ในโลกของการทำ software หลาย ๆ ครั้งเราเห็นการทำ performance benchmark เปรียบเทียบภาษาโปรแกรมมิ่งทำนองว่า
ภาษา PHP มันกาก ดูมันกิน RAM เทียบกับ Rust สิ
Ruby โคตรช้าเลย Go เจ๋งกว่าเยอะ!
C เร็วที่สุดแล้ว
benchmark พวกนี้ใช้โชว์พลังของแต่ละภาษาได้ แต่การเป็น developer หรือ software engineer ที่เก่ง ควรนำข้อมูลเหล่านี้มาประกอบการตัดสินใจ ไม่ใช่เลือก tooling โดย performance benchmark
การออกแบบและทำ software เพื่อใช้งานจริงมีอะไรมากกว่าแค่ ความเร็ว, resource consumption และความสวยงามของโค้ด ซึ่งภาษาอังกฤษมีคำง่าย ๆ ที่อธิบายสิ่งนี้ได้คือคำว่า Practical
Practical = ใช้งานได้จริง
Practical แปลตรง ๆ ว่าใช้งานได้จริง แต่ การใช้งานได้จริงในโลกของ software development คืออะไร?
developer หลาย ๆ คนติดกับดัก doing technical thing for the sake of being technical หรือเป็นภาษาไทยง่าย ๆ คือ "โฟกัสกับการทำอะไรที่ไม่ได้มี user value"
PHP ช้า เขียนใหม่ด้วย Rust เลยสิ!
ทำได้ไหม? ได้ ควรทำไหม? 99% คือไม่ควร!
เส้นแบ่งระหว่าง developer ที่เก่งกับ developer ทั่ว ๆ ไป คือ ความ practical ครับ
ทำยังไงถึงเรียกว่า practical?
ใครที่เรียนวิศวกรรมซอร์ฟแวร์มาอาจได้เคยได้ยินชื่อ project management triangle ผ่านหูมาบ้าง
มันคืออะไร?
มันคือ property 3 อย่างที่ software project ต้องแลกเพื่อที่จะให้อีกอย่างเกิดขึ้นได้อย่างมีคุณภาพครับคือ
- Time - เวลาที่ใช้
- Scope - งานที่อยากได้
- Cost - ราคาที่ต้องจ่าย ปกติจะเป็นมุมของ human resource ที่ใช้
ยกตัวอย่างคือ
งานเร่ง (Time น้อย) ถ้าอยากให้โปรเจคเสร็จทัน ทำได้สองทางคือ ไม่ลด scope ก็เพิ่ม cost (คน)
งานใหญ่ (Scope ใหญ่) ถ้าอยากให้โปรเจคเสร็จครบ ทำได้สองทางคือเพิ่มเวลา หรือ ไม่ก็เพิ่มคน
งบน้อย (Cost ไม่มี) ถ้าอยากให้โปรเจคทำได้ตามงบ ทำได้สองทางคือ เพิ่มเวลา หรือ ไม่ก็ลด scope
สามอย่างนี้ไม่สามารถทำทั้งหมดพร้อม ๆ กันได้โดย keep quality ไว้ครับ ยกเว้นคุณจะมี resource ไม่จำกัด เช่น เวลาไม่จำกัด (physically impossible), เงินไม่จำกัด (physically impossible), แรงคนไม่จำกัด (financially impossible)
ทีม product development ที่เก่ง คือ ทีมที่มีความ practical สามารถ balance สามอย่างนี้ได้เก่งและเลือกปรับได้เหมาะสมตามสถานการณ์ครับ
โลกของ software engineering ไม่มีคำว่าเอาสุดทุกอย่าง
จากที่เล่ามาข้างต้น จะเห็นว่าเอาสุดทุกอย่างเป็นไปไม่ได้! ในโลกความเป็นจริง business ต้องเดินหน้า research มันมีงบจำกัด product มันต้อง launch
สิ่งที่คนทำซอฟ์ตแวร์ต้องทำคือหา sweet spot ของทั้งสามอย่างครับ
ตัวอย่าง
ถ้าระบบที่เขียนมันเป็น PHP แล้วมีเวลา 1 เดือนในการทำ feature ใหญ่ การ rewrite ในภาษาใหม่มันไม่ควรอยู่ใน option ด้วยซ้ำ!
ถ้าขึ้นระบบใหม่ budget จำกัดแล้วคนในทีมเขียน Golang เป็น ก็ไม่ควรดื้อไปเลือก PHP ที่คนในทีมทำไม่เป็น
ลูกค้าอยาก extend system เก่าเพื่อใช้งานใน 1 สัปดาห์ แต่ทีมเสนอทำ service ใหม่แยกจะทำทันไหม?
ถ้าไม่ใช่ hobby project ทำเอามันส์ ผมคิดว่าทีมที่ประสบความสำเร็จคือทีมที่ ยืดหยุ่นและรู้ความถนัดของตัวเองครับ
แล้ว MeCode practical ไหม?
ทีม MeCode ให้ความใส่ใจกับ constraint ของโปรเจคเป็นอย่างแรกก่อนเสนอ solution ให้ลูกค้าครับ
ถ้าลูกค้ามี software อยู่แล้วการ rewrite จะเป็น option สุดท้าย เพราะ ทีมเรามั่นใจว่าสามารถ maintain codebase PHP, Python, JS/TS, Ruby และ Golang ได้ แม้ว่ามันจะเละแค่ไหนก็ตาม
ถ้าลูกค้ายังไม่รู้ว่า requirement ต้องเป็นแบบไหน ทีมเราจัด exploration workshop เพื่อทำให้มันเคลียขึ้นก่อนเริ่มทำได้เพื่อลด risk
ถ้าลูกค้าหาคน operate software เรามี platform SRE ที่ทำให้การ detect ปัญหาและแก้ไขสามารถมี SLA มารองรับได้ถึงแม้จะไม่ใช่โค้ดที่เราเขียนเอง
และถ้าลูกค้าไม่ได้มี technical constraint ทีมเราก็มี tech stack ที่ optimized เพื่อ productivity เพื่อให้งานออกมาเร็วและมีคุณภาพอย่าง MeCode Stack เพื่อให้ลูกค้าได้ product ที่ตอบโจทย์ภายใต้ constraint ของแต่ละเจ้า
สรุป
ที่เขียนมาทั้งหมดนี่ ผมอยากสื่อว่าในการทำงานจริงทีม product development ที่ดีคือทีมที่เข้าใจ product และ user (ลูกค้า) ของตัวเองดีพอและสามารถเลือก trade off ที่เหมาะสมของแต่ละโปรเจคได้มากกว่า cracked programmer ที่ใช้ C เขียน web application เพราะมันเร็วครับ
ใครที่มีข้อสงสัยหรืออยากปรึกษาเรื่อง software development หรือสนใจจะจ้างงานสามารถติดต่อมาที่ [email protected] ได้เลยครับผม
และถ้าใครสนใจ Digital Ocean อยู่ทีมผมเป็น partner สามารถใช้ referral link นี้ได้ credit $200 ฟรี ครับ https://m.do.co/c/71a088fffcd6
Tino Thamjarat
Tino Thamjarat
