"ตัวแปรที่สำคัญมากในการตัดสินใจด้าน technical คือเรื่องมนุษย์"
เมื่อวานเห็นพี่เนยเขียนประมาณว่า PHP ไม่ใช่ภาษาที่เลวร้ายอะไรในตัวมันเอง มันมีหลายกรณีที่สามารถนำมาใช้แก้ปัญหาได้จริง แต่ community ในไทยมี stigma ที่จะรังเกียจ PHP ว่าเป็นภาษาที่แย่ ห้ามใช้ ใครใช้จะโดนล้อ
เราว่าเหตุผลที่มันเกิด stigma กับภาษาจำพวก PHP หรือ JavaScript ปัญหามันไม่ได้มาจากที่คนไม่ชอบ language design เพียงอย่างเดียวหรอก ส่วนใหญ่จะเป็นเรื่องของภาพจำที่เกิดจากวิธีการสอน หนังสือ หรือ tutorials ที่คนเห็นกัน
สมัยก่อนถ้าเราไปอ่าน PHP หรือ JavaScript tutorial จะเจอว่ามันส่งเสริม bad practices and design decisions ที่จะเกิดปัญหาเมื่อโปรเจคเริ่มสเกลใหญ่ขึ้น เช่นการใช้ global variables, การเอา business logic และ query logic ไปยำรวมกันกับ presentation logic ในที่เดียวกัน หรือ practice ที่ทำให้เกิด vulnerability แบบการไม่ใช้ prepared statements แล้วเอา string มายัดตรงๆ
ถามว่าการออกแบบภาษามีส่วนผิดไหม มีส่วนอยู่แล้ว ยังไงเราก็อยากได้ภาษาที่มันไม่มี pitfalls พวก type coercion (แบบ JS ที่ 1 + '1' กลายเป็น 11) หรือมี inconsistencies เยอะอยู่แล้ว ทุกคนต่างอยากได้ภาษาที่ออกแบบมาดีแน่นอ
แต่ถ้าคนเขียนโค้ดรู้ good practices อยู่แล้ว หรือเลือกไปใช้ frameworks ที่มัน encourage good practice เช่น Laravel ก็คงแทบไม่มีปัญหาถ้าสเกลมันไม่ได้ใหญ่จนเกินขีดจำกัดของ runtime เดี๋ยวนี้ส่วนใหญ่ก็แก้ที่ฝั่ง architecture ได้
หรืออย่างคนเขียน JS สมัยนี้ก็เริ่มใช้ประโยชน์จาก type checking ใน editor เยอะขึ้นเรื่อยๆ เริ่มย้ายไปใช้ TypeScript และเข้าใจวิธีการออกแบบโค้ดที่ดีมากขึ้น ทำให้เราไม่เคยเจอปัญหาหรือ Pitfalls จาก JavaScript เวลาทำงานกับคนในทีมเลย
งานในโลกนี้มันมีหลายประเภท งานบางอย่างมัน quick and dirty อยากขึ้นแบบเร็วๆ หาคนมารับงานต่อได้ง่าย ถ้าใช้ PHP ขึ้นงานแบบเร็วๆ แล้วรับ good PHP developers มันก็คงไม่มีปัญหาอะไร
แต่ในทางกลับกัน PHP community ในไทยที่หลายๆ คนเจอมา อาจไม่ได้ให้ความสำคัญกับเรื่อง code architecture เยอะเท่ากับกลุ่มอื่นๆ
ถ้าเกิด first language ของคนคนนึงคือ PHP แล้วเค้าไปอ่าน tutorial ที่คนเขียนสมัยก่อนๆ หรือที่มีบางคนเขียนแบบผิดๆ พอมาทำงานด้วยกันแล้วก็จะเจอว่ามันทำโค้ดให้ maintain ต่อในระยะยาว และ follow good software design practices ได้ยากมาก
แต่นี่ก็เป็นปัญหาเรื่องมนุษย์หรือเปล่า?
วิธีแก้ปัญหาเรื่องนี้คือการพัฒนา community และทำ tutorials/resources ให้ดีขึ้นมากกว่า เพราะ language design มันก็พัฒนาให้ดีขึ้นทุกวันอยู่แล้ว แค่เราต้องรู้ว่าอะไรเหมาะกับอะไร
สิ่งที่สำคัญคือ ถ้าทุกคนยังมองแบบ dogmatic อารมณ์แบบ "ยี้ PHP ภาษาไม่ดี ไม่เอาเด็ดขาด" สุดท้ายเราก็จะมี stigma กับมัน ไม่ยอมอนุญาตให้ทีมใช้ แล้ว productivity ก็ลดฮวบ ทั้งๆ ที่ทีมก็ใช้ Laravel กัน เขียนเทสต์กันอย่างดี
เวลาตัดสินใจเรื่องเทคโนโลยี อย่า dogmatic แต่ให้ skeptic ไว้เยอะๆ ว่ามันไม่ดีจริงเหรอ ทำไมมันถึงไม่ดี ทำไมมันถึงจะไม่เหมาะกับเคสนี้ ถ้าเราอยากเป็น developer ที่ดีจริงๆ ก็ต้องทำความเข้าใจว่า pitfalls และ limitations มันอยู่ที่ไหน และมันเสี่ยงต่อทีมเราขนาดนั้นเลยหรือเปล่า?
(แต่อีกเคส เราก็เคยเจอบางบริษัทรับ Clojure developers มา แล้วสุดท้ายก็ให้มาเขียน JavaScript กลายเป็นว่าเขียนโค้ดสวยมาก แต่เค้าก็อาจจะนอยด์พอสมควร มันก็เป็นการ filter คนไปอีกแบบ เพราะบริษัทอาจเชื่อว่า Clojure devs มีแนวโน้มที่จะเข้าใจ good code architecture มากกว่า)
สำหรับเรา เราเลยเชื่อว่าเวลาเลือกเทคโนโลยีอะไร เรื่องมนุษย์ก็เป็นปัจจัยสำคัญมาก
ถ้าเรามีทีมอยู่แล้ว หนึ่งในตัวแปรที่ควบคุมได้คือการเลือกสิ่งที่เข้ากับทีม คนในทีมถนัด มีความสุขที่จะใช้ สามารถเขียนมันได้ในเวลาที่เร็วตามความต้องการของเรา แต่ก็ต้องเข้ากับ business requirement ของงานด้วย
ยกตัวอย่างเช่น ถ้าคนในทีมอาจจะมีความสุขกับการใช้ภาษาที่ functional มากกว่า เช่น Clojure, Scala หรือ F# แล้วเราวิเคราะห์ว่างานเรามันเน้น data transformation เยอะๆ แต่ไม่ต้องเร็วแบบ real-time ก็ให้ทีมใช้ได้ชิวๆ
แต่ถ้าสมมุติคนในทีมส่วนมากบอกว่า เออฉันถนัดกับการเขียน Go มากกว่า ไม่ได้อินกับ FP มากขนาดนั้น แล้วเราวิเคราะห์แล้วว่าจริงๆ งานที่เราทำมันก็ไม่ได้ transform data ซับซ้อนอะไรขนาดนั้นนี่หว่า ก็ให้ทีมใช้ได้ชิวๆ
เคสที่น่าเศร้าคือ ถ้าคนในทีมเราถนัดเขียน PHP กันหมด เขียนกันสวยด้วยนะ แต่ team lead ไม่คิดถึง element เรื่องมนุษย์ ความสุขของคนโค้ด และความเป็นไปได้ในการจ้าง แต่มี stigma กับมัน แล้วไปเน้น ideal ว่าฉันต้องเอาภาษา XYZ เท่านั้น มันดีที่สุด สุดท้ายทีมก็ต้องไปเสียเวลา re-learn อาจจะไม่แฮปปี้ แล้วอาจจะไม่ productive เท่า PHP ด้วย
เราว่าในปัจจุบัน ภาษาในโลกมันแทบจะมี capabilities เทียบเท่ากันเกือบหมดแล้ว แถม cost ของการจ้าง devs มันก็สูง จนความแตกต่างด้าน scaling ในแต่ละภาษามันเป็นปัจจัยน้อยลงทุกวัน ในยุคที่มีอะไรก็ยัดใส่ cloud run โยนใส่ k8s
แต่ถ้าเรายังไม่มีทีม เราก็เลือกตามความต้องการของธุรกิจ และความ practical ว่าถ้าเราจะทำโปรเจค Clojure เราจะหาคนมา maintain ได้มั้ย cost เท่าไหร่
อีกเคสนึงที่น่าสนใจ คือพี่ไทบอกว่า "ถ้าเป็นโปรเจคเล็กๆ ก็ query ที่ระดับ router ได้ เพราะมันเริ่มต้นง่ายกว่า พอโปรเจคสเกลแล้วค่อยๆ refactor ก็ได้ ค่อยเพิ่ม abstraction layer ค่อยๆ ปรับ architecture ไป"
ซึ่งอันนี้เราก็เห็นด้วยอีก ถ้าคนในทีมเรารู้ตรงกันว่า เออ อันนี้เพิ่งเริ่มต้นนะ เดี๋ยวต่อจากนี้ต้อง refactor นะ อาจจะด้วยทั้งการสื่อสารในทีม และด้วยทักษะด้าน code architecture ที่คนในทีมมี จนมันเกิด intuition ว่าถึงจุดไหนควร refactor
ในทางกลับกัน เราเคยพูดแบบขำๆ ไว้ว่า "JavaScript เป็นภาษาที่ดีถ้าเราเขียนคนเดียว"
เราเชื่อว่าในทีมส่วนมาก น้อยคนในทีมจะมีความรู้ด้านนี้ เราเชื่อว่าคนส่วนมากที่เพิ่งเข้ามาแตะ codebase ก็จะ copy-paste โค้ดที่คนก่อนเขียนไว้ให้มันใช้งานได้ ด้วยประสบการณ์และทักษะ หลายคนกลัวที่จะเปลี่ยนโค้ดหรือเพิ่ม abstraction layer ด้วยซ้ำ ทำให้ evolution ที่มันควรจะเกิดขึ้นถ้าเราเขียนโค้ดคนเดียว มันก็ไม่เกิดขึ้นในทีม ถ้าเกิดเราหายจากโปรเจคนั้นไปพักนึง แล้วไม่สื่อสารไว้ก่อน
หลายๆ คน รวมถึงเราเอง ก็เลยเลือกที่จะทำ architecture ให้มันมี abstraction เพิ่มขึ้นระดับนึงตั้งแต่ช่วงแรกๆ (หลังจากที่ proof-of-concept/prototype ผ่านแล้ว) เช่นเอา DDD (domain-driven design) หรือเอา design pattern พวก Repository Pattern ที่เป็นมาตรฐานมาใช้ เพราะเชื่อว่ายังไงมันก็จะ evolve มาถึงจุดนั้น
เรื่องนี้เราว่าเป็นเรื่องของคนอีก มันคือเรื่องความเชื่อใจ ว่าเราจะเอา convention มา safeguard คนขนาดไหน มันคือ trade-off ระหว่างการให้อิสระคนเขียน (developer freedom) กับการ enforce structure ไปเลย เพื่อให้มั่นใจว่าจะรองรับทุกเคส
นึกถึง React versus Angular หรือ Express versus Nest.js มันคนละ ideology กันเลย เราจะให้ความสำคัญกับเรื่องอะไรมากกว่า
ถ้าเราอยู่ในทีมที่เราเชื่อใจกันว่า ทุกคน follow boy scout rule ทุกคนจะทำโค้ดให้มันดีขึ้นกว่าที่มันเป็น และไม่ถูก deadline ทำให้เสียอุดมการณ์ไปซะก่อน มันก็ไม่จำเป็นจะต้อง design upfront หรือสร้าง abstraction layers มาตั้งแต่แรก หลายคนก็อาจเลือกใช้อะไรที่มันให้อิสระในการออกแบบ architecture มากกว่า
แต่จากประสบการณ์ที่เราเจอ ทีมมันร้อยพ่อพันแม่จริงๆ ไม่ใช่ทุกคนที่มีพื้นฐานตรงสาย บางคนเป็น data scientist หรือ operations หรือ 3D developer ที่ไม่ได้มีพื้นด้าน good code architecture แล้วต้องมาแตะโค้ดบางส่วน เราจะเจอทุกครั้งว่าไม่ใช่ทุกคนที่จะมี intuition นี้ แล้วโค้ดส่วนนั้นก็จะมีปัญหาไปเลย หลายคนก็เลือกใช้อะไรที่มี up-front structure แบบ Nest.js
ซึ่งก็เป็นเรื่องคนอีก คนในทีมเรา prefer อะไรมากกว่า ถ้าให้บางคนไปเขียน Go ก็อาจจะไม่แฮปปี้เท่าเขียน Elixir หรือ Clojure แน่นอน
ใน technical discussions เราไม่ค่อยเห็นคนพูดเรื่อง direction เรื่องนี้ของคนในทีมเลย เป็นประเด็นที่น่าคุยกันมากขึ้นเพื่อความสุขในการโค้ดของทุกคน