Balancing Architecture and Hands-On Coding (การสร้างสมดุลระหว่าง Architecture และการเขียนโค้ดจริง)

หนึ่งในงานที่ยากที่สถาปนิกต้องเผชิญคือการสร้างสมดุลระหว่างการเขียนโค้ดจริงกับ software architecture เราเชื่ออย่างแน่วแน่ว่าสถาปนิกทุกคนควรเขียนโค้ด และควรรักษา technical depth ในระดับหนึ่งไว้ (ดู “Technical Breadth” ) แม้เรื่องนี้อาจดูเหมือนเป็นงานง่าย แต่บางครั้งมันก็ยากพอสมควรที่จะทำได้จริง

เคล็ดลับแรกของเราสำหรับใครก็ตามที่พยายามสร้างสมดุลระหว่างการเขียนโค้ดจริงกับการเป็น software architect คือการหลีกเลี่ยง Bottleneck Trap Bottleneck Trap antipattern เกิดขึ้นเมื่อสถาปนิกเข้าครอบครองโค้ดที่อยู่ใน critical path ของระบบ (มักเป็นโค้ด framework พื้นฐานหรือส่วนที่ซับซ้อนกว่า) และกลายเป็น bottleneck ให้กับทีม สิ่งนี้เกิดขึ้นเพราะ สถาปนิกไม่ใช่นักพัฒนาเต็มเวลา จึงต้องสร้างสมดุลระหว่างงานพัฒนา (เช่นการเขียนและทดสอบซอร์สโค้ด) กับบทบาทสถาปนิก (การวาด diagram, การเข้าประชุม และก็, การเข้าประชุมมากขึ้นอีก)

วิธีหนึ่งในการหลีกเลี่ยง Bottleneck Trap คือให้สถาปนิกมอบหมายส่วนสำคัญของระบบให้กับคนอื่นในทีมพัฒนา แล้วมุ่งเน้นไปที่การเขียนโค้ดฟังก์ชันทางธุรกิจส่วนย่อย (เช่น service หรือหน้าจอ UI) หนึ่งถึงสาม iteration ข้างหน้า สิ่งนี้ส่งผลดีสามอย่าง อย่างแรก สถาปนิกได้รับประสบการณ์ลงมือจริงจากการเขียน production code ในขณะที่หลีกเลี่ยงการกลายเป็น bottleneck ให้กับทีม อย่างที่สอง critical path และโค้ด framework ถูกกระจายไปยังทีมพัฒนา (ที่ที่มันควรอยู่) ทำให้ทีมมีความเป็นเจ้าของและเข้าใจส่วนที่ยากกว่าของระบบดีขึ้น อย่างที่สาม และอาจสำคัญที่สุด สถาปนิกกำลังเขียนซอร์สโค้ดที่เกี่ยวกับธุรกิจแบบเดียวกับที่ทีมพัฒนาเขียน สิ่งนี้ช่วยให้พวกเขาเข้าใจปัญหาของทีมพัฒนาเกี่ยวกับ process, procedure และสภาพแวดล้อมการพัฒนาได้ดีขึ้น (และหวังว่าจะทำงานเพื่อปรับปรุงสิ่งเหล่านั้น)

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

Frequent proofs-of-concept (Proof-of-concept บ่อยๆ)

การทำ proof-of-concept (POC) บ่อยๆ ต้องการให้สถาปนิกเขียนซอร์สโค้ด มันยังช่วยตรวจสอบความถูกต้องของ architecture decision โดยพิจารณารายละเอียดการ implement ด้วย ตัวอย่างเช่น สมมติว่าสถาปนิกติดอยู่กับ การเลือกระหว่าง caching solution สองตัว วิธีที่ได้ผลวิธีหนึ่งในการช่วยตัดสินใจคือการพัฒนาตัวอย่างที่ใช้งาน ได้จริงในแต่ละ caching product แล้วเปรียบเทียบผลลัพธ์ สิ่งนี้ทำให้สถาปนิกเห็นรายละเอียดการ implement และปริมาณความพยายามที่ต้องใช้ในการพัฒนา solution เต็มรูปแบบด้วยตาตัวเอง มันยังทำให้พวกเขาเปรียบเทียบ architectural characteristic ระหว่าง caching solution ที่ต่างกันได้ดีขึ้น เช่น scalability, performance และ fault tolerance โดยรวม

เมื่อใดก็ตามที่เป็นไปได้ สถาปนิกควรเขียนโค้ดที่มีคุณภาพระดับ production ที่ดีที่สุดเท่าที่ทำได้ เราแนะนำ practice นี้ด้วยเหตุผลสองข้อ อย่างแรก บ่อยครั้งที่โค้ด proof-of-concept แบบ “ใช้แล้วทิ้ง” เข้าไปอยู่ใน source code repository และกลายเป็น reference architecture หรือตัวอย่างชี้นำให้คนอื่นทำตาม สิ่งสุดท้ายที่สถาปนิกคนไหนอยากให้เกิดขึ้นคือการที่โค้ดใช้แล้วทิ้งที่เขียนอย่างลวกๆ ถูกมองว่าเป็นตัวแทน คุณภาพงานทั่วไปของพวกเขา อย่างที่สอง การเขียนโค้ด proof-of-concept ที่มีคุณภาพระดับ production หมายถึงการได้ฝึกฝนเขียนโค้ดที่มีคุณภาพและมีโครงสร้างที่ดี แทนที่จะพัฒนานิสัยการเขียนโค้ดที่ไม่ดีอย่างต่อเนื่อง จากการสร้าง POC แบบรวดเร็วและลวกๆ

Tackle technical debt (จัดการ Technical Debt)

อีกวิธีหนึ่งที่สถาปนิกยังคงลงมือทำจริงได้คือการจัดการ technical debt บางส่วน ปลดปล่อยให้ทีมพัฒนาทำงาน กับ user story เชิงฟังก์ชันที่สำคัญได้ Tech debt มักมีความสำคัญต่ำ ดังนั้นถ้าสถาปนิกไม่มีโอกาส ทำงาน technical debt ให้เสร็จภายใน iteration ที่กำหนด ก็ไม่ใช่จุดจบของโลก และโดยทั่วไปจะไม่กระทบ ความสำเร็จของ iteration นั้น

Fix bugs (แก้บั๊ก)

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

Automate (สร้าง Automation)

การใช้ automation ด้วยการสร้างเครื่องมือ command-line และตัววิเคราะห์แบบง่ายๆ เพื่อช่วยทีมพัฒนา ในงานประจำวันเป็นอีกวิธีที่ดีในการรักษาทักษะการเขียนโค้ดจริงไว้ ในขณะที่ทำให้ทีมพัฒนามีประสิทธิภาพมากขึ้น มองหางานที่ทำซ้ำๆ ที่ทีมพัฒนาทำอยู่ แล้วทำ automation ให้ พวกเขาจะขอบคุณสำหรับ automation นั้น ตัวอย่างบางส่วนคือ automated source validator ที่ช่วยตรวจสอบ coding standard เฉพาะที่ lint test อื่นๆ ไม่มี, automated checklist และงาน code-refactoring ที่ทำด้วยมือซ้ำๆ

Automation ในรูปแบบของการวิเคราะห์ architecture และ fitness function เพื่อให้มั่นใจใน vitality และการปฏิบัติตามของ architecture เป็นอีกวิธีที่ดีในการลงมือทำจริง ตัวอย่างเช่น สถาปนิกสามารถเขียนโค้ด Java ใน ArchUnit บนแพลตฟอร์ม Java เพื่อทำ architectural compliance แบบ automated หรือสร้าง fitness function แบบกำหนดเองเพื่อให้มั่นใจใน architectural compliance ในขณะที่ได้รับประสบการณ์ลงมือจริง เราจะพูดถึงเทคนิคเหล่านี้ใน บทที่ 6

Do code reviews (ทำ Code Review)

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