ผสมผสานการวางแผนและการเขียนโปรแกรมที่เหมาะสมในโครงการใหม่

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

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

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

อัปเดต : เริ่มด้วย "คลิกจำลอง" และใช้งานฟังก์ชันในภายหลังได้อย่างไร

คุณมาถูกทางแล้ว ไม่จำเป็นต้องใช้เวลาวางแผนเป็นเดือน แต่คุณควรมีแผนบางอย่าง

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

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

วางแผนผลิตภัณฑ์ที่มีศักยภาพขั้นต่ำและนำไปใช้ จากนั้นฟังผู้ใช้ของคุณและวางแผนการปรับปรุงเชิงตรรกะครั้งต่อไปและนำไปใช้ ทำซ้ำ

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

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

ข้อเสนอแนะของฉันคือการวางแผนเพียงเล็กน้อย แต่เริ่มต้นการเขียนโค้ดโดยเร็วและ refactor, refactor, refactor เพื่อให้รหัสอยู่ในรูป หลักการของ DRY (อย่าทำซ้ำตัวเอง) เป็นตัวบ่งชี้ที่ยอดเยี่ยมสำหรับสิ่งนั้น

เมื่อฉันอยู่ในตำแหน่งนี้บางครั้งฉันก็ใช้ประโยชน์จาก TDD (ทดสอบขับเคลื่อนการพัฒนา) และเริ่มวางแผนการทดสอบสำหรับส่วนที่ซับซ้อนที่สุดของระบบที่ฉันกำลังพัฒนา หรือฉันอาจรวบรวมรหัสหลอกระดับสูงอีกครั้งสำหรับพื้นที่ที่ซับซ้อนที่สุด ฉันพบว่ากระบวนการนี้ให้แผนปฏิบัติการที่หลวมและช่วยให้ฉันระบุว่าพื้นที่ใดน่าจะใช้เวลามากที่สุด

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

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

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

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

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