บลิกิ: ConwaysLaw

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

ผู้เขียนน่าจะระบุกฎหมายได้ดีที่สุดว่า: [1]

องค์กรใดๆ ที่ออกแบบระบบ (กำหนดอย่างกว้างๆ) จะสร้างการออกแบบที่มีโครงสร้างเป็นสำเนาของโครงสร้างการสื่อสารขององค์กร

— เมลวิน คอนเวย์

กฎของคอนเวย์เป็นการสังเกตว่าสถาปัตยกรรมของระบบซอฟต์แวร์นั้นมีความคล้ายคลึงกันอย่างมากกับองค์กรของทีมพัฒนาที่สร้างมันขึ้นมา เดิมทีอธิบายกับผมว่าถ้าทีมเดียวเขียนคอมไพเลอร์ก็จะเป็นคอมไพเลอร์แบบ one-pass แต่ถ้าแบ่งเป็นสองทีมก็จะเป็นคอมไพเลอร์แบบ two-pass แม้ว่าโดยปกติเราจะพูดคุยกันเกี่ยวกับซอฟต์แวร์ แต่การสังเกตก็นำไปใช้อย่างกว้างขวางกับระบบโดยทั่วไป [2]

ตามที่เพื่อนร่วมงานของฉัน Chris Ford พูดกับฉัน: “Conway เข้าใจว่าการเชื่อมต่อซอฟต์แวร์เปิดใช้งานและสนับสนุนโดยการสื่อสารของมนุษย์” ถ้าฉันสามารถพูดคุยกับผู้เขียนโค้ดได้อย่างง่ายดาย ฉันก็จะสร้างความเข้าใจที่สมบูรณ์เกี่ยวกับโค้ดนั้นได้ง่ายขึ้น วิธีนี้ทำให้โค้ดของฉันโต้ตอบได้ง่ายขึ้น และรวมเข้ากับโค้ดนั้นได้ง่ายขึ้น ไม่เพียงแค่ในแง่ของการเรียกใช้ฟังก์ชันที่ชัดเจนเท่านั้น แต่ยังรวมถึงสมมติฐานที่ใช้ร่วมกันโดยนัยและวิธีคิดเกี่ยวกับโดเมนของปัญหาด้วย

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

คนโหลหรือสองคนสามารถมีการสื่อสารที่ลึกซึ้งและไม่เป็นทางการ ดังนั้น Conways Law จึงระบุว่าพวกเขาจะสร้างเสาหิน ไม่เป็นไร – กฎของ Conway จึงไม่ส่งผลต่อความคิดของเราสำหรับทีมขนาดเล็ก ถึงเวลาที่มนุษย์จำเป็นต้องจัดระเบียบกฎของคอนเวย์ควรส่งผลต่อการตัดสินใจ

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

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

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

การยอมรับกฎหมายของคอนเวย์ดีกว่าการเพิกเฉย และในทศวรรษที่ผ่านมา เราได้เห็นวิธีที่สามในการตอบสนองต่อกฎหมายนี้ ที่นี่เราจงใจเปลี่ยนโครงสร้างองค์กรของทีมพัฒนาเพื่อสนับสนุนสถาปัตยกรรมซอฟต์แวร์ที่ต้องการ วิธีการที่เรียกว่า Inverse Conway Maneuver [3] แนวทางนี้มักถูกพูดถึงในโลกของ ไมโคร เซอร์วิส ซึ่งผู้สนับสนุนแนะนำให้สร้างทีม BusinessCapabilityCentric ขนาดเล็กที่มีอายุยืนยาว ซึ่งมีทักษะทั้งหมดที่จำเป็นในการส่งมอบคุณค่าให้กับลูกค้า การจัดทีมที่เป็นอิสระด้วยวิธีนี้ เราใช้กฎหมายของ Conway เพื่อส่งเสริมบริการอิสระที่คล้ายคลึงกันซึ่งสามารถปรับปรุงและปรับใช้อย่างเป็นอิสระจากกัน นี่คือเหตุผลที่ฉันอธิบายไมโครเซอร์วิสเป็นเครื่องมือในการจัดโครงสร้างองค์กรเพื่อการพัฒนาเป็นหลัก

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

สิ่งสำคัญที่ต้องจำเกี่ยวกับกฎหมาย Conways คือการสลายตัวแบบแยกส่วนของระบบและการสลายตัวขององค์กรการพัฒนาต้องทำร่วมกัน นี่ไม่ใช่เพียงจุดเริ่มต้น วิวัฒนาการของสถาปัตยกรรมและการปรับโครงสร้างองค์กรของมนุษย์จะต้องจับมือกันตลอดชีวิตขององค์กร