สำหรับคนไอทีจำนวนมากรวมถึงตัวผมเองเมื่อไม่กี่ปีที่ผ่านมากระบวนการพัฒนาซอฟต์แวร์ที่เหมาะสมจะเกี่ยวข้องกับการสร้างเอกสารการออกแบบอย่างละเอียดพร้อมไดอะแกรม UML จำนวนมากก่อนที่จะมีการเขียนบรรทัดโค้ด (ดูเหมือนว่าคำอธิบายของโมเดลน้ำตก แต่จะเหมือนกันกับว่องไวยกเว้นว่าการทำซ้ำจะเล็กกว่า)
ในช่วงสองหรือสามปีที่ผ่านมาฉันเปลี่ยนใจโดยสิ้นเชิง ฉันยังคิดว่าข้อกำหนดรายละเอียดความต้องการพร้อมกรณีทดสอบที่เกี่ยวข้องนั้นเป็นสิ่งจำเป็นอย่างยิ่ง สำหรับโครงการขนาดใหญ่ฉันก็ต้องการโครงร่างของสถาปัตยกรรมโดยรวมก่อนที่จะเริ่มโค้ด แต่ส่วนที่เหลือทั้งหมดควรทำในรหัสมากที่สุด ในกรณีที่เหมาะสมไม่ควรมีคำอธิบายของการออกแบบซอฟต์แวร์ยกเว้นรหัสเอง
ฉันมาถึงข้อสรุปนี้ได้อย่างไร นี่คือข้อโต้แย้งบางอย่าง:
ผลตอบรับ
เครื่องมือสำหรับการเขียนเอกสารหรือสร้างไดอะแกรมนั้นให้ผลป้อนกลับเล็กน้อย ใช่มีเครื่องมือสร้างแบบจำลองที่ทำการตรวจสอบความสอดคล้องบนไดอะแกรม UML แต่มีข้อ จำกัด และมาพร้อมกับค่าใช้จ่ายจำนวนมาก
หากไม่มีข้อเสนอแนะมันเป็นการยากที่จะรับรู้และแก้ไขข้อผิดพลาด
ทันทีที่คุณเขียนรหัสคุณจะได้รับข้อเสนอแนะมากมายเช่น:
- ข้อผิดพลาดและคำเตือนจากคอมไพเลอร์
- ผลการวิเคราะห์รหัสคงที่
- การทดสอบหน่วย
สามารถจดจำและแก้ไขข้อผิดพลาดได้อย่างรวดเร็ว
ความมั่นคง
เพื่อให้แน่ใจว่ารหัสสอดคล้องกับเอกสารของคุณคุณต้องตรวจสอบอีกครั้งและอีกครั้ง หากมีการเปลี่ยนแปลงบ่อยครั้งจะเป็นการยากที่จะทำให้รหัสและเอกสารตรงกัน
refactoring
มีเครื่องมือและเทคนิคที่มีประสิทธิภาพสำหรับการ refactoring code ในขณะที่การ refactoring textual description หรือไดอะแกรมมักจะยากและเกิดข้อผิดพลาดได้ง่าย
มีเงื่อนไขหนึ่งที่จะทำให้งานนี้: รหัสจะต้องง่ายพอที่จะอ่านและทำความเข้าใจ สิ่งนี้อาจไม่สามารถทำได้ด้วย Assembler, Basic หรือ Fortran แต่ภาษาสมัยใหม่ (และห้องสมุด) มีความหมายมากกว่า
ดังนั้นหากข้อโต้แย้งของฉันถูกต้องควรมีแนวโน้มไปสู่ข้อกำหนดและเอกสารการออกแบบซอฟต์แวร์ที่มีน้ำหนักเบาหรือน้อย มีหลักฐานเชิงประจักษ์สำหรับแนวโน้มนี้หรือไม่?