ออกแบบก่อนพัฒนา

มันคือความสมดุลระหว่างการออกแบบระบบและการพัฒนาระบบเสมอ มีคำกล่าวที่โดดเด่นที่ว่า “design a little, code a little”

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

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

“การเข้ารหัสและการออกแบบโปรแกรมซอฟต์แวร์เป็นสองขั้นตอนที่แตกต่างกัน”

Developer ส่วนใหญ่รวมทั้งผมด้วย เรามักอยากจะข้ามไปที่การพัฒนาก่อนการออกแบบ แล้วค่อยพัฒนาการออกแบบในภายหลังโดยที่เราปรับแต่งให้เหมาะกับโปรแกรมที่เราเขียนขึ้น ฉันเรียกสิ่งนี้ว่าการพัฒนาปฏิกิริยา

ดังที่อลัน เลคินกล่าวไว้ว่า “การล้มเหลวในการวางแผนคือการวางแผนที่จะล้มเหลว”

ดังนั้นเมื่อใดก็ตามที่นักพัฒนาซอฟต์แวร์หรือวิศวกรไม่ได้ให้ความสำคัญกับการออกแบบเป็นอันดับแรกสำหรับโครงการใดๆ ไม่ว่าจะเล็กก็ตาม ผู้พัฒนากำลังปูทางให้ซอฟต์แวร์ล้มเหลว และตัวผู้พัฒนาซอฟต์แวร์เองก็ล้มเหลว ซึ่งจะส่งผลกระทบต่อบริษัท

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

ตามพจนานุกรมของเคมบริดจ์ระบุว่า

จินตนาการคือการจินตนาการหรือคาดหวังว่าบางสิ่งเป็นไปได้หรือเป็นไปได้ที่พึงปรารถนาในอนาคต

ตามพจนานุกรมของอ็อกซ์ฟอร์ดระบุว่า

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

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

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

นักพัฒนาซอฟต์แวร์ที่ฝึกฝนการออกแบบบางส่วนหรือพลาดการออกแบบไปโดยสิ้นเชิงมักใช้วิธีต่อไปนี้:

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

ในบทความของ Chris Richardson หัวข้อCxOs forget architecture at their perilเขาบรรยายว่าทำไมสถาปัตยกรรม ( สำหรับกรณีของเรา เราขอเปลี่ยนคำว่าสถาปัตยกรรมเป็น 'การออกแบบ' เพื่อแสดงถึงบริบทของการออกแบบโดยทั่วไปของเรา ) มีความสำคัญในการพัฒนาซอฟต์แวร์และเป็นขั้นตอนที่ต้องทำ ก่อนที่ผู้พัฒนาจะนำไปใช้งานจริง

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

Brian Foote และ Joseph Yoder กล่าวไว้ว่า “ถ้าคุณคิดว่าสถาปัตยกรรมที่ดีมีราคาแพง ให้ลองใช้สถาปัตยกรรมที่ไม่ดี”

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

กุญแจสำคัญในการสร้างรหัสทางเศรษฐกิจสำหรับระบบใดๆ ก็ตามคือการใช้เวลาในการออกแบบโปรแกรมของคุณอย่างเป็นระบบก่อนที่จะเขียนรหัสบรรทัดเดียว ซึ่งอาจรวมถึงการออกแบบไดอะแกรมสถาปัตยกรรม, ERD, โฟลว์ควบคุมและแผนภูมิการไหล, pseudocodes, การขึ้นต่อกันอื่นๆ) ด้วยการออกแบบอย่างเป็นระบบ (การเขียนโปรแกรมแบบมีโครงสร้าง) คุณจะลดการใช้หน่วยความจำ เวลาในการประมวลผล และโดยทั่วไปโค้ดจะทำงานได้อย่างถูกต้องในการทดลองใช้งานครั้งแรก

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

“ออกแบบก่อนพัฒนาเสมอ”

อ้างอิง

การออกแบบเฟิร์มแวร์สำหรับระบบฝังตัวโดยใช้ Warnier-Orr Diagrams — บทความทางเทคนิค (allaboutcircuits.com )

CxO ละเลยสถาปัตยกรรมที่อันตราย (microservices.io)