หากคุณเพิ่งได้รับการแนะนำให้รู้จักกับโครงการใหม่สิ่งแรกที่คุณมองหาคือการได้รับแนวคิดว่ามันทำงานอย่างไร
คุณมองหาการออกแบบก่อนหรือไม่? หากมีการออกแบบคุณมองหาอะไร คลาสไดอะแกรมหรือไดอะแกรมปรับใช้หรือไดอะแกรมลำดับหรืออย่างอื่น?
หรือคุณตรงไปสำหรับรหัส? ถ้าเป็นเช่นนั้นคุณจะเข้าใจได้อย่างไรว่าเลเยอร์ที่ต่างกันมีปฏิสัมพันธ์กันอย่างไร
คำตอบ:
ฉันเริ่มต้นด้วยรหัส แยกเอกสารการออกแบบหากมีมีแนวโน้มที่จะผิดหรือเข้าใจผิดว่าไม่ใช่ ดังนั้นฉันเริ่มต้นโดยพยายามติดตามกระแสง่าย ๆ ผ่านรหัส; หากเป็น webapp ก็อาจเป็นคำขอหรือลำดับของคำขอตัวอย่างเช่น เมื่อฉันทำเช่นนั้นแล้วฉันก็มีโครงกระดูกเพื่อทำความเข้าใจให้มากขึ้น จากนั้นฉันอาจกลับไปอ่านการออกแบบหรือเอกสารอื่น ๆ แต่ ณ จุดนี้ฉันมีบางสิ่งบางอย่างที่เกี่ยวข้องกับพวกเขาและเพื่อตรวจสอบพวกเขาด้วยดังนั้นฉันสามารถตรวจสอบข้อมูลดัฟฟ์ หรือฉันอาจจะอ่านรหัสหรือกรณีทดสอบ ฯลฯ
ฉันจะเริ่มต้นในระดับที่สูงขึ้น หากมีเอกสารใด ๆ ที่ผู้ใช้หันไป - คู่มือผู้ใช้หรือคำแนะนำ ความล้มเหลวนั้นจะดูที่ข้อกำหนดของข้อกำหนดเพื่อให้คุณมีความคิดเกี่ยวกับซอฟต์แวร์ที่ควรทำ ฉันอยากจะดูการออกแบบและลองแมปลงบนไฟล์รหัส หวังว่าสิ่งเหล่านี้จะถูกจัดโครงสร้างเป็นโฟลเดอร์ด้วยวิธีที่เหมาะสม ฉันจะเลือกส่วนหนึ่งของการออกแบบและเข้าไปในไฟล์เพื่อติดตามโฟลว์ของโค้ดโดยไม่จมลงไปในรายละเอียดที่ละเอียดเกินไป
ฉันเริ่มต้นด้วยการตั้งค่าระบบนักพัฒนา ฉันใช้ขั้นตอนที่ทำเป็นเอกสาร วิธีนี้ช่วยให้แมวออกมาจากกระเป๋าเกี่ยวกับจำนวนเอกสารที่สอดคล้องกับความเป็นจริง
นอกจากนี้ยังบอกฉันว่าการพึ่งพาคืออะไร เรื่องนี้
ตอนนี้ฉันได้ติดตั้งนักพัฒนาแล้ว (และฉันทำเครื่องหมายเอกสารการตั้งค่าด้วยการแก้ไขตามที่ฉันไป) ฉันสร้างเวอร์ชัน ฉันสิ้นสุดการถามคำถามตลอดระยะนี้
ตอนนี้มันถูกสร้างขึ้นฉันทำแบบฝึกหัดเบื้องต้นจากคู่มือผู้ใช้ สิ่งนี้บอกฉันอย่างคร่าว ๆ ว่าระบบทำอะไร
ตอนนี้ฉันมีเงื่อนงำบางส่วนเกี่ยวกับระบบฉันอ่านเอกสารการออกแบบซึ่งตอนนี้ฉันเชื่อในสัดส่วนที่ว่าเอกสารผิดไปไกลขนาดไหน
เมื่อฉันได้รับเอกสารเกี่ยวกับพฤติกรรมจริงฉันสามารถเริ่มดูโค้ดและดูว่ามีอะไรเกิดขึ้นจริง พวกเขาไม่เคยเข้าแถว แต่ตอนนี้ฉันรู้ว่าจะเชื่อได้มากแค่ไหน
จากนั้นฉันจะดูที่เอาต์พุต IDE สำหรับความคิดเห็น "todo" และ "fixme" สิ่งที่ชอบ "แก้ไขในรุ่น 2.0" ก็เป็นสิ่งที่ต้องทำเช่นกัน
ดังนั้นจึงเป็นเรื่องของการเรียนรู้ความจริงและในขณะที่ผู้คนชี้ให้เห็นเอกสารการออกแบบที่แยกออกมานั้นไม่ค่อยทันสมัยหรือถูกต้อง แต่มันบอกคุณได้ว่าผู้คนกำลังคิดอะไรอยู่ ณ จุดหนึ่ง และแน่นอนว่าคนเหล่านั้นอาจไม่ได้ซักถาม
ความชอบของฉันคือการเริ่มต้นด้วยการออกแบบเพื่อรับภาพรวมของโครงการและพยายามทำความเข้าใจกับคุณลักษณะและ / หรือโครงสร้างที่สำคัญก่อนที่จะเจาะลึกเข้าไปในรายละเอียด
การออกแบบอยู่เสมอ ด้วยโค้ดมันคุ้มค่าที่จะทำตามขั้นตอนการตั้งค่าของนักพัฒนา (การตรวจสอบแหล่งที่มารับโครงการที่สร้างขึ้นทำการเปลี่ยนแปลงการกำหนดค่าที่จำเป็น) แต่ไม่มีจุดใดที่จะพยายามเรียนรู้โครงสร้างของแอปพลิเคชันจากรหัสของมัน สิ่งนั้นบอกคุณว่าโครงสร้างคืออะไรไม่ใช่สาเหตุของโครงสร้างหรือสิ่งที่นักพัฒนารายอื่นคิดว่าจุดเด่นและจุดที่ไม่ดีเป็นของสถาปัตยกรรม สิ่งที่คุณเรียนรู้จากไดอะแกรมและไวท์บอร์ดกับนักพัฒนา
สำหรับซอฟต์แวร์ที่มีความซับซ้อนฉันจะเข้าหามันอย่างคร่าว ๆ ราวกับว่ามันเป็นโครงการพัฒนาใหม่ เริ่มต้นด้วยวิสัยทัศน์บริบทบริบทขอบเขตผู้มีส่วนได้เสียที่ยิ่งใหญ่ อ่านเอกสารของผู้ใช้และรับทราบวิธีการใช้งาน รับการฝึกอบรมผู้ใช้ด้วยซอฟต์แวร์ถ้าเป็นไปได้ (หรือมี) จากนั้นเริ่มต้นศึกษาเกี่ยวกับข้อกำหนดและเอกสารการออกแบบเพื่อให้ได้แนวคิดในการทำงานในระดับสูง พูดคุยกับนักออกแบบหากพวกเขายังอยู่รอบ ๆ ดูสถาปัตยกรรมระบบในมุมมองที่ต่างกัน จากนั้นเริ่มขุดลงในฟังก์ชั่นหลักและดูรหัสบางอย่างกลับไปสู่ข้อกำหนดและการออกแบบตามต้องการ เมื่อคุณดูโค้ดให้รันซอฟต์แวร์เพื่อดูการทำงาน ในขณะที่รวบรวมเอกสารสรุปสำหรับการอ้างอิงในอนาคต - คุณเป็นเจ้าของ Cliffs Notes แตกแขนงออกไปจนกว่าคุณจะมีความคิดที่ดีเกี่ยวกับวิธีการทำงานและเข้ากันได้ดี แต่ให้ความสนใจกับส่วนที่คุณจะทำงานด้วย ถึงตอนนี้คุณมีความเข้าใจจากบนลงล่างถึงทั้งระบบหรืออย่างน้อยก็ส่วนที่เกี่ยวข้องกับคุณ
แน่นอนว่าในโลกแห่งความเป็นจริงคุณอาจไม่มีเวลาที่จะทำสิ่งเหล่านี้ทั้งหมดก่อนที่คุณจะเริ่มทำให้มือสกปรกโดยเฉพาะอย่างยิ่งในโครงการขนาดใหญ่ แต่นี่คือวิธีที่ฉันจะทำถ้ามันขึ้นอยู่กับฉัน
คุณควรทำงานไปมาระหว่างรหัสนั้นและเอกสารการออกแบบใด ๆ
คุณสามารถเริ่มต้นที่รหัสหรือการออกแบบและมันไม่สำคัญ อ่านรหัสจนกว่าคุณจะรู้สึกดีและสับสนอย่างแท้จริงจากนั้นตรวจสอบเอกสารการออกแบบ หรืออ่านเอกสารการออกแบบเพื่อให้ได้ภาพระดับสูงแล้วดูที่รหัสเพื่อดูว่ามีลักษณะอย่างไร ทำซ้ำเกือบตลอดเวลาตราบใดที่คุณทำงานกับรหัส
โปรดทราบว่าเอกสารการออกแบบเกือบจะล้าสมัยและไม่ถูกต้องในหลาย ๆ ด้าน อย่างไรก็ตามตราบใดที่คุณคำนึงถึงประเด็นเหล่านี้เอกสารที่ล้าสมัยยังคงช่วยให้คุณเข้าใจความคิดของผู้แต่งในอดีตที่ผ่านมา ปัญหาและข้อกังวลระดับสูงจำนวนมากจะยังคงใช้ได้และคุณอาจจะเข้าใจได้อย่างรวดเร็วยิ่งขึ้นว่ารหัสมาถึงที่ที่มันอยู่ที่ไหนถ้าคุณแม้แต่ภาพลงวันที่ซึ่งผู้เขียนคิดว่ามันจะ ไป.
ในขณะที่คุณทำงานกับรหัสและการออกแบบให้สร้างเอกสารของคุณเองซึ่งอธิบายความเข้าใจเกี่ยวกับโค้ดวันนี้ เอกสารเหล่านี้อาจเป็นแบบร่างอย่างง่าย ๆ หรือสองอย่างบางทีพวกเขาอาจเขียนเป็นวิกิหรืออาจเป็นอย่างอื่น อย่าทำให้ซับซ้อนเกินไป: ไม่มีเอกสารคำ 30 หน้า เพียงแค่ลดความคิดลงซึ่งจะทำให้ความคิดของคุณชัดเจนขึ้นอย่างมาก
ขึ้นอยู่กับประเภทของแอปพลิเคชัน ถ้าเป็นแอพที่มีข้อมูลเป็นศูนย์กลางฉันมักจะเริ่มต้นด้วยการออกแบบฐานข้อมูล หากมี UI คุณสามารถเรียกใช้ (หรือการออกแบบหน้าจอที่ดี) สิ่งเหล่านี้สามารถช่วยให้คุณมีความคิดที่ดีว่าแอปทำงานอย่างไรอย่างรวดเร็ว (ฉันกำลังพูดถึงที่นี่ไม่กี่ชั่วโมงที่นี่) หลังจากนั้นฉันก็เริ่มขุดลงในโค้ดและมันจะสมเหตุสมผลมากกว่าเพราะฉันรู้ว่าแอปพลิเคชันกำลังทำอะไรอยู่
ฉันเริ่มต้นด้วยเอกสารการออกแบบ โดยเฉพาะอย่างยิ่งข้อมูลจำเพาะ - ที่บอกเจตนาของสิ่งที่ถูกมอง
ถ้าเป็นไปได้ฉันจะดูบันทึกย่อการออกแบบและเอกสารประกอบเพื่อให้ได้รสชาติโดยทั่วไปของวิธีการทำกระบวนการคิดสไตล์และลักษณะของคนที่เกี่ยวข้อง
ถ้าเป็นไปได้ฉันก็จะคุยกับคนที่ทำงานกับมัน - มันทำอะไร? อย่างไร? ทำไม? ศพถูกฝังอยู่ที่ไหน?
มีแนวโน้มในหมู่นักพัฒนาที่จะกระโดดเข้าไปในรหัส: "ให้ฉันแสดงรหัสนี้" นี่เป็นสิ่งที่ดีสำหรับพวกเขา แต่มีแนวโน้มที่จะจี้ความต้องการของฉัน - ซึ่งก็คือการเข้าใจในระดับสูงซึ่งให้บริบทกับสิ่งที่อยู่ในระดับต่ำ
มันใช้พลังสมองจำนวนมหาศาลเพื่อดูรหัสเล็กน้อยออกจากบริบทที่สมบูรณ์และเข้าใจสิ่งที่มีความหมาย ดังนั้นถ้าเป็นไปได้ให้ผู้พัฒนาพูดคุยเกี่ยวกับ PRINCIPLE โครงสร้างหน่วยโมดูลสิ่งที่นำไปสู่การชื่นชมของงาน
เท่านั้นก็คุ้มค่าที่จะลองใช้โค้ด
ในรูปแบบขนาดใหญ่ของสิ่งต่าง ๆ การมองดูโค้ดก็เหมือนกับการดูหน้าเว็บที่เต็มไปด้วย 0 และ 1 มีความหมาย แต่ใช้เวลานานในการคิดออก การได้รับรสชาติของสถานที่มองและส่วนใดที่มีความหมายจะช่วย จำกัด พื้นที่การค้นหาให้แคบลง
ทั้งหมดที่กล่าว - เมื่อไม่มี doco ไม่มีคนและรหัสเท่านั้น - แล้วไม่มีอะไรเลยนอกจากดูที่รหัส
ในกรณีนี้ปกติฉันจะไม่พยายามและเข้าใจมันโดยการอ่านลึก ๆ ช้า ๆ ฉันทำแบบรวดเร็วและอ่านทุกอย่าง บางครั้งนี่เป็นเพียงแค่เปิดไฟล์และนั่งกดปุ่มหน้าลง คุณสามารถรับภาพขนาดใหญ่ที่น่าทึ่งเพียงแค่ทำสิ่งนี้ (และในบางกรณีฉันยังใช้ไฟล์ที่เรียกใช้งานได้แบบ string-dump และสืบค้นไฟล์เหล่านั้นเพื่อค้นหาลายเซ็นและรูปแบบ
ฉันเริ่มต้นด้วยการทดสอบ หากการทดสอบหน่วยและการทดสอบการรวมเข้าด้วยกันเขียนได้ดีพวกเขาจะอธิบายกรณีการใช้งาน หากพวกเขาเขียนไม่ดีหรือไม่เขียนเลย (น่าเศร้านี่เป็นส่วนใหญ่) ฉันเริ่มต้นด้วยจุดเข้าในรหัสและจับคู่ผู้ที่มีการออกแบบ
ฉันจะเขียนการทดสอบสำหรับแต่ละกรณีการใช้งานซึ่งถูกค้นพบโดยทรีที่คุณจะพบหลังจากตรวจสอบจุดเข้าใช้งานเพื่อตรวจสอบรหัสและใช้ยูทิลิตี้การครอบคลุมโค้ดเพื่อดูว่าฉันขาดอะไร การทดสอบเหล่านี้บอกฉันได้ว่ารหัสทำงานอย่างไร
ฉันมักจะพยายามเพิ่มคุณค่าให้กับสิ่งที่ฉันดู การเขียนการทดสอบการล้างโค้ดการทำซ้ำฟังก์ชัน (20+ บรรทัด) ที่มีขนาดใหญ่
ฉันพบว่าการสร้างเอกสารเพียงอย่างเดียวไม่ได้เพิ่มคุณค่าที่แท้จริงให้กับโค้ดเนื่องจากไม่เคยโต้ตอบกับโค้ด
"การออกแบบ" คืออะไร? README หรือไม่? แผนภาพ uml คุณสามารถทำเอกสารการออกแบบได้ครึ่งทาง (และส่วนใหญ่ทำ) คุณไม่สามารถกำหนดรหัสครึ่งทางได้
การออกแบบใด ๆ ก็จะเป็นความเห็นในขณะที่รหัสคือความจริง
ฉันจะอ้างถึงเอกสารรองเมื่อฉันไม่เข้าใจเหตุผลของรหัสเท่านั้น
การอ่านรหัสเป็นทักษะที่จำเป็นสำหรับนักพัฒนา คุณอาจเรียนรู้ได้ในตอนนี้คุณจะไม่ได้เห็นเอกสารที่มีประโยชน์มากมายในอาชีพของคุณ
จากนั้นฉันก็ดู README, TODO และ Changelog ของผู้พัฒนา หากฉันไม่เข้าใจว่าเพราะเหตุใดซอฟต์แวร์จึงถูกเขียนขึ้นมามันถูกเขียนอย่างไรและจะไปยังที่ใด ... ฉันไม่ได้ใช้
ออกแบบก่อนแล้วตามด้วยรหัสจากบนลงล่างหากคุณต้องการดังนั้นฉันจึงเข้าใจบริบทในทุกระดับที่ฉันต้องทำงาน
แต่ถ้าฉันต้องทำการเปลี่ยนแปลงที่เฉพาะเจาะจงเช่นแก้ไขรายงานหรือการคำนวณฉันแค่ไปดูที่รหัส
โดยเฉพาะอย่างยิ่งแนวทาง "ออกแบบก่อน" ของฉันคือวิธีนี้:
ฉันเริ่มต้นด้วยตัวแบบโดเมนหากมีอยู่ถ้าไม่มีฉันจะสร้างอย่างน้อยหนึ่งแบบพื้นฐาน (จุดเริ่มต้นที่ดีคือตัวแบบข้อมูล) มันกำหนด "glosary" ของแอปพลิเคชันและความสัมพันธ์ระหว่างวัตถุ (คลาส)
รูปภาพ "วัตถุที่ได้รับการจัดการ" โดย aplication
จากนั้นฉันก็มองหารูปแบบกรณีการใช้งานเพื่อหา "แอปพลิเคชันที่ทำเสร็จแล้ว" แม้ว่าฉันจะชอบแมปกระบวนการถ้าเป็นรูปแบบที่แสดงลำดับของกระบวนการ
หลังจากนั้นฉันควรจะมีรูปสวย ๆ ของแอพพลิเคชั่นจากนั้นฉันก็สามารถออกแบบการเปลี่ยนแปลงได้
โดยวิธีการที่คำตอบข้างต้นอยู่ในบริบทของการใช้งานทางธุรกิจ
รหัสไม่โกหก ความคิดที่ดีแน่นอนที่จะได้รับภาพรวมของโครงการก่อนที่จะเข้าใจสิ่งที่มันทำ อย่างไรก็ตามถ้างานของคุณคือการทำความเข้าใจรายละเอียดเกี่ยวกับวิธีการทำงานของโครงการการดูรหัสอย่างน้อยสำหรับฉันก็เหมือนกับการดูจิ๊กซอว์ชิ้นต่อชิ้นยกเว้นว่าคุณดูแต่ละคลาสคุณเพิ่มอีก ชิ้นส่วนของจิ๊กซอว์ หากรหัสมีโครงสร้างที่ดีคุณสามารถเห็นรูปแบบที่สร้างจากชื่อของคลาสโดยไม่ต้องตรวจสอบสิ่งที่คลาสทำ ในหลายกรณีคุณสามารถรับคำแนะนำและเคล็ดลับจากโค้ดที่จะช่วยคุณเพิ่มเติม
ในที่สุดคุณจะได้รับสิ่งที่คิดเอาคืนไม่ได้ในสิ่งที่โปรแกรมทำคือตัวต่อที่สมบูรณ์ เอกสารอาจไม่สมบูรณ์หรือไม่ถูกต้อง แต่รหัสไม่เคยอยู่ ทั้งหมดนี้คุณสามารถทำได้โดยไม่ต้องหาวิธีที่แต่ละวิธีทำ ทุกคนไม่สามารถเรียนรู้เกี่ยวกับโครงการด้วยวิธีนี้ แต่ถ้าคุณทำบ่อยๆมันจะง่ายขึ้นสำหรับคุณไม่ต้องพูดถึงว่าคุณจะได้รับส่วนสำคัญของแอปพลิเคชั่นขนาดกลางในเวลาไม่กี่ชั่วโมงในการศึกษา แม้ว่าฉันคิดว่ามันทั้งหมดลงมาที่การตั้งค่า
หลังจากที่ฉันเห็นรหัสของโมดูล / จุดที่สำคัญที่สุดของแอปพลิเคชัน: การดูรหัสฉันสามารถตรวจสอบความดีของการออกแบบได้
ตัวอย่าง:
คุณต้องทำงานในการจัดการแอปพลิเคชันของเว็บแอพเกี่ยวกับการรายงานทางการเงิน
หลังจากฉันอ่านรหัสเกี่ยวกับข้อความแล้วแอปพลิเคชั่นเริ่มต้นและสิ้นสุด (สำหรับล็อกที่เป็นไปได้ในฐานข้อมูล) กระบวนการหลักของการสร้างข้อมูลที่ต้องรายงาน ฯลฯ ฯลฯ (ตัวอย่างเช่นในการจัดเก็บก๊าซกระบวนการหลักเป็นเรื่องเกี่ยวกับ การคำนวณสต็อคก๊าซในพื้นที่เก็บข้อมูลของลูกค้าด้วยการจัดหาและการฉีดกระบวนการรองคือการเรียกเก็บเงินประมาณข้อมูลนี้คำนวณก่อนหน้านี้)
ทั้งรหัสหรือการออกแบบ ฉันชอบพูดคุยกับผู้มีส่วนได้ส่วนเสียและผู้ใช้ปลายทางและดูว่ามันทำงานอย่างไรจากมุมมองของพวกเขา เมื่อฉันสามารถสร้างภาพในใจจากพวกเขาฉันมีลักษณะที่รวดเร็วในการออกแบบทางเทคนิคแล้วลงบนรหัส
ฉันจะไปกับการออกแบบก่อนแล้วรหัสพร้อมกัน มันสำคัญมากเพราะทุกโครงการต่างกัน คุณต้องออกมาพร้อมแผนและเวิร์กโฟลว์กระบวนการระดับสูงจาก A ถึง Z ก่อนที่คุณจะสามารถเริ่มทำงานกับรหัสพร้อมกันได้ การตัดสินใจทุกครั้งจะต้องมีการบันทึกไว้เพื่อให้ทีมอื่น ๆ (หรือตัวคุณเอง) ซึ่งเป็น / กำลังพัฒนารหัสจะทราบการปรับปรุงล่าสุดและสิ่งที่ได้รับการยืนยัน
หากมีเอกสารการออกแบบระดับสูงที่ดีฉันจะใช้มัน จะต้องกระชับและทันสมัย ถ้ามันละเอียดเกินไปหรือล้าสมัยเกินไปฉันจะไปหาโค้ด
แน่นอนมันขึ้นอยู่กับโครงการใช่ไหม โครงการที่ซับซ้อนมากหรือหลายแง่มุมอาจเข้าหาผ่านเอกสารได้ดีกว่า (หากเอกสารมีความแข็งแกร่งเพียงพอ)
โมดูลง่าย ๆ หรือแอพพลิเคชั่นที่เรียบง่ายในความคิดของฉันเกือบจะเข้าถึงที่ดีที่สุดในระดับรหัส
ไม่มีคำตอบที่ถูกต้องสำหรับทุกสถานการณ์!