Architect Personalities (บุคลิกของสถาปนิก)

เราจะขอสรุปแบบกว้างๆ เพื่อความชัดเจนของแนวคิด และขอบอกว่าบุคลิกของสถาปนิกมีอยู่สามแบบพื้นฐาน คือ control-freak architect , armchair architect และ effective architect สถาปนิกแบบ control-freak มักสร้างขอบเขตที่แคบ สถาปนิกแบบ armchair มักสร้างขอบเขตที่หลวม และสถาปนิกที่มีประสิทธิภาพจะสร้างขอบเขตที่เหมาะสม ส่วนต่อไปนี้จะอธิบายรายละเอียดของบุคลิกสถาปนิกแต่ละแบบ

The Control-Freak Architect (สถาปนิกจอมควบคุม)

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

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

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

ตัวอย่างเช่น สมมติว่าสถาปนิกสร้างคอมโพเนนต์เชิงตรรกะที่จัดการข้อมูลอ้างอิงภายในระบบ เช่น ข้อมูลคู่ชื่อ-ค่าแบบสแตติกที่ใช้บนเว็บไซต์ รหัสสินค้า และรหัสคลังสินค้า บทบาทของสถาปนิกคือการระบุคอมโพเนนต์เชิงตรรกะ (ในกรณีนี้คือ Reference Manager ) กำหนดชุดการดำเนินการหลักของมัน (เช่น GetData , SetData , ReloadCache และ NotifyOnUpdate ) และระบุว่าคอมโพเนนต์อื่นใดบ้างที่ต้องโต้ตอบกับ ReferenceManager สถาปนิกจอมควบคุมอาจคิดว่าวิธีที่ดีที่สุดในการอิมพลีเมนต์คอมโพเนนต์นี้คือผ่านแพทเทิร์น parallel loader โดยใช้แคชภายในร่วมกับโครงสร้างข้อมูลเฉพาะ นี่อาจเป็นการออกแบบที่มีประสิทธิภาพ แต่มันไม่ใช่การออกแบบเดียวที่เป็นไปได้ และที่สำคัญกว่านั้นคือ ไม่ใช่หน้าที่ของสถาปนิกที่จะคิดค้นการออกแบบภายในของ Reference Manager นั่นเป็นหน้าที่ของนักพัฒนา

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

The Armchair Architect (สถาปนิกเก้าอี้นวม)

สถาปนิกเก้าอี้นวมคือสถาปนิกที่ไม่ได้เขียนโค้ดมานานมาก (ถ้าเคยเขียนเลย) และไม่คำนึงถึงรายละเอียดการอิมพลีเมนต์เวลาสร้างสถาปัตยกรรม พวกเขามักตัดขาดจากทีมพัฒนาและแทบไม่ปรากฏตัว เพียงแค่ย้ายไปโครงการถัดไปทันทีที่ทำไดอะแกรมสถาปัตยกรรมเบื้องต้นเสร็จ

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

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

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

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

• ไม่เข้าใจโดเมนธุรกิจ ปัญหาทางธุรกิจ หรือเทคโนโลยีที่ใช้อย่างถ่องแท้

• ไม่มีประสบการณ์ลงมือพัฒนาซอฟต์แวร์จริงมากพอ

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

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

The Effective Architect (สถาปนิกที่มีประสิทธิภาพ)

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

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