Architecture with team

เมื่อวันที่ผ่านมาได้มีโอกาสผ่านตาบล็อกนึงที่เขาบอกว่า บริษัทเขาจ้าง Software Architect จากเมืองนอกมา และสิ่งแรกที่เขาทำคือการสำรวจว่า Developer มีกี่คน แต่ละคนมีนิสัยยังไงบ้าง มีการแบ่งแผนกยังไงบ้าง

ซึ่งก็มีหลายคนสงสัยว่า ทำไมออกแบบ Software architecture ต้องรู้เรื่องทีมด้วย

ผมกลับคิดว่านั่นคือปัจจัยสำคัญที่สุดในการออกแบบ Software architecture เลยนะ

“เราออกแบบ Architecture กันไปทำไมนะ”

ตัดศัพท์แสงสวยหรูทั้งหมดออกไป เราออกแบบ Architecture และไม่เขียนโค้ดทั้งหมดรวมกันไว้ที่ Main อย่างเดียวเพราะ

1. ถ้าเขียนรวมกันทั้งหมด มันอ่านไม่รู้เรื่อง
2. ถ้าไม่ออกแบบเลย แล้วคนเข้ามาร่วมทีมเขาจะรู้มั้ยว่าโค้ดอะไรอยู่ตรงไหน แถมจะแก้ตรงนั้นก็กระทบตรงนี้ มึนไปหมด
3. ถ้าไม่ออกแบบโค้ดเลย เวลาทดสอบก็ต้องทดสอบมืออย่างเดียวสิ เราไม่สามารถสร้างชุดทดสอบอัตโนมัติที่ทดสอบแค่ส่วนเดียวของโปรแกรมได้สิ
4. เวลาที่เราต้องการขยายทีม ถ้าทุกคนมารวมยำเขียนโค้ดที่ function, method เดียวกันหมด ตีกันตายเลย

แต่ถ้าพูดแบบหรูๆ เลยคือ

1. Readability
2. Modularity & Reusability
3. Testability
4. Scalability

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

“Architecture ที่ดีมีหน้าตายังไงนะ”

โอเค เรารู้แล้วว่าตกลงทำไมเราต้องมาออกแบบ Architecture ของซอฟต์แวร์กันแล้ว ดังนั้น เวลาที่เราได้ Architecture ที่แก้ปัญหาที่กล่าวไว้ข้างต้น มันควรจะมีลักษณะดังนี้

1. อ่านง่าย (Readability)
2. แต่ละส่วนแยกจากกันและใช้ใหม่ได้ (Reusability & Modularity)
3. ทดสอบได้ง่าย
4. คนในทีมขนาดใหญ่สามารถทำงานร่วมกันได้ง่าย ไม่ตีกัน

จะเห็นว่าจากปัจจัยทั้งหมดนี้ มันมีสองข้อในสี่ข้อเลยนะ ที่เราต้องสนใจทีมและมนุษย์ตัวเป็นๆ

Readability

เมื่อพูดถึงความอ่านง่ายแล้วเนี่ย มันก็มีส่วนนึงที่เป็นสากลตามทฤษฎีของ Information theory เช่นพวก Signal-to-noise ratio หรือพวกที่ว่ามนุษย์เราปราดตามองจากซ้ายไปขวาในระยะอันสั้น หรือว่า Pattern คล้ายกันแล้วไม่ Explicit ลงไปคนจะโดนหลอกง่าย (เช่น มีโค้ดสามบรรทัดที่ Copy กันมา ยาว 150 ตัวอักษร แล้วต่างกันตรงตัวอักษรเดียวตรงตัวอักษรที่ 89 ยังเงี้ย ยังไงก็อ่านเห็นยาก)

แต่ทีนี้อีกส่วนนึงมันก็อยู่ที่ตัวคนด้วย ว่ามีลักษณะยังไง คุ้นเคยกับการอ่านแบบไหน ไม่คุ้นเคยกับการอ่านแบบไหน

ผมไม่ยกตัวอย่างโปรแกรมมิ่งละกัน ผมยกตัวอย่างโลกจริง

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

เราจะบอกให้ทั้งโลกเปลี่ยนเป็นภาษาละตินให้หมด เผาหนังสือภาษาไทยภาษาอังกฤษทิ้งเหรอ?

มันไม่ใช่นะ? ทำแบบนั้นนอกจากโลกจะไม่ Productive ขึ้นแล้วยังน่าจะอลหม่านสุดๆ

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

มันต้องเริ่มจากจุดเล็กๆ อย่าง เห้ย งานประชุมวิชาการบางอันก็เริ่มให้เขียนบทความภาษาละติน งานสนทนาทางการบางอันก็ Adapt ภาษาละตินมาใช้บ้าง

มันจะค่อยๆ เริ่มเป็น Incremental step เล็กๆ แบบนี้ไปเรื่อยๆ

โปรแกรมมิ่งก็เหมือนกัน

ถ้าคุณไม่รู้ว่าทีมคุณปัจจุบันอยู่จุดไหน แต่คุณแค่เอามาโยนว่า

“เนี่ย ภาษาเนี้ย พิสูจน์มาแล้วว่าเจ๋งสุด พวกคุณต้องเรียนให้ได้”

“Design pattern เนี้ยดีสุด ไปเรียนซะ”

มันเป็นไปไม่ได้

เหมือนอยู่ดีๆ ทั้งโลกบอกเผาหนังสือภาษาอังกฤษทิ้งหมด โลกไม่ Productive ขึ้นฉันใด การโยนลงไปตูมแบบนั้นก็ไม่ได้ทำให้ทีม Productive ขึ้นฉันนั้น

มันต้องมี Incremental step ในการเปลี่ยนแปลงไปสู่สิ่งที่ดีกว่า

ซึ่งถ้าเราไม่สังเกต “คน” ตัวเป็นๆ ไม่เอาเรื่องทีมเข้ามาพิจารณาเลย

เราจะพาตัวเองไปสู่จุดที่ดีกว่าได้เหรอ?

เราก็จะได้แต่วาดฝันในอากาศว่า Architecture ที่ดีต้องเป็นแบบนั้นแบบนี้ แต่ทำจริงไม่ได้

Scalability

เรื่องของการสเกลก็เป็นอีกเรื่องนึงที่น่าสนใจ

เพราะมันเป็นคำถามว่า “ถ้าทีมใหญ่ขึ้นแล้วจะทำงานร่วมกันยังไงให้ไม่ตีกัน”

เราจะต้องมี Process อย่างไรบ้าง Automated test ตรงไหนบ้าง เพื่อจะให้มั่นใจได้ว่า โปรแกรมเมอร์จะทำงานได้อย่างเป็นอิสระ

เราต้องการให้ทีมนึงต้องเรียนรู้กี่ภาษา

แล้วทีมที่มีอยู่ ทีมไหนถ้าจับมาคุยกันทำงานร่วมกันแล้วจะลำบาก ทีมไหนที่จริงๆ เดิมทีก็แทบจะทำงานด้วยกันตลอดเวลาอยู่แล้ว

ข้อมูลพวกนี้เป็นสิ่งสำคัญในการตอบว่าแล้วเราจะแบ่งโค้ดยังไง ใช้ Microservices กี่ตัว เราจะ Deploy แยกกันหรือ Deploy รวมกัน

ถ้า Microservice ที่มัน Depend on กันมากๆ อยู่ในสองทีมที่ติดต่อกันลำบาก เช่น ทีมนึงพูดภาษาเกาหลี ทีมนึงพูดภาษาอินเดีย ยังงี้ Producitivity ไม่ยิ่งลดเหรอ

มันมีปัจจัยเรื่องคนเข้ามาเยอะเลยนะ

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

เราพูดถึง Modularity, Reusability, Blahblahbility ทุกอย่างเลย ยกเว้นคน

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

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

เอิ่มมมมมมม

ผมอยากให้เวลาเราพูดถึง Architecture เราไม่ลืมเป้าหมาย

เราอยากให้ชีวิตเพื่อนๆ โปรแกรมเมอร์ในทีมดีขึ้น

ศัพท์แสงทั้งหลาย Blahblahbility ทั้งหมดมันเป็นแค่เครื่องมือพาไปสู่สิ่งนั้น

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

“เราออกแบบ Architecture กันไปทำไมนะ”