ต้องวางแผนอะไรก่อนเริ่มพัฒนาโครงการ [ปิด]

สมมติว่าฉันได้รับข้อมูลจำเพาะสำหรับโครงการจากลูกค้าและตอนนี้ถึงเวลาที่จะเริ่มพัฒนาโครงการ โดยปกติฉันเพิ่งเริ่มต้นด้วยโมดูลแรก (ปกติจะลงทะเบียนผู้ใช้) จากนั้นไปจากโมดูลหนึ่งไปยังอีกโมดูล ฉันวางแผนในหัวก่อนที่ฉันจะเริ่มต้นในโมดูลว่ามันทำงานอย่างไร แต่ไม่มีการวางแผนมาก่อน

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

เพื่อให้ความคิดที่ดีขึ้นเกี่ยวกับสิ่งที่ฉันขอฉันควรทำอย่างไร -

a) แบ่งโครงการออกเป็นส่วนประกอบ

b) วางแผนปฏิสัมพันธ์ของพวกเขาเช่นฉันควรทำแผนภาพคลาสเขียนการทดสอบหน่วย ฯลฯ หรือไม่

ความคิดใด ๆ

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

• เริ่มต้นด้วยเป้าหมายสำหรับโครงการ เป้าหมายจำเป็นต้องคลุมเครือที่สุด แต่ช่วยให้คุณมุ่งเน้นไปที่สิ่งที่ลูกค้าหรือผู้ใช้ตั้งใจจะทำกับซอฟต์แวร์ ในตอนท้ายของวันที่คุณต้องการบรรลุเป้าหมายเหล่านั้น - แม้ว่านั่นหมายถึงการวางคุณสมบัติที่ยอดเยี่ยมบางอย่าง
• จากนั้นฉันก็เริ่มแบ่งแอปพลิเคชันลงในโดเมนย่อย อาจมีวิธีที่แตกต่างกันหลายร้อยวิธีในการทำเช่นนี้ซึ่งเป็นเหตุผลที่เราเริ่มต้นด้วยเป้าหมายของโครงการ เราต้องการแยกแอปพลิเคชันออกเป็นระบบย่อยที่เกี่ยวข้องซึ่งสนับสนุนเป้าหมายเหล่านั้น สิ่งนี้ช่วยให้เรามุ่งเน้นไปที่งานต่อไป
• ระบุวิธีการและเวลาที่ระบบย่อยจำเป็นต้องโต้ตอบ เราไม่ได้จัดการรายละเอียดเพียงข้อมูลระดับสูงเพื่อให้แน่ใจว่าเรามีระบบรวมของระบบย่อย คุณจำเป็นต้องมีความคิดทั่วไปของสิ่งนี้เพื่อให้คุณสามารถรวบรวมรายละเอียดที่สนับสนุนเป้าหมายโดยรวมของโครงการ
• ให้รายละเอียดเฉพาะสำหรับระบบย่อยที่ฉันกำลังดำเนินการอยู่ในขณะนี้ (คล้ายกับกลยุทธ์ปัจจุบันของคุณ) ฉันรู้อยู่แล้วว่าระบบย่อยนี้ต้องการโต้ตอบกับระบบย่อยอื่น ๆ อย่างไร แต่ฉันอาจต้องหาทางเลือกสองทางเพื่อให้เหมาะสมที่สุด แต่ละระบบย่อยจะถูกคั่นด้วยส่วนต่อประสานดังนั้นฉันสามารถปรับการใช้งานให้ได้มากที่สุดโดยไม่ทำลายระบบโดยรวม
• ตรวจสอบวิธีการนำสิ่งต่าง ๆ มาใช้ในระบบย่อยปัจจุบันของฉันเปรียบเทียบกับวิธีการนำไปใช้ในระบบย่อยอื่น ๆ ทุกวิธีที่ไม่สอดคล้องกันเป็นสิ่งที่ผู้ใช้ต้องเรียนรู้ ไม่เป็นไรถ้าเรากำลังพูดถึงแนวคิดใหม่เอี่ยม เพื่อประโยชน์ในการใช้งานเราไม่ต้องการ 5 วิธีในการลบข้อมูลที่มีอยู่เพียงเพราะเราขี้เกียจ การใช้องค์ประกอบส่วนติดต่อผู้ใช้ซ้ำกันเป็นวิธีที่รวดเร็วที่สุดในการทำให้แอปพลิเคชันใช้งานง่ายขึ้น การเรียนรู้สามแนวคิดนั้นง่ายกว่าการเรียนรู้ 20

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

ฉันคิดว่ามันจะดีกว่าถ้าฉันไปดูรายละเอียด

ขวา. ความคิดที่ดี.

วางแผนว่าระบบจะทำงานอย่างไรก่อนที่ฉันจะเขียนมัน

ดี. ทำมากกว่านั้น

ส่วนประกอบหลักคืออะไร

ยอดเยี่ยม

พวกเขาจะโต้ตอบอย่างไร

แก้ไข.

ฉันไม่แน่ใจว่าสิ่งที่ฉันควรวางแผน

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

อ่านเพิ่มเติมเกี่ยวกับโมเดลการดู 4 + 1: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

อ่านเพิ่มเติมเกี่ยวกับกรอบ Zachman: http://en.wikipedia.org/wiki/Zachman_Framework

นั่นคือสิ่งที่คุณต้องวางแผน

ฉันควร a) แบ่งโครงการออกเป็นส่วนประกอบต่างๆอย่างไร

ใช้รูปแบบการออกแบบที่ใช้กันอย่างแพร่หลายสำหรับโครงการอื่นที่คล้ายคลึงกัน

เมื่อสงสัยให้อ่านพิมพ์เขียว J2EE เพื่อหาแนวคิด

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

ฉันควรข) วางแผนการโต้ตอบของพวกเขาเช่นฉันควรทำแผนภาพคลาสเขียนการทดสอบหน่วย ฯลฯ

ใช่. ความคิดที่ดีทั้งหมด

สิ่งสำคัญที่สุดที่ต้องทำ: ตรวจสอบรายละเอียดโต้ตอบกับลูกค้าเพื่อรับข้อมูลจำเพาะที่ละเอียดยิ่งขึ้น

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

ดังนั้นคุณควรตรวจสอบรายละเอียดสัมภาษณ์ลูกค้าและดูว่านี่คือสิ่งที่เขา / เธอต้องการจริงๆและต้องการและสามารถจ่ายได้ ฯลฯ

พัฒนากรณีทดสอบ / ใช้และตรวจสอบกับลูกค้า หากความต้องการไม่สามารถทดสอบได้ให้โยนมันทิ้ง

พัฒนาการออกแบบและตรวจสอบให้แน่ใจว่าชิ้นส่วนทั้งหมดทำงานอย่างถูกต้องตามที่ทฤษฎีจะทำในสิ่งที่คุณต้องการ

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

คุณต้องการให้มีการออกแบบบางอย่างก่อนที่จะเริ่มการเข้ารหัส

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

จากนั้นฉันก็สร้าง 1 คุณลักษณะจากบนลงล่างเพื่อให้คุณใช้งานบางอย่างได้อย่างสมบูรณ์

จากนั้นไปจากที่นั่น

ทุกอย่าง

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