ขณะนี้ฉันกำลังทำงานในโครงการที่กำลังจะเข้าถึงโค้ดมากกว่า 5,000 บรรทัด แต่ฉันไม่เคยคิดเลยเกี่ยวกับการออกแบบเลย ฉันควรใช้วิธีใดในการจัดโครงสร้างและจัดการรหัสของฉัน กระดาษและปากกา? แผนภาพ UML อื่น ๆ อีก?
ขณะนี้ฉันกำลังทำงานในโครงการที่กำลังจะเข้าถึงโค้ดมากกว่า 5,000 บรรทัด แต่ฉันไม่เคยคิดเลยเกี่ยวกับการออกแบบเลย ฉันควรใช้วิธีใดในการจัดโครงสร้างและจัดการรหัสของฉัน กระดาษและปากกา? แผนภาพ UML อื่น ๆ อีก?
คำตอบ:
คุณอาจได้รับมุมมองที่แตกต่างกันมากเท่าที่จะมีคำตอบ แต่นี่คือมุมมองของฉัน
สำหรับผู้เริ่มต้นโค้ด 5,000+ บรรทัดนั้นเป็นโครงการขนาดเล็กมาก ทีนี้คุณจะออกแบบโครงการที่เติบโตได้อย่างไร ประการแรกคุณออกแบบระบบของคุณไม่ใช่รหัส รหัสเป็นจริงรองสถาปัตยกรรม เริ่มต้นด้วยการรองรับข้อกำหนดขั้นต่ำในปัจจุบัน ใส่ส่วนประกอบที่เกี่ยวข้องกับการวาดแบบง่าย ๆ ฉันชอบ UML เป็นการส่วนตัว แต่ทุกอย่างที่มองเห็นจะดี เป็นการดีที่คุณต้องการปฏิบัติตามแนวทางการออกแบบที่ดีที่นี่ (อินเทอร์เฟซการแยกความกังวล ฯลฯ )
เมื่อคุณสนับสนุนข้อกำหนดขั้นต่ำในการออกแบบให้กำหนดรหัส ลองทำตามวิธีการเข้ารหัสที่ดีอีกครั้ง
หลังจากนั้นเพิ่มฟังก์ชั่นให้มากขึ้นเมื่อมีข้อกำหนดใหม่เกิดขึ้น เป็นการดีที่คุณต้องการปรับปรุงการออกแบบของคุณเช่นกัน
สิ่งที่สำคัญตามประสบการณ์ของฉันคือไม่ได้ออกแบบระบบของคุณโดยไม่ต้องคำนึงถึงข้อกำหนดที่มีอยู่ มิฉะนั้นโครงการของคุณจะเติบโตอย่างรวดเร็วและซับซ้อนมากในเวลาอันสั้น อีกครั้ง - ปฏิบัติตามแนวทางปฏิบัติที่ดีและเริ่มต้นด้วยข้อกำหนดปัจจุบันที่เป็นรูปธรรม
Flow Diagram, Class Diagram, Case Diagram นั้นเป็นไดอะแกรมที่ต้องมีสำหรับโครงการขนาดใหญ่ ค้นหาและเลือกไลบรารีภายนอกที่คุณต้องการและค้นหารหัสโอเพนซอร์ซที่คล้ายกันที่คุณสามารถใช้ (เพื่อเรียนรู้ & เพื่อลดเวลาในการพัฒนา)
ฉันแนะนำให้คุณซื้อไวท์บอร์ด & แม่เหล็กที่มีสีสัน & Post-It มันจะช่วยให้คุณระบุงานของคุณ
แม้ว่ารหัส PS 5000+ นั้นไม่ได้เป็น "ใหญ่" ซอฟต์แวร์ CMS / ฟอรัมมีรหัสมากกว่า 5,000 บรรทัด
ฉันจะสร้างแพ็คเกจและคลาสไดอะแกรม ในแผนภาพแพคเกจฉันสนใจคลาสกลุ่มและอินเตอร์เฟสในลักษณะที่เป็นตรรกะ ฉันต้องการสร้างแพ็คเกจภายใน ฯลฯ ...
แต่ก่อนอื่นคุณต้องคิดว่าโปรแกรมควรทำอย่างไร คุณสามารถสร้างไดอะแกรม usecase หรือทำเอง ฉันทำด้วยตนเองกับคลาสไดอะแกรมเพราะฉันต้องการรับรหัสทันทีและมันง่ายกว่าที่จะสลับเป็นไดอะแกรมคลาสแพ็กเกจในภายหลัง การใช้คลาสไดอะแกรมทำให้ฉันมี java ถ้าฉันไม่ชอบฉันก็เปลี่ยนมันเอง รหัสใหม่จะได้รับการอัพเดตโดยอัตโนมัติในไดอะแกรมของฉัน ฉันมีการแสดงรหัสที่อัปเดตในระดับสูงที่มองเห็นได้ มีประโยชน์จริง ๆ เพราะแม้ว่าฉันรหัสฉันสามารถใช้เวลาสองสามนาทีเพื่อดูว่าโครงการของฉันเป็นไปในลักษณะกราฟิก ฉันเพียงแค่ลากและวางเอนทิตีในแพ็คเกจที่ถูกต้องด้วยตนเองเพื่อจัดระเบียบ ฉันคิดว่ารหัสของฉันดีกว่าการใช้แพ็คเกจ abstraction และไดอะแกรมระดับที่สูงขึ้น
(ที่มา: ejb3.org )
เพื่อนร่วมงานของฉันบางคนบอกว่าวิธีการทำงานของฉันคืออึ .... แต่ฉันชอบ :-)
อย่างแน่นอน. ฉันมีบอร์ดแบบลบแท็บเล็ตขนาดเล็กสำหรับใช้ในสิ่งนี้ แต่ใช้สิ่งที่คุณพอใจ สิ่งสำคัญคือคุณสามารถทำให้ความคิดของคุณลงได้อย่างง่ายดายและดูภาพรวมว่าทุกอย่างเข้าด้วยกันได้อย่างไร
บางคนชอบแผนที่เป็นทางการมากขึ้นเช่นไดอะแกรม UML แต่ฉันรู้สึกว่ามันง่ายเกินไปที่จะเข้าใจวิธีการแต่ละวิธีที่ควรจะเป็น อย่างไรก็ตามอีกครั้งให้ใช้สิ่งที่คุณพอใจ
แก้ไข: นอกจากนี้คุณยังอาจจะสนใจในการเขียนโปรแกรมความรู้ แนวคิดคือคุณสามารถวางแผนได้ทั้งหมดและค่อยๆเจาะจงมากขึ้น ตัวอย่างเช่นคุณอาจบอกว่าโปรแกรมของคุณประกอบด้วย:
จากนั้นคุณอาจปรับแต่งความคิดในการแปลงข้อความให้เป็นรูปภาพ ดังนั้นอาจมีลักษณะเช่น:
จากนั้นคุณอาจปรับความคิดในการเลือกสีแบบสุ่มและในไม่ช้าคุณก็จะเขียนโค้ดปกติ
สำหรับฉันแล้วกิจกรรมการพัฒนาซอฟต์แวร์เป็นชุดของการออกแบบที่ละเอียดยิ่งขึ้นเพื่อแก้ไขปัญหาเฉพาะ เมื่อคุณมีความคิดระดับสูงในสิ่งที่คุณกำลังสร้างการออกแบบของคุณอาจมีระดับสูงมากเช่น "จะมีเว็บแอปพลิเคชันที่พูดถึงฐานข้อมูล SQL และบริการเว็บหลายแห่ง" หรืออะไรทำนองนั้น จากนั้นเมื่อคุณเจาะลึกลงไปในรายละเอียดของแต่ละชิ้นคุณจะได้รับการออกแบบอย่างละเอียดยิ่งขึ้น ขึ้นอยู่กับความซับซ้อนของการแก้ปัญหาจะมีการวนซ้ำของความพยายามในการออกแบบมากขึ้นหรือน้อยลง การทำซ้ำขั้นสุดท้ายเกี่ยวข้องกับการสร้างรหัสจริงที่ใช้ระดับการออกแบบที่สูงขึ้น
สำหรับฉันความแตกต่างระหว่างสถาปัตยกรรมและการออกแบบนั้นน้อยมากและเป็นเพียงแค่การทำซ้ำที่แตกต่างกันของกระบวนการที่ฉันอธิบายข้างต้น เส้นแบ่งระหว่างคนทั้งสองเลือนและต่างกันสำหรับคนต่าง
มีศิลปะในการตัดสินใจระดับของรายละเอียดการออกแบบที่จะเข้าไปในส่วนใดส่วนหนึ่งของแอปพลิเคชันและที่จุดในวงจรชีวิตของโครงการ สำหรับความเสี่ยงสูงโครงการที่มีความซับซ้อนสูงคุณอาจต้องการการออกแบบที่มีรายละเอียดมากก่อนที่คุณจะเขียนบรรทัดของโค้ด สำหรับโครงการขนาดเล็กคุณสามารถหลีกเลี่ยงการออกแบบด้านหน้าเล็ก ๆ น้อย ๆ และออกรหัสบางอย่างแล้วดูว่าอะไรไม่ทำงานและออกแบบพื้นที่เหล่านั้นใหม่ ที่นี่ไม่มีคำตอบสำหรับเขียนเพียงคำเดียว โดยปกติจะอยู่ที่ไหนสักแห่งระหว่างสองขั้ว
ฉันมีบล็อกโพสต์ที่พูดถึงหลักการบางอย่างที่ฉันใช้เมื่อเข้าใกล้สถาปัตยกรรม มันอาจเป็นประโยชน์กับคุณเมื่อคิดตามบรรทัดเหล่านี้ บางบทความเฉพาะกับ. NET แต่ส่วนใหญ่ไม่ได้เป็น
ฉันเคยถามตัวเองด้วยคำถามเดียวกัน ตอนนี้ฉันเพิ่งฝึกฝนพัฒนาโดยใช้การทดสอบและไม่ต้องกังวลกับมัน ฉันไม่ได้ "วางแผน" โค้ดเลยยกเว้นทำตามมาตรฐานสำหรับสถาปัตยกรรมที่เลือก เมื่อฉันเริ่มโครงการฉันมีความคิดว่าจะต้องใช้อะไรบ้าง แต่เมื่อมีการพัฒนาฉันพยายามที่จะเปิดใจ โดยการติดตามการพัฒนาที่ขับเคลื่อนด้วยการทดสอบและการสร้างรหัสใหม่อย่างต่อเนื่องฉันไม่จำเป็นต้อง "วางแผน" โค้ด ฉันเพิ่งทำแบบทดสอบเสร็จแล้วและการออกแบบก็เกิดขึ้นจากการปรับสภาพ นี่เป็นการออกแบบที่ดีกว่าแผนใด ๆ ที่ฉันทำได้ก่อนการเข้ารหัส