Good Architecture

มีสาส์นจาก CTO ของผม (ผมเป็น CEO ฮ่าๆๆ) ส่งข้ามน้ำข้ามทะเลมาจากสวิต-เซอร์แลนด์ตอนกลางดึกคืนวันอังคารที่ผ่านมาครับ

สตีฟคือ Chief Technology Officer และเป็นหุ้นส่วนใหญ่ของบริษัทที่ผมทำงานอยู่ พวกเรากำลังอยู่ในกระบวนการคิดผลิตภัณฑ์หลักของบริษัท ไอเดียมีบ้าง กำลังจะลงแรงทำระบบจริงขึ้นมา ที่เห็นข้างบนคือแนวคิดของสตีฟครับ

เพราะเค้าเป็นคนที่ชอบและอินกับเรื่องเทคโนโลยีอย่างมาก มีประสบการณ์ออกแบบและสร้างระบบใหญ่ๆมาเยอะ ส่วนใหญ่เป็นระบบจำพวก Core Banking, และ Real-Time Financial Products เค้าจึงให้ความสำคัญอย่างสูงสุดกับการออกแบบโครงสร้างระบบที่ดี

“… for me it is vital that we define an architecture before we start any major project.” — เราต้องวางโครงสร้างที่ดีก่อนเริ่มโปรเจกต์

“good architecture is a clean design methodology which is used for all projects, modularity, and reusability, standard modules, testability, stability” — นี่คือหัวข้อที่เราต้องใส่ใจตอนออกแบบระบบครั้งแรก เพราะ …

“[good architecture supports] scalability — we may be doing small projects at the moment, but who knows. Scalability [and other non-functional requirements] cannot be added afterwards. It must be in from day 1. — บางอย่างเพิ่มเข้ามาภายหลังได้ (พวกฟีเจอร์ทั่วไป) แต่หลายอย่างก็ไม่ได้ถ้าไม่ได้เตรียมไว้ตั้งแต่วันแรกก็จบกัน คนทำงานซอฟต์แวร์ระบบใหญ่ๆมาจะทราบดีว่านี่คือเรื่องจริง

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

“To make money from software development we must minimize the amount of development we do, but maximize the amount of functionality we deliver. A clean architecture based around modularity and maximum reuse is mandatory.” — ถ้าจะทำรายได้จากการพัฒนาซอฟต์แวร์เราจำเป็นต้องลดพลังงานที่เราใช้ในการพัฒนาลงแต่เพิ่มความสามารถของระบบที่เราส่งมอบ นั่นแปลว่าโครงสร้างที่สะอาดเรียบร้อยที่มีพื้นฐานจากส่วนประกอบของระบบที่ถอดประกอบได้ง่ายและการนำส่วนประกอบพวกนั้นกลับมาใช้งานใหม่เป็นเรื่องจำเป็น ย้ำนี่ไม่ใช่ทางเลือกแต่เป็นสิ่งที่ต้องทำ

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

ใครได้โอกาสเริ่มใหม่กับระบบใหม่ ขอให้พยายามหน่อยนะครับ การลงทุนที่โครงสร้างพื้นฐานที่ดีจะให้ผลตอบแทนที่คุ้มค่าเสมอ ผมเชื่อแบบนี้ เพราะบางเรื่องก็แก้ไขภายหลังไม่ได้แล้วเหมือนอย่างที่ CTO ของผมบอก

ป.ล. ใครกำลังจะเริ่มทำโครงการ Re-Write / Re-Architect ลองใช้เวลาสัก 10–15 นาทีอ่านบทความนี้ดูนะครับ Things You Should Never Do, Part I เค้าเขียนไว้ดีมากว่า “ทำไมโครงการ Re-Write ไม่เคยสำเร็จ” — คนเขียนชื่อโจเอล สโพลสกี้ ผู้ให้กำเนิด Trello และ Stack Exchange จะว่าไปผมเป็นหนี้บุญคุณเค้าเยอะเลยนะเนี่ยะ :)

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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ