ฉันจะวางแผนรหัสฐานได้อย่างไร [ปิด]


10

ขณะนี้ฉันกำลังทำงานในโครงการที่กำลังจะเข้าถึงโค้ดมากกว่า 5,000 บรรทัด แต่ฉันไม่เคยคิดเลยเกี่ยวกับการออกแบบเลย ฉันควรใช้วิธีใดในการจัดโครงสร้างและจัดการรหัสของฉัน กระดาษและปากกา? แผนภาพ UML อื่น ๆ อีก?


ภาษาอะไร ?

ไม่ใช่ปากกาและกระดาษ แป้นพิมพ์และจอภาพ
Tulains Córdova

คำตอบ:


6

คุณอาจได้รับมุมมองที่แตกต่างกันมากเท่าที่จะมีคำตอบ แต่นี่คือมุมมองของฉัน

สำหรับผู้เริ่มต้นโค้ด 5,000+ บรรทัดนั้นเป็นโครงการขนาดเล็กมาก ทีนี้คุณจะออกแบบโครงการที่เติบโตได้อย่างไร ประการแรกคุณออกแบบระบบของคุณไม่ใช่รหัส รหัสเป็นจริงรองสถาปัตยกรรม เริ่มต้นด้วยการรองรับข้อกำหนดขั้นต่ำในปัจจุบัน ใส่ส่วนประกอบที่เกี่ยวข้องกับการวาดแบบง่าย ๆ ฉันชอบ UML เป็นการส่วนตัว แต่ทุกอย่างที่มองเห็นจะดี เป็นการดีที่คุณต้องการปฏิบัติตามแนวทางการออกแบบที่ดีที่นี่ (อินเทอร์เฟซการแยกความกังวล ฯลฯ )

เมื่อคุณสนับสนุนข้อกำหนดขั้นต่ำในการออกแบบให้กำหนดรหัส ลองทำตามวิธีการเข้ารหัสที่ดีอีกครั้ง

หลังจากนั้นเพิ่มฟังก์ชั่นให้มากขึ้นเมื่อมีข้อกำหนดใหม่เกิดขึ้น เป็นการดีที่คุณต้องการปรับปรุงการออกแบบของคุณเช่นกัน

สิ่งที่สำคัญตามประสบการณ์ของฉันคือไม่ได้ออกแบบระบบของคุณโดยไม่ต้องคำนึงถึงข้อกำหนดที่มีอยู่ มิฉะนั้นโครงการของคุณจะเติบโตอย่างรวดเร็วและซับซ้อนมากในเวลาอันสั้น อีกครั้ง - ปฏิบัติตามแนวทางปฏิบัติที่ดีและเริ่มต้นด้วยข้อกำหนดปัจจุบันที่เป็นรูปธรรม


ฉันเชื่อว่าคุณหมายถึง "มุมมอง" ไม่ใช่ "โอกาส" (ฉันไม่สามารถแก้ไขได้เพราะมีอักขระน้อยกว่าหกตัว)
Maxpm

4

Flow Diagram, Class Diagram, Case Diagram นั้นเป็นไดอะแกรมที่ต้องมีสำหรับโครงการขนาดใหญ่ ค้นหาและเลือกไลบรารีภายนอกที่คุณต้องการและค้นหารหัสโอเพนซอร์ซที่คล้ายกันที่คุณสามารถใช้ (เพื่อเรียนรู้ & เพื่อลดเวลาในการพัฒนา)

ฉันแนะนำให้คุณซื้อไวท์บอร์ด & แม่เหล็กที่มีสีสัน & Post-It มันจะช่วยให้คุณระบุงานของคุณ

แม้ว่ารหัส PS 5000+ นั้นไม่ได้เป็น "ใหญ่" ซอฟต์แวร์ CMS / ฟอรัมมีรหัสมากกว่า 5,000 บรรทัด


คำถามที่จริงจัง: แผนภาพการใช้ประโยชน์คืออะไร? ภาพที่ฉันเห็นนั้นเป็นภาพวาดรูปแท่งและบอลลูนที่เจ็บปวดเล็กน้อยซึ่งไม่ได้บอกอะไรเลยที่ฉันยังไม่รู้
Joris Timmermans

1
MadKeithV - เช่นเดียวกับเครื่องมือใด ๆ พวกเขาเป็นคนดีเท่าคนที่ใช้พวกเขา พยายามหลีกเลี่ยงคดีเล็ก ๆ น้อย ๆ ที่เจ็บปวดและมุ่งไปที่สถานการณ์ที่ซับซ้อนมากขึ้น อย่างไรก็ตามสิ่งที่คุณพบว่าไม่สำคัญอื่น ๆ ในทีมอาจไม่ กรณีการใช้งานหรือแผนภาพอื่น ๆ จะช่วยให้แน่ใจว่าทุกคนกำลังร้องเพลงจากแผ่นเพลงสวดเดียวกัน
Gavin Coates

@Gavin Coates - ฉันจะได้รับสิ่งที่คุณพูด แต่คุณรู้หรือไม่จากตัวอย่างออนไลน์ใด ๆ ที่ฉันสามารถตรวจสอบความคิดเห็นของฉันเกี่ยวกับไดอะแกรมเหล่านี้ได้จริงหรือ?
Joris Timmermans

3

ฉันจะสร้างแพ็คเกจและคลาสไดอะแกรม ในแผนภาพแพคเกจฉันสนใจคลาสกลุ่มและอินเตอร์เฟสในลักษณะที่เป็นตรรกะ ฉันต้องการสร้างแพ็คเกจภายใน ฯลฯ ...

ข้อความแสดงแทน

แต่ก่อนอื่นคุณต้องคิดว่าโปรแกรมควรทำอย่างไร คุณสามารถสร้างไดอะแกรม usecase หรือทำเอง ฉันทำด้วยตนเองกับคลาสไดอะแกรมเพราะฉันต้องการรับรหัสทันทีและมันง่ายกว่าที่จะสลับเป็นไดอะแกรมคลาสแพ็กเกจในภายหลัง การใช้คลาสไดอะแกรมทำให้ฉันมี java ถ้าฉันไม่ชอบฉันก็เปลี่ยนมันเอง รหัสใหม่จะได้รับการอัพเดตโดยอัตโนมัติในไดอะแกรมของฉัน ฉันมีการแสดงรหัสที่อัปเดตในระดับสูงที่มองเห็นได้ มีประโยชน์จริง ๆ เพราะแม้ว่าฉันรหัสฉันสามารถใช้เวลาสองสามนาทีเพื่อดูว่าโครงการของฉันเป็นไปในลักษณะกราฟิก ฉันเพียงแค่ลากและวางเอนทิตีในแพ็คเกจที่ถูกต้องด้วยตนเองเพื่อจัดระเบียบ ฉันคิดว่ารหัสของฉันดีกว่าการใช้แพ็คเกจ abstraction และไดอะแกรมระดับที่สูงขึ้น

ข้อความแสดงแทน
(ที่มา: ejb3.org )

เพื่อนร่วมงานของฉันบางคนบอกว่าวิธีการทำงานของฉันคืออึ .... แต่ฉันชอบ :-)


2

อย่างแน่นอน. ฉันมีบอร์ดแบบลบแท็บเล็ตขนาดเล็กสำหรับใช้ในสิ่งนี้ แต่ใช้สิ่งที่คุณพอใจ สิ่งสำคัญคือคุณสามารถทำให้ความคิดของคุณลงได้อย่างง่ายดายและดูภาพรวมว่าทุกอย่างเข้าด้วยกันได้อย่างไร

บางคนชอบแผนที่เป็นทางการมากขึ้นเช่นไดอะแกรม UML แต่ฉันรู้สึกว่ามันง่ายเกินไปที่จะเข้าใจวิธีการแต่ละวิธีที่ควรจะเป็น อย่างไรก็ตามอีกครั้งให้ใช้สิ่งที่คุณพอใจ


แก้ไข: นอกจากนี้คุณยังอาจจะสนใจในการเขียนโปรแกรมความรู้ แนวคิดคือคุณสามารถวางแผนได้ทั้งหมดและค่อยๆเจาะจงมากขึ้น ตัวอย่างเช่นคุณอาจบอกว่าโปรแกรมของคุณประกอบด้วย:

  1. รับข้อความจากผู้ใช้
  2. แปลงข้อความเป็นรูปภาพ
  3. บันทึกภาพผลลัพธ์ไปยังดิสก์

จากนั้นคุณอาจปรับแต่งความคิดในการแปลงข้อความให้เป็นรูปภาพ ดังนั้นอาจมีลักษณะเช่น:

  1. กำหนดจำนวนบรรทัดที่ข้อความควรใช้
  2. เลือกสีแบบสุ่มสำหรับข้อความและพื้นหลัง
  3. ประมวลผลในรูปแบบที่เหมาะสม

จากนั้นคุณอาจปรับความคิดในการเลือกสีแบบสุ่มและในไม่ช้าคุณก็จะเขียนโค้ดปกติ


2

สำหรับฉันแล้วกิจกรรมการพัฒนาซอฟต์แวร์เป็นชุดของการออกแบบที่ละเอียดยิ่งขึ้นเพื่อแก้ไขปัญหาเฉพาะ เมื่อคุณมีความคิดระดับสูงในสิ่งที่คุณกำลังสร้างการออกแบบของคุณอาจมีระดับสูงมากเช่น "จะมีเว็บแอปพลิเคชันที่พูดถึงฐานข้อมูล SQL และบริการเว็บหลายแห่ง" หรืออะไรทำนองนั้น จากนั้นเมื่อคุณเจาะลึกลงไปในรายละเอียดของแต่ละชิ้นคุณจะได้รับการออกแบบอย่างละเอียดยิ่งขึ้น ขึ้นอยู่กับความซับซ้อนของการแก้ปัญหาจะมีการวนซ้ำของความพยายามในการออกแบบมากขึ้นหรือน้อยลง การทำซ้ำขั้นสุดท้ายเกี่ยวข้องกับการสร้างรหัสจริงที่ใช้ระดับการออกแบบที่สูงขึ้น

สำหรับฉันความแตกต่างระหว่างสถาปัตยกรรมและการออกแบบนั้นน้อยมากและเป็นเพียงแค่การทำซ้ำที่แตกต่างกันของกระบวนการที่ฉันอธิบายข้างต้น เส้นแบ่งระหว่างคนทั้งสองเลือนและต่างกันสำหรับคนต่าง

มีศิลปะในการตัดสินใจระดับของรายละเอียดการออกแบบที่จะเข้าไปในส่วนใดส่วนหนึ่งของแอปพลิเคชันและที่จุดในวงจรชีวิตของโครงการ สำหรับความเสี่ยงสูงโครงการที่มีความซับซ้อนสูงคุณอาจต้องการการออกแบบที่มีรายละเอียดมากก่อนที่คุณจะเขียนบรรทัดของโค้ด สำหรับโครงการขนาดเล็กคุณสามารถหลีกเลี่ยงการออกแบบด้านหน้าเล็ก ๆ น้อย ๆ และออกรหัสบางอย่างแล้วดูว่าอะไรไม่ทำงานและออกแบบพื้นที่เหล่านั้นใหม่ ที่นี่ไม่มีคำตอบสำหรับเขียนเพียงคำเดียว โดยปกติจะอยู่ที่ไหนสักแห่งระหว่างสองขั้ว

ฉันมีบล็อกโพสต์ที่พูดถึงหลักการบางอย่างที่ฉันใช้เมื่อเข้าใกล้สถาปัตยกรรม มันอาจเป็นประโยชน์กับคุณเมื่อคิดตามบรรทัดเหล่านี้ บางบทความเฉพาะกับ. NET แต่ส่วนใหญ่ไม่ได้เป็น


2

ฉันเคยถามตัวเองด้วยคำถามเดียวกัน ตอนนี้ฉันเพิ่งฝึกฝนพัฒนาโดยใช้การทดสอบและไม่ต้องกังวลกับมัน ฉันไม่ได้ "วางแผน" โค้ดเลยยกเว้นทำตามมาตรฐานสำหรับสถาปัตยกรรมที่เลือก เมื่อฉันเริ่มโครงการฉันมีความคิดว่าจะต้องใช้อะไรบ้าง แต่เมื่อมีการพัฒนาฉันพยายามที่จะเปิดใจ โดยการติดตามการพัฒนาที่ขับเคลื่อนด้วยการทดสอบและการสร้างรหัสใหม่อย่างต่อเนื่องฉันไม่จำเป็นต้อง "วางแผน" โค้ด ฉันเพิ่งทำแบบทดสอบเสร็จแล้วและการออกแบบก็เกิดขึ้นจากการปรับสภาพ นี่เป็นการออกแบบที่ดีกว่าแผนใด ๆ ที่ฉันทำได้ก่อนการเข้ารหัส

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.