เมื่อวันก่อน นั่งคุยกับน้องคนหนึ่งที่กำลังจะขึ้นโปรเจ็คใหม่ แต่ลังเลว่าจะใช้ภาษาอะไรดี

เป็นเรื่องน่าปวดหัวของโปรแกรมเมอร์สมัยใหม่ครับ เพราะมีตัวเลือกเยอะไป สมัยก่อน ตัวเลือกไม่เยอะ อย่างเก่งก็แค่ C#, Java, PHP, C แต่เดี๋ยวโผล่มาพรึ่บพรั่บกันหมด

พอคุยๆกันกับน้องเค้าไปสักพัก ก็มีชื่อ Python + Django, Ruby on Rail, JavaScript + NodeJS, Go, Kotlin, Scala, TypeScript, Closure อะไรไม่รู้เต็มไปหมด

ตัวผมเอง เคยเขียนแค่สี่ห้าภาษา แถมยังไม่ได้ลงลึกด้วย ก็พอแต่แนะนำไกด์ไลน์ไปคร่าวๆ ว่าภาษาไหนมีจุดเด่นอะไร

พอมีเวลากลับมานั่งคิดดูอีกครั้ง จริงๆแล้วการบอกว่าแต่ละภาษาใช้ทำอะไร เหมาะหรือไม่ มันเหมือนกับการหยิบปลาให้น้องมากกว่า เราควรสอนวิธีให้น้องหาวิธีหาปลาเอง

ก็เลยเป็นที่มาของบันทึกฉบับนี้ครับ

โดยบันทึกฉบับนี้ เราจะมาเรียนรู้วิธีหาปลา(ภาษา)กัน แต่ผมจะไม่มานั่งไล่บอกว่า C กับ Go เนี่ยมันเร็วยังไง หรือ Scala มันเทพกว่า Java ยังไง

แต่เราจะมาออกจากความเป็นโปรแกรมเมอร์สุดกี้คมานิดนึง มามองการพัฒนาโปรแกรมด้วยเลนส์ของการจัดการกันบ้าง

1. ความเร็วของระบบกับประสิทธิภาพ vs ความเร็วในการพัฒนา

โปรแกรมเมอร์เรามักจะไปเน้นเรื่องความเร็ว และประสิทธิภาพกันจนบางทีลืมมองภาพรวมครับ

ว่าจริงๆแล้ว เราไม่ต้องไปแคร์เรื่องพวกนั้นจนกระทั่งเรามีคนใช้เยอะๆ (ซึ่งก็ไม่รู้ว่าเมื่อไร)

มันจำเป็นจริงๆรึเปล่าที่เราต้องให้ Backend เราทำงานเสร็จใน 50 ms หรือจริงๆ 300 ms ก็โอเคแล้ว

ส่วนเรื่องประสิทธิภาพในการเสกล จริงๆแล้วมันสำคัญที่การออกแบบระบบ มากกว่าการเลือกภาษา และเอาเข้าจริงใช้วิธีอัดเครื่องเพิ่มเข้าไปอาจจะคุ้มกว่าที่จะต้องไปนั่งเขียนภาษาที่ประสิทธิภาพโหดๆ แต่ใช้เวลาการพัฒนานานๆ

ถ้าออกแบบระบบมาดี ภาษาอะไรก็สเกลได้ในระดับหนึ่งครับ พอถึงจุดนั้นค่อยมานั่ง ​Optimize คอขวด (Bottleneck) กัน เฟสบุ้คเองก็เริ่มเขียนด้วย PHP (ซึ่ง Scale/Performance บัดซบมาก) แล้วค่อยๆ Optimize ขึ้นมาตามจำนวนผู้ใช้ครับ

หรือถ้าออกแบบเป็นเซอร์วิซ เราสามารถเขียนอีกภาษาหนึ่งให้ Optimized กว่า แล้วสลับแทนในภายหลังได้ อาจจะไม่ง่ายเหมือนเขียนใหม่แต่แรก แต่อย่างน้อย เราก็สามารถส่งโปรดักต์เราออกไปให้กับลูกค้าได้เร็วกว่ามาก พอฮิตแล้วค่อยมาดูว่ามันต้องเขียนใหม่จริงรึเปล่าก็ยังไม่สาย แต่ถ้าไม่ฮิต ก็จะได้ไม่ต้องเสียเวลา ไปทำโปรดักต์ใหม่เลย

ในทางตรงกันข้าม ความเร็วในการพัฒนางานให้เสร็จ เป็นอะไรที่ต่อรองได้ยาก

อย่างสตาร์ทอัพที่ต้องการความเร็ว ต้องไปไว แล้วทดลองไอเดียใหม่ๆ รับฟีดแบ็คจากผู้ใช้ ทิ้งไอเดียที่ไม่เวิร์ค แล้วทำใหม่ให้ไว สร้าง Volume ให้ได้ อันนี้ความเร็วในการพัฒนานี่คือความเป็นความตายของบริษัทเลย

ดังนั้น แทนที่จะไปมองเรื่องประสิทธิภาพ ลองมองดูว่า ตัวเลือกไหนที่จะทำโปรดักต์ที่พร้อมใช้ให้เร็วที่สุด ซึ่งอาจจะสำคัญกว่าในกรณีของโปรเจ็คคุณ

2. ภาษามาพร้อมกับ Framework/Library

คราวนี้ พอเราเลือกภาษา เอาเข้าจริง เราไม่ได้เลือกแค่ภาษาครับ ตัวอย่างเช่น ถ้าจะทำเว็บแอพเนี่ย เราก็มาพร้อมกับเฟรมเวิร์คแน่นอน ตัวเลือกก็มี

1. Python + Django
2. PHP + Laravel/Cake
3. Java + Spring
4. Ruby on Rail
5. JavaScript + NodeJS

หรือในกรณี บางทีคุณอาจจะพบว่าคุณเลือก PHP เพราะ Wordpress มีทุกสิ่งให้คุณเลือกสรร ไม่ต้องโค้ดก็ได้

หรือถ้าจะทำ Big Data คนก็อาจจะเลือก Scala เพราะ Spark พอทำ Machine Learning คนอาจจะเลือก Python เพราะ Scikit-learn

สังเกตดูว่า เพราะเราต้องการพัฒนาให้เร็ว เราจึงไม่อยากเขียนอะไรทุกอย่างเองหมด จำต้องใช้เฟรมเวิร์คไปโดยปริยาย

หลายๆครั้ง คนมองแค่ภาษา แต่ไม่ได้มองเฟรมเวิร์คกับไลบรารี่ครับ เขียนเสร็จแล้ว พึ่งมาค้นพบว่า จริงๆอีกภาษานึงมีคนทำไว้เสร็จแล้ว เรียกทีเดียวจบ

ดังนั้น เวลาศึกษาว่าใช้ภาษาไหนดี ศึกษาเฟรมเวิร์คกับไลบรารี่ไปด้วยนะครับ มันต้องไปด้วยกัน

ในเรื่องนี้ อีกจุดหนึ่งที่น่าสนใจคือ แม้ภาษาใหม่ๆมักจะมีข้อดีที่ได้รับการปรับปรุงมาจากภาษาเก่าๆ แต่ก็จะมีข้อด้อยตรงที่มี เฟรมเวิร์คกับไลบรารี่ที่ไม่ค่อย Mature เท่าไร

ผลที่ตามมาเวลาพัฒนาจริงคือ

1. ได้เจอบั้กเป็นคนแรก (เพียบเลยด้วย)
2. เวลาหาอะไรใน StackOverflow ก็ไม่เจอ
3. ไปถามใน Github issue ก็รอนาน
4. Document ก็ไม่มี

ซักพักนึงจะเริ่มอยาก Contribute เข้าโปรเจ็คเองเลย

ซึ่งมันก็ดีนะครับ คนรุ่นหลังก็ได้รับอานิสงส์ไปด้วย

แต่จริงๆแล้วเราอยากทำอะไรกันแน่? ทำงานเราให้เสร็จ หรือไป Contribute ให้ Opensource

3. อย่าดูถูกความลึกซึ้งของภาษา

อย่าดูถูกความลึกซึ้งของภาษานะครับ

ตอนผมเขียนเป็นสักสองสามภาษา ผมเคยคิดว่าภาษาพวก Procedural คล้ายๆกันหมด เรียนภาษาใหม่ไม่ยากหรอก แต่นั่นคือแค่เรื่องของ Syntax เวลาเขียนโค้ดจริงลงระบบจริงนี่คนละเรื่องเลย

แต่ละภาษามันมีรายละเอียดยิบย่อย (Subtlety) ของมันมาก ซึ่งถ้าจะเขียนให้ดี มันต้องเข้าใจ

อย่างผมเองเขียน Java มาเป็นภาษาแรก สอบเซอร์ผ่านแบบชิลๆ คิดว่าตัวเองเข้าใจ Java เป็นอย่างดี พอไปอ่าน Effective Java ของ Joshua Bloch ถึงค้นพบว่า ผมแม่งไม่เข้าใจภาษานี้เลยนี่หว่า

ส่วน JavaScript เอง คนส่วนใหญ่มักจะคิดว่ามันคล้าย Java ให้ลองเอา JavaScript: The Good Parts ของ Crockford ไปอ่านดูครับ แล้วจะค้นพบว่ามันเป็นสัตว์คนละสปีชี่กับ Java เลย

ส่วนใครเขียน C/C++ ผมคงไม่ต้องสาธยายให้ฟัง

แม้แต่ภาษาที่ออกแบบมาให้เขียนง่ายอย่าง Python ผมเคยเจอเคสที่คนเขียนไม่เข้าใจวิธีการจัดการ String วนลูปสร้างใหม่จนเมมเกือบหมดเซอร์เวอร์มาแล้ว

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

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

ยิ่งเดี๋ยวนี้ฮิตไมโครเซอร์วิซ (MicroService) กัน บางคนเอาไปใช้เป็นแหล่งทดลองภาษาใหม่

ผมเคยเห็นทีมเดียวซัด Backend เข้าไปสี่ภาษา เวลาเขียนเสร็จแล้วต้องมาเมนเทนนี่มีแต่อ้วกกับอ้วกครับ ดีบั้ก PHP ด้วย XDebug อยู่ดีๆ ต้องสลับไปใช้ Java ต่อผ่าน JMX สักพักนึงรีเควสเข้า Python ละ เซ็ตดีบั้กเกอร์เสร็จ ลืมไปแล้วว่าตอนแรกจะแก้บั้กอะไร

4. ในทีมมีคนเขียนภาษา/Framework/Library นี้คล่องรึเปล่า?

สืบเนื่องจากข้อที่แล้ว หากจะเลือกภาษาใดภาษาหนึ่ง ควรจะมีคนในทีมที่คล่องภาษานี้อย่างน้อย 1-2 คนครับ

ถ้าจะให้ดีควรจะ 2 เพราะตลาดงานสมัยนี้ คนเปลี่ยนงานกันบ่อย

คนที่เขียนคล่องจะต้องถ่ายทอด Best Practices ผ่านช่องทางต่างๆ ไม่ว่าจะเป็น Code Review, Pair programing, หรือ Workshop ให้กับคนในทีม

ซึ่งจะช่วยลดระยะเวลาที่ต้องเสียไปกับการลองผิดลองถูกไปได้มาก

โดยส่วนตัวแล้ว ผมมองว่าการเลือกภาษาใหม่ โดยไม่มีคนในทีมที่เก่งภาษานั้นเลย ผิดตั้งแต่เริ่มแล้ว เพราะเราไม่ได้รู้จักภาษานั้นๆดีพอที่จะใช้ตัดสินใจเลือกด้วยซ้ำ

5. ในอนาคต จะมีคนเขียนภาษา/Framework/Library ให้จ้างรึเปล่า?

ในโปรดักต์ที่คิดว่าจะอยู่กันยาว อยากให้นึกถึงเรื่องนี้กันด้วยครับ

เราอาจค้นพบว่า โปรดักต์เราใช้ภาษา ZungkaZy นี่โคตรเหมาะ เพอร์ฟอร์มานซ์นี่สูสีกับ C ไลบรารี่เพรียบพร้อมอย่างกับ Java ภาษาสวยและเจ้าของภาษาเท่อย่างกับ Python เฟรมเวิร์คนี่เนี้ยบยังกับใช้ Rail

ผ่านไป 2 ปี คนในทีมเปลี่ยนงานกัน เราจะหาคนมาเขียน ZungkaZy แทนได้รึเปล่า? ถ้าคนใหม่ไม่เคยเขียน ก็ต้องเสียเวลาเทรนกันใหม่ แล้วถ้าเกิดโปรแกรมเมอร์ที่เก่งภาษานี้ในทีม พร้อมใจกันออกขึ้นมาล่ะ จะไปหาซีเนียร์ที่ไหน

ถ้าเกิดภาษา ZungkaZy ไม่บูมอย่างที่คิด จำนวนคนเขียนในตลาดก็จะน้อยลงเรื่อยๆ ยิ่งโปรดักต์เรามีชีวิตอยู่นาน ก็ยิ่งหาคนเขียนยากเรื่อยๆ

ไอ้ไลบรารี่ที่เพรียบพร้อมก็โดนคนทำเทซะงั้น ไม่เมนเทนต่อแล้ว

ตกอับนะครับ

6. เลือกภาษาที่ในบริษัทมีคนทำ Tool ให้ใช้แล้ว

ข้อนี้สำหรับบริษัทใหญ่ครับ บริษัทที่ Mature มากๆแล้ว มักจะมีเครื่องมือที่ใช้กันในบริษัท (Internal Tool) ในการทำ Continuous Delivery ไว้เรียบร้อยแล้ว เช่น Package Management, Configuration Management, Monitoring (metric + logging), A/B Testing, etc.

สังเกตว่ามันเยอะมาก การทำ Critical System สเกลใหญ่ๆ เครื่องมือพวกนี้สำคัญมากนะครับ

ซึ่งพวกเครื่องมือเหล่านี้ มักจะรองรับแค่ภาษาเดียวหรือไม่กี่ภาษาครับ ถ้าคนในบริษัทส่วนใหญ่ใช้ Java แต่เราเลือกใช้ Python การใช้เครื่องมือที่มีคนทำไว้แล้วก็จะยาก

ดีไม่ดีต้องมาทำเองใหม่หมด ซึ่งเสียเวลามาก เวลามีปัญหาข้ามทีม แทนที่อีกทีมจะช่วยได้ง่ายๆเพราะใช้ Stack เดียวกัน ก็ช่วยกันไม่ได้อีก

สรุป: ไอ้ภาษาที่ดีกว่า จริงๆมันให้ประโยชน์กับคุณแค่ไหน

อ่านมาถึงตรงนี้ ผมหวังว่าขึ้นโปรเจ็คใหม่ครั้งหน้า จะได้มองในมุมอื่นๆเพิ่มขึ้นนะครับ

บางคนอาจจะบอกว่า สรุปคือผมแนะนำให้ใช้ภาษาเดิมที่ทำอยู่สินะ จะให้ดักดานอยู่ที่ภาษาเดิมใช่ไหม?

อันนี้ก็จริงส่วนนึงครับ

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

คุณจะเปลี่ยนภาษาทำไม ถ้าภาษาเดิมมันทำทุกอย่างได้อยู่แล้ว

ถ้าจะเปลี่ยน ก็แปลว่ามันต้องดีกว่า หรือมีประโยชน์คุ้มค่ากับความเสี่ยงในการให้ทีมต้องใช้ภาษาใหม่ครับ

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