เกณฑ์สำหรับการออกแบบที่ไม่ดี
ชีวิตดำเนินไปอย่างเรียบง่าย บ่อยครั้ง เพื่อที่จะฉลาด คุณแค่ไม่ต้องทำอะไรโง่ๆ สิ่งนี้ใช้กับการพัฒนาซอฟต์แวร์ด้วย: ในกรณีส่วนใหญ่ ในการทำบางสิ่งให้ดี คุณแค่ต้องไม่ทำมันให้แย่
โปรแกรมเมอร์ส่วนใหญ่มีประสบการณ์กับส่วนต่างๆ ของระบบที่ได้รับการออกแบบมาไม่ดี แต่ที่น่าเศร้ายิ่งกว่านั้น พวกคุณส่วนใหญ่จะมีประสบการณ์ที่น่าเศร้าจากการตระหนักว่าคุณเป็นผู้เขียนระบบดังกล่าว เราต้องการสิ่งที่ดีที่สุด แต่มันก็กลายเป็นเช่นเคย
นักพัฒนาส่วนใหญ่ไม่ต้องการสถาปัตยกรรมที่ไม่ดี และสำหรับหลายๆ ระบบ มีจุดที่พวกเขาเริ่มพูดว่าสถาปัตยกรรมของมันแย่มาก ทำไมสิ่งนี้ถึงเกิดขึ้น? การออกแบบสถาปัตยกรรมไม่ดีตั้งแต่เริ่มต้น หรือแย่ลงเมื่อเวลาผ่านไป?
ต้นตอของปัญหานี้คือการขาดคำจำกัดความของการออกแบบที่ "ไม่ดี"
สำหรับฉันแล้วดูเหมือนว่าความเข้าใจในคุณภาพของการออกแบบและสาเหตุของ "การสลายตัว" ซึ่งเป็นคุณสมบัติที่สำคัญที่สุดสำหรับโปรแกรมเมอร์ทุกคน ในกรณีส่วนใหญ่ สิ่งสำคัญคือการระบุปัญหา และจะเป็นเรื่องของเทคโนโลยีในการแก้ปัญหา
คำจำกัดความของ “การออกแบบที่ไม่ดี”
หากคุณตัดสินใจที่จะคุยโม้เกี่ยวกับโค้ดของคุณต่อหน้าเพื่อนโปรแกรมเมอร์ คุณมักจะถูกเยาะเย้ยด้วยการตอบกลับว่า “ใครทำสิ่งนี้”, 'ทำไมมันเป็นอย่างนั้น' และ “ฉันจะทำในสิ่งที่ต่างออกไป” สิ่งนี้เกิดขึ้นบ่อยมาก
ทุกคนมีความแตกต่างกัน แต่คุณยังคงเขียนโค้ดสำหรับโปรแกรมเมอร์คนอื่นๆ ของคุณ ดังนั้นในกระบวนการพัฒนาคุณลักษณะแต่ละอย่าง คุณจำเป็นต้องมีขั้นตอนการตรวจสอบเสมอเมื่อคนอื่นๆ ดูโค้ดของคุณ
แต่แม้ว่าจะมีหลายสิ่งหลายอย่างที่สามารถทำได้ด้วยวิธีต่างๆ แต่ก็มีเกณฑ์ที่นักพัฒนาทุกคนเห็นพ้องต้องกัน โค้ดส่วนใดก็ตามที่ตรงตามความต้องการแต่ยังคงแสดงคุณลักษณะหนึ่งอย่าง (หรือมากกว่า) นั้นเป็นการออกแบบที่ไม่ดี
การออกแบบที่ไม่ดี:
- เปลี่ยนแปลงได้ยากเนื่องจากการเปลี่ยนแปลงใด ๆ ส่งผลกระทบต่อส่วนอื่น ๆ ของระบบมากเกินไป ( ความแข็ง , ความแข็ง).
- เมื่อทำการเปลี่ยนแปลง ส่วนอื่นๆ ของระบบจะหยุดทำงานโดยไม่คาดคิด ( ความเปราะบาง , ความเปราะบาง).
- รหัสนี้ใช้ซ้ำได้ยากในแอปพลิเคชันอื่น เนื่องจากยากเกินไปที่จะลบออกจากแอปพลิเคชันปัจจุบัน ( เคลื่อนที่ไม่ได้ , เคลื่อนที่ไม่ได้).
และที่น่าตลกก็คือแทบจะเป็นไปไม่ได้เลยที่จะหาชิ้นส่วนของระบบที่ไม่มีลักษณะเหล่านี้ (นั่นคือ มีความยืดหยุ่น เชื่อถือได้ และนำมาใช้ซ้ำได้) ตรงตามความต้องการ และในขณะเดียวกันการออกแบบก็แย่ .
ดังนั้นเราจึงสามารถใช้คุณลักษณะทั้งสามนี้เพื่อตัดสินได้อย่างชัดเจนว่าการออกแบบนั้น "ไม่ดี" หรือ "ดี"
สาเหตุของ "การออกแบบที่ไม่ดี"
อะไรทำให้การออกแบบมีความแข็ง เปราะ และไม่สามารถเคลื่อนย้ายได้ การพึ่งพาซึ่งกันและกันอย่างเข้มงวดของโมดูล
การออกแบบนั้นเข้มงวดหากไม่สามารถเปลี่ยนแปลงได้ง่าย ความแข็งแกร่งนี้เกิดจากความจริงที่ว่าการเปลี่ยนแปลงรหัสชิ้นเดียวในระบบทอส่งผลให้เกิดการเปลี่ยนแปลงเรียงซ้อนในโมดูลที่ขึ้นต่อกัน สิ่งนี้จะเกิดขึ้นเสมอเมื่อมีบุคคลหนึ่งกำลังทำงานกับโค้ด
สิ่งนี้ทำให้กระบวนการพัฒนาเชิงพาณิชย์ทั้งหมดซับซ้อนในทันที: เมื่อนักออกแบบหรือนักพัฒนาไม่สามารถคาดการณ์จำนวนของการเปลี่ยนแปลงที่ต่อเนื่องกัน จึงไม่สามารถประเมินผลกระทบของการเปลี่ยนแปลงดังกล่าวได้ ดังนั้นพวกเขาจึงพยายามเลื่อนการเปลี่ยนแปลงดังกล่าวออกไปอย่างไม่มีกำหนด
และสิ่งนี้ทำให้ต้นทุนของการเปลี่ยนแปลงไม่สามารถคาดเดาได้ เมื่อเผชิญกับความไม่แน่นอนดังกล่าว ผู้จัดการจึงลังเลที่จะทำการเปลี่ยนแปลง ดังนั้นการออกแบบจึงเข้มงวดอย่างเป็นทางการ
เมื่อถึงจุดหนึ่ง โครงการของคุณผ่าน "ขอบฟ้าเหตุการณ์" และถึงวาระที่จะตกลงไปใน "หลุมดำ" ของสถาปัตยกรรมที่เข้มงวด
ความเปราะบางคือแนวโน้มที่ระบบจะพังในหลายจุดหลังจากการเปลี่ยนแปลงเพียงครั้งเดียว โดยปกติแล้วปัญหาใหม่ๆ จะเกิดขึ้นในสถานที่ซึ่งไม่เกี่ยวข้องกับสถานที่แห่งการเปลี่ยนแปลง ความเปราะบางดังกล่าวบั่นทอนความมั่นใจในการออกแบบและบำรุงรักษาระบบอย่างมาก
โดยปกติจะเป็นกรณีที่ไม่มีวิธีการส่วนตัว ก็เพียงพอแล้วที่จะทำให้วิธีการทั้งหมดเป็นแบบสาธารณะและคุณจะต้องพบกับสถาปัตยกรรมที่เปราะบาง การห่อหุ้มช่วยจัดการกับสิ่งนี้ในระดับจุลภาค แต่ในระดับมหภาค คุณจำเป็นต้องมีสถาปัตยกรรมแบบแยกส่วน
เมื่อโครงการมีสถาปัตยกรรมที่เปราะบาง ผู้พัฒนาไม่สามารถรับประกันคุณภาพของผลิตภัณฑ์ได้
การเปลี่ยนแปลงง่ายๆ ในส่วนหนึ่งของแอปพลิเคชันทำให้เกิดข้อบกพร่องในส่วนอื่นๆ ที่ไม่เกี่ยวข้อง การแก้ไขข้อผิดพลาดเหล่านี้นำไปสู่ปัญหาที่มากขึ้น และกระบวนการคุ้มกันก็กลายเป็นสุนัขที่มีชื่อเสียงไล่ตามหางของมันเอง
การออกแบบนั้นไม่สามารถเคลื่อนที่ได้เมื่อส่วนที่จำเป็นของระบบเชื่อมโยงกับรายละเอียดที่ไม่ต้องการอื่นๆ โค้ดของตนเองมากเกินไป แนวทางและวิธีแก้ปัญหาเฉพาะของตนเอง
คุณจำคนตัดไม้ JUL ที่นักพัฒนาสร้างระดับการบันทึกของตัวเองขึ้นมาโดยไม่มีเหตุผลที่ดีได้หรือไม่? นี่เป็นเพียงกรณี
เพื่อให้นักออกแบบได้ทราบว่าการนำการออกแบบที่มีอยู่กลับมาใช้ซ้ำนั้นง่ายเพียงใด ก็เพียงพอแล้วที่จะคิดว่าการใช้งานในแอปพลิเคชันใหม่จะง่ายเพียงใด
หากการออกแบบมีความเชื่อมโยงกันอย่างแน่นหนา ผู้ออกแบบรายนี้จะต้องตกใจกับปริมาณงานที่ต้องใช้ในการแยกส่วนที่จำเป็นของระบบออกจากรายละเอียดที่ไม่จำเป็น ในกรณีส่วนใหญ่ การออกแบบดังกล่าวไม่สามารถใช้ซ้ำได้ เนื่องจากต้นทุนในการแยกชิ้นส่วนนั้นมีค่ามากกว่าการพัฒนาตั้งแต่เริ่มต้น
ความเกี่ยวข้อง
ทุกสิ่งเปลี่ยนไป แต่ทุกอย่างยังคงเหมือนเดิม (สุภาษิตจีน)
มีคำถามที่ดีมากข้างต้น อะไรคืออันตรายของระบบที่เปราะบางและแข็ง? ใช่ เนื่องจากกระบวนการจัดการโครงการดังกล่าวคาดเดาไม่ได้และควบคุมไม่ได้ และราคาก็แพงหูฉี่
ผู้จัดการจะให้หรือไม่ให้ไปข้างหน้าเพื่อเพิ่มคุณสมบัติบางอย่างได้อย่างไรหากเขาไม่รู้ว่าจริง ๆ แล้วจะใช้เวลาเท่าไหร่? จะจัดลำดับความสำคัญของงานอย่างไรหากคุณไม่สามารถประมาณเวลาและความซับซ้อนของการใช้งานได้อย่างเพียงพอ
และนักพัฒนาจะจ่ายหนี้ทางเทคนิคก้อนเดิมได้อย่างไรในเมื่อเราจะจ่ายหนี้นั้น และเราไม่สามารถเข้าใจได้ว่าเราจะจ่ายเท่าไหร่จนกว่าเราจะจ่าย
ปัญหาเกี่ยวกับการใช้รหัสซ้ำหรือการทดสอบก็มีความเกี่ยวข้องเช่นกัน การทดสอบหน่วยไม่เพียงแต่ทดสอบสมมติฐานบางอย่างเกี่ยวกับหน่วยที่ทดสอบ แต่ยังกำหนดระดับการเกาะตัวกันและสามารถใช้เป็นตัวบ่งชี้การนำกลับมาใช้ใหม่ได้
นี่คือคำพูดจาก Bob Martin สำหรับกรณีนี้: “ในการใช้รหัสของคุณซ้ำ คุณต้องใช้ความพยายามในการนำมาใช้ใหม่ให้น้อยกว่าค่าใช้จ่ายในการพัฒนาตั้งแต่เริ่มต้น ” มิฉะนั้นจะไม่มีใครยุ่งกับเรื่องนี้
การใช้หลักการออกแบบและรูปแบบมีจุดประสงค์เดียว - เพื่อให้การออกแบบดี หากการใช้งานไม่ได้ให้ประโยชน์ใด ๆ แก่คุณ (หรือในทางกลับกัน ละเมิดหลักการของ "การออกแบบที่ดี") แสดงว่ามีบางอย่างในเรือนกระจกของคุณไม่ถูกต้อง และบางทีเครื่องมือนี้อาจเริ่มใช้เพื่อวัตถุประสงค์อื่นแล้ว