ฉันเพิ่งอ่านลิงค์บทความที่คุณโพสต์ฉันต้องบอกว่าฟาวเลอร์ทำคะแนนได้ดีมากและหลายสิ่งหลายอย่างที่เขาพูดฉันได้สนับสนุนทีมของเรามาหลายปีแล้ว
IMO หากคุณออกแบบที่ดีคุณไม่ควรเข้าไปเกี่ยวข้องกับสถานการณ์ที่สิ้นชีวิต ผมเคยดูซอฟแวร์เคยเป็นที่สร้างขึ้นจากการสร้างบล็อก ฉันยังเชื่อในการออกแบบล่วงหน้า แต่เป้าหมายหลักคือไม่ได้ออกแบบผลิตภัณฑ์ทั้งหมด แต่เพื่อจัดทำสถาปัตยกรรม / ทิศทางโดยรวมเพื่อให้ทีมของคุณสามารถเห็นภาพทั่วไปที่เราทำงานอยู่ หากคุณมีชิ้นส่วนของลูกบาศก์และชิ้นสามเหลี่ยมมันจะช่วยให้คุณทราบว่าปราสาทจะรวมตัวกันได้อย่างไรก่อนที่คุณจะเริ่มตบชิ้นด้วยกัน
เนื่องจากฉันมาจากดินแดน OO สำหรับฉันแต่ละบล็อกเป็นคลาสและพื้นที่ผิวของบล็อกนั้นเป็นส่วนต่อประสานสาธารณะ (สิ่งที่มองเห็นได้จากคลาสภายนอกหรือคลาสที่ได้รับ) ถ้าคุณทำตามหลักการ SOLID ที่ดีคุณจะต้องแน่ใจว่าแต่ละบล็อคนั้นง่ายมากและมีส่วนต่อประสานสาธารณะที่ใช้งานง่าย กลับไปที่การเปรียบเทียบของฉันคุณต้องการให้แน่ใจว่ารหัสของคุณสร้างรูปร่างที่เรียบง่ายเท่านั้น เมื่อใดก็ตามที่คุณสร้างคลาสที่ซับซ้อนเกินไป (ฟังก์ชั่นมากมายหลายตัวแปร) คุณสร้างรูปร่างที่ยากที่จะนำมาใช้ใหม่เมื่อความต้องการเปลี่ยนแปลง
ฉันเห็นด้วยกับฟาวเลอร์ในเรื่องความเสี่ยง / ความท้าทายที่ใหญ่ที่สุดสำหรับการออกแบบเชิงวิวัฒนาการคือคุณต้องตัดสินใจเลือกการออกแบบเพื่อกำหนดเวลาและคุณคาดหวังว่านักพัฒนาแต่ละคนจะทำการตัดสินใจเหล่านั้น นี่คือที่ที่ระบบสามารถพังหากคุณไม่มีกลไกการตอบรับที่เหมาะสม เมื่อใดก็ตามที่มีการขอคุณสมบัติใหม่มันเป็นสิ่งที่ดึงดูดอย่างยิ่งที่จะหาฟังก์ชั่นที่จำเป็นต้องขยายเพิ่มใส่เงื่อนไขบางอย่างภายในและเพียงเพิ่มโค้ดจำนวนมากในฟังก์ชันนั้น และบางครั้งสิ่งนี้อาจเป็นสิ่งที่จำเป็น แต่นี่ก็เป็น (IMO) วิธีปฏิบัติที่พบบ่อยที่สุดเพียงอย่างเดียวที่นำไปสู่องค์ประกอบที่สิ้นตาย สิ่งนี้ไม่เกี่ยวกับการออกแบบเชิงวิวัฒนาการ นี่คือสิ่งที่เรียกว่า "ไม่มีการออกแบบ"
ตราบใดที่คุณใช้เวลาในการถอยกลับและพูดว่าเดี๋ยวก่อนชั้นนี้มีสมาชิก 15 คนแล้วให้ฉันแยก 6 ตัวเหล่านี้และใส่ในชั้นเรียนของพวกเขาเองซอฟต์แวร์ของคุณจะเบามาก น้ำหนักเบายืดหยุ่นและนำมาใช้ใหม่ได้ แน่นอนว่า PMs มาพร้อมกับเปลี่ยนความต้องการผลิตภัณฑ์ครึ่งหนึ่งของคุณคุณอาจต้องถอดบล็อกบางส่วนออกวางบนชั้นวางแล้ววาดใหม่ (เช่นเมื่อสร้างปราสาทคุณอาจไม่ได้ใช้ทั้งหมด ถังของคุณ) แต่ ณ จุดนั้นนั่นเป็นเพียงส่วนหนึ่งของการทำธุรกิจ ความต้องการเปลี่ยนแปลงและด้วยการรักษารหัสของคุณให้มีความยืดหยุ่นและเป็นโมดุลคุณควรจะสามารถเปลี่ยนผลิตภัณฑ์ให้สอดคล้องกับทิศทางธุรกิจใหม่ของคุณได้
ฉันเชื่อว่าวิธีการวิวัฒนาการในการออกแบบทำงานได้กับทักษะของวิศวกรทุกระดับ โดยส่วนตัวฉันได้ทำซอฟต์แวร์มาเป็นเวลานานและก่อนที่ทีมของเราจะเปลี่ยนไปใช้วิธีการแบบเปรียวฉันต้องรับผิดชอบในการจัดส่งส่วนประกอบที่สำคัญหลายอย่างจากพีซี dev ของฉันไปยังลูกค้าโดยตรงแทบจะไม่มี QA ใด ๆ ในขณะเดียวกันส่วนประกอบเหล่านั้นยังคงมีความยืดหยุ่นและบำรุงรักษาได้อยู่เสมอ
ฉันแค่พยายามจะบอกว่าฉันคิดว่าตัวเองค่อนข้างดีในการออกแบบซอฟต์แวร์ ในเวลาเดียวกันถ้าคุณขอให้ฉันเขียนเอกสารการออกแบบ 100 หน้ามอบให้ coder และคาดหวังให้มันทำงานฉันอาจไม่สามารถออกแบบตัวเองออกจากถุงกระดาษได้ เมื่อเริ่มทำงานบางครั้งฉันจะร่างไดอะแกรม UML ที่คล้ายกัน (ง่ายมากไม่เต็มภาษา) แต่เมื่อฉันเริ่มเขียนโค้ดฉันจะ refactor ตามความต้องการและรหัสสุดท้ายของฉันจะไม่เหมือนที่ฉันวาด แม้ว่าฉันจะใช้เวลาหนึ่งหรือสองเดือนคิดเกี่ยวกับรายละเอียดเล็ก ๆ น้อย ๆ ทุกอย่าง แต่ฉันไม่สามารถถ่ายภาพคนอื่นที่สามารถนำไดอะแกรมของฉันมาใช้กับซอฟต์แวร์ที่เป็นของแข็งได้โดยไม่ต้องดัดแปลงการออกแบบเนื่องจากพวกเขากำลังเขียนโค้ด
อีกด้านหนึ่งของสเปกตรัมปัจจุบันในทีมของฉัน (ตอนนี้เปรียวและฉันสนับสนุนอย่างเต็มที่) เรามีผู้ชายสองคนที่เข้าร่วมกับเราจากดินแดนฝังตัวที่พวกเขาทำ C ในช่วง 15 ปีที่ผ่านมา เห็นได้ชัดว่าฉันช่วยในการวางแผนเริ่มต้นและออกชั้นเรียน แต่ฉันก็แน่ใจว่าได้ติดตามความคิดเห็นเกี่ยวกับรหัสปกติและการประชุมระดมสมองที่เราจะพูดคุยเกี่ยวกับการประยุกต์ใช้ SOLID และหลักการออกแบบ พวกเขาสร้างรหัสสปาเก็ตตี้ที่ทำให้ฉันประจบประแจงเพียงเล็กน้อย แต่ด้วยความดุดันเล็กน้อยจากฉันพวกเขาเริ่มต้นการซ่อมแซมสิ่งที่ผลิตไปแล้วและส่วนที่ตลกคือหนึ่งในนั้นกลับมาหาฉันในไม่กี่วันต่อมาและพูดว่าฉันเกลียด ที่จะพูด แต่หลังจากที่ย้ายรหัสนั้นออกไปแล้วจะมีลักษณะที่สามารถอ่านและเข้าใจได้ง่ายขึ้น หันหน้าไปทาง Dead-end จุดที่ฉัน พยายามทำคือแม้แต่คนที่ใหม่ OO สามารถสร้างรหัสที่ค่อนข้างดีตราบใดที่เขามีที่ปรึกษาที่มีประสบการณ์มากกว่าเพื่อเตือนเขาว่า "การออกแบบวิวัฒนาการ" ไม่เหมือนกับ "ไม่มีการออกแบบ" และแม้กระทั่งบางส่วนของ "ความซับซ้อนมากขึ้น" ของเขาก็ไม่ได้น่ากลัวเพราะแต่ละชั้นไม่มีความรับผิดชอบมากขนาดนั้น (นั่นคือไม่ได้รหัสมาก) ดังนั้นที่เลวร้ายที่สุดมาถึงเลวร้ายยิ่งถ้าชั้นหนึ่ง "ปลายตาย" เรา เชยและเขียนคลาสทดแทนที่มีส่วนต่อประสานสาธารณะแบบเดียวกัน (จนถึงตอนนี้ฉันไม่เคยเห็นความจำเป็นที่จะเกิดเหตุการณ์นี้ในทุกสิ่งที่เราเขียนและฉันทำรีวิวโค้ดสองครั้งต่อสัปดาห์)
ในฐานะที่เป็นบันทึกสุดท้ายฉันยังเชื่อมั่นในการออกแบบเอกสาร (อย่างน้อยสำหรับเงื่อนไขทางธุรกิจของทีมปัจจุบันของฉัน) แต่เป้าหมายหลักสำหรับเอกสารการออกแบบของเราคือหน่วยความจำขององค์กรดังนั้นเอกสารจริงจะถูกเขียนหลังจากสร้างรหัสและ refactored ก่อนการเข้ารหัสเรามักจะมีขั้นตอนการออกแบบที่รวดเร็ว (บางครั้งก็ไม่เร็ว) ที่เราร่างคลาสบนผ้ากันเปื้อน / mspaint / visio และฉันมักจะเตือนผู้คนว่าขั้นตอนนี้สร้างเส้นทางที่จะติดตามไม่ใช่พิมพ์เขียวและเมื่อพวกเขาเริ่มเขียนโปรแกรม ควรเปลี่ยนสิ่งใดที่ไม่สมเหตุสมผล ถึงแม้จะมีการเตือนความจำเหล่านี้คนรุ่นใหม่มักจะพยายามใส่รหัสกลับเข้าไปในการออกแบบดั้งเดิม สิ่งนี้มักจะแสดงในบทวิจารณ์โค้ด
แดงฉันเขียนมาก ขอโทษสำหรับเรื่องนั้น.