รสนิยมที่ดีในงานวิศวกรรมเป็นคนละเรื่องกับฝีมือ [บทความแปล]

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

รสนิยมเป็นคนละเรื่องกับฝีมือ

• รสนิยมทางเทคนิคก็เหมือนรสนิยมด้านอาหาร เป็นความรู้สึกที่แยกจากฝีมือได้ โดยแม้จะเขียนโค้ดเก่งไม่ได้โดยตรง ก็ยังแสดงออกผ่านความสามารถในการแยกแยะว่า “โค้ดนี้ดูดี/ไม่ชอบ”, “การตัดสินใจด้านการออกแบบนี้ถูกใจ/ยังรู้สึกก้ำกึ่ง” ได้
• การเลือกอย่าง for loop vs map/filter ไม่ใช่เรื่องที่มีเทคโนโลยีไหนเหนือกว่าอย่างสัมบูรณ์ แต่เป็นเพียงความต่างของรสนิยมที่ขึ้นกับว่าต่างฝ่ายให้ความสำคัญกับคุณค่าอะไรเป็นหลักมากกว่า เช่น readability, simplicity, performance เป็นต้น และสุดท้ายวิศวกรก็มักตัดสินตามชุดคุณค่าที่ตนเองยึดถือ

รสนิยมทางวิศวกรรม = ลำดับความสำคัญของคุณค่า

• การตัดสินใจส่วนใหญ่ในวิศวกรรมซอฟต์แวร์คือปัญหาเรื่อง trade-off ระหว่างคุณค่าต่าง ๆ เช่น performance, readability, correctness, flexibility, scalability, resilience, portability, development speed และไม่บ่อยนักที่จะมีตัวเลือกใดถูกต้องแบบสมบูรณ์เพียงด้านเดียวเสมอไป
• รสนิยมของวิศวกรคนหนึ่งถูกนิยามจากการให้ความสำคัญกับคุณค่าเหล่านี้ว่าอะไรควรมาก่อนแค่ไหน เช่น หากให้ความสำคัญกับความเร็วและความถูกต้องมากกว่าความเร็วในการพัฒนา ก็อาจโน้มเอียงไปหารัสต์หรือคลาวด์บางแบบ และถ้าให้ความสำคัญกับ resilience มากกว่าความเร็ว ก็จะเลือกแนวทางอย่างการกระจายหลายรีเจียนโดยเป็นธรรมชาติ

รสนิยมที่ไม่ดี: การบูชา ‘best practice’ แบบไร้ความยืดหยุ่น

• รสนิยมที่ไม่ดีคือการที่คุณค่าที่คนนั้นชอบไม่สอดคล้องกับโปรเจกต์ปัจจุบัน แต่ยังคงผลักดันวิธีการที่เชื่อว่าเคยได้ผลในอดีต (เช่น formal verification, การเขียนใหม่ด้วยภาษาใดภาษาหนึ่ง, multi-region ที่มากเกินไป, metaprogramming ที่ซับซ้อนเกินจำเป็น) โดยไม่สนบริบท
• คนกลุ่มนี้มักอาศัยมาตรฐานสัมบูรณ์อย่าง “นี่คือ best practice” เพื่อทำให้การเลือกของตนดูชอบธรรม และแม้จะทำงานได้ดีในสถานการณ์เฉพาะ แต่เมื่อบริบทเปลี่ยน ก็อาจพาทีมไปผิดทางได้ เหมือนเข็มทิศที่คลาดทิศ

รสนิยมที่ดี: การเลือกคุณค่าให้เหมาะกับบริบทและมีความยืดหยุ่น

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

วิธีพัฒนารสนิยมที่ดี

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