ทำไม “ความเจ๋ง” ของภาษาโปรแกรม ถึงไม่ใช่สาระ (อีกต่อไป)
ช่วงหลัง ๆ เวลาคุยกับเพื่อนนักพัฒนาทีไร ก็มักจะเจอคำถามว่า “ตอนนี้ใช้ภาษาอะไรอยู่?” บางคนก็ตอบอย่างภาคภูมิใจว่า Rust บ้าง Scala บ้าง Typescript แบบยาก ๆ บ้าง
พอถามเหตุผลก็ได้ประมาณว่า “มันเจ๋ง มันยาก” “คนอื่นทำตามได้ยาก” ซึ่งฟังแล้วก็รู้สึกว่ามันเท่ดีนะ แต่เอาจริง ๆ แล้ว เราไม่ได้เขียนโค้ดเพื่อโชว์ความเท่ หรือพยายามทำให้คนอื่นตามไม่ทัน
แต่เราเขียนโปรแกรมเพื่อ “แก้ปัญหา” ให้ Business หรือเปล่า?
ความ Simple (Simplicity) คือพระเอกของงาน
ทุกวันนี้ Python กับ JavaScript เป็นเบอร์ต้น ๆ ในใจนักพัฒนาหลายคน ก็เพราะมันเข้าใจง่าย แก้ปัญหาได้ไว มี community เยอะ เหมือนมีคนพร้อมส่งสารพัดไลบรารีมาให้ใช้
พอเจอคอขวดด้าน performance ใน Python เราจึงค่อยมอง C หรือไม่ก็ Rust เข้ามาเสริม หรือเจอความซับซ้อนที่ต้องการจัดหนักหน่อยของ JavaScript เราก็ค่อยขยับไปใช้ Typescript เป็นต้น โดยไม่ต้องนั่งงมหรือตัดสินใจเลือกภาษาที่ยากตั้งแต่แรก
ภาษายาก ๆ เป็น “แต้มต่อ” ในการจ้างงาน
เคยสงสัยมั้ยว่าทำไมบางบริษัทหรือบางทีม ชอบเอาภาษาที่ยากเช่น Typescript (ด้วยการเขียนแบบยาก) หรือ Scala มาใช้กับงานที่จริง ๆ แค่ JavaScript หรือ Java ก็พอแล้ว?
มันมีความจริงที่นักพัฒนาอย่างเรา ๆ ไม่อยากพูดกัน ก็คือนักพัฒนาบางคนใช้ความยากนี่แหละเป็น “แต้มต่อ” เพื่อให้ตัวเองถูกแทนที่ได้ยากขึ้น เพราะโค้ดมันซับซ้อน และต้องใช้เวลาหาคนมาแทนหลายเดือนจึงจะเข้าที่ แม้ว่าจะเป็น Senior ก็ตาม (แถมมี cost มหาศาลทั้งในกระบวนการหา และการจ้าง)
ตัวอย่างเช่น
- ใช้ Promise ใน Typescript ซ้อน ๆ กันจนคนเขียนเองเปิดโค้ดมาอ่านก็ยังปวดหัว
- ใช้ Scala เพราะ “type system” หรือเป็น “functional language” ที่เหมาะกับสาย finance ทั้งที่ Java ก็ยังรับมือได้
- เอา Rust มาเขียนเว็บแบบ MVC ด้วยการอ้างเหตุผลเรื่อง memory safety (แทนที่จะเอา Rust ไปเขียน low-level หรือระบบ performance สูง ๆ) แต่เอาเข้าจริงก็ไม่ได้เคยจะสนใจ patch ระบบเวลามีสารพัด CVE ที่ต้องแก้ไข
แต่ Barrier พวกนี้ ไร้ความหมายแล้ว
AI มาพลิกเกม ความซับซ้อนใช้เป็นเกราะไม่ได้แล้ว
“เกราะป้องกัน” ที่เคยใช้ไม่ให้หาคนใหม่มาแทนได้ง่าย ๆ กำลังจะใช้ไม่ได้ผลแล้ว เพราะ AI ราคา 750 บาทต่อเดือน เข้ามาช่วยให้คนที่เพิ่งเข้าทีมมาใหม่ ใช้เวลาไม่กี่วันก็จับทางโค้ดเก่าที่ซับซ้อนมาก ๆ ได้
- AI ช่วยอ่านโค้ด: เอา code base ที่มีเป็นพัน ๆ บรรทัด โยนให้ AI วิเคราะห์ ชี้จุดสำคัญให้ได้ในพริบตา
- AI ช่วยสร้าง Test Case: อยากได้ test coverage 100% ก็สั่ง AI เขียน test case ให้ ด้วยต้นทุนที่ถูกมาก
- AI ช่วยลอกสไตล์โค้ด: ต่อให้เราเขียนในแบบ “ฉันล้ำสุด ๆ” มันก็ถอดแบบออกมาได้ง่าย ๆ เพราะสิ่งที่ AI กลุ่ม GPT o4 / Claude Sonnet 3.5 ทำได้ดีคือ pattern matching ในระดับ Senior Engineer
นักพัฒนาก็สามารถถูกแทนที่กันได้ง่ายขึ้น ผู้บริหารก็ไม่ต้องกังวลเรื่องการจ้างคนใหม่แล้วต้องอีก 6 เดือนกว่าจะ catch up ได้ เพราะ AI ในปัจจุบันและในอนาคตอันใกล้นี้จะช่วยเพิ่มความเร็วให้ จนเงื่อนไขเดิมที่ใช้โค้ดยาก ๆ เพื่อต่อรอง ตอนนี้กลายเป็นโล่กำบังอ่อน ๆ เท่านั้น
ควรรักษา Value ด้วยอะไร
การฝึกภาษาใหม่ tech ชุดใหม่ แล้ววิ่งหนีไปเรื่อย ๆ ก็ยังเป็นทางเลือกที่ดี ถ้าวิ่งได้เร็วพอ
แต่สุดท้ายแล้ว การเลือกภาษาโปรแกรม หรือความพยายามทำให้โค้ดซับซ้อนนั้น ไม่ได้มี Value จริงในตัว เพราะภาษา (หรือแม้แต่เฟรมเวิร์คก็ตาม) เป็นแค่ “เครื่องมือ” ในการสร้างผลิตภัณฑ์หรือบริการให้คนได้ใช้ เราควรโฟกัสที่ผลลัพธ์และการแก้ปัญหา มากกว่าอวดโค้ดเท่ ๆ ที่เขียนด้วยวิธีหรือเทคนิคซับซ้อน
Value ที่แท้จริง คือ
- ได้งานเสร็จเร็ว มีประสิทธิภาพ
- ทีมเข้าใจโค้ดร่วมกันได้ง่าย
- เตรียมพร้อมรับมือกับการเปลี่ยนแปลง (เปลี่ยนสมาชิกในทีม, ปรับ product direction ฯลฯ)
- ใช้ภาษาและเครื่องมือที่เหมาะกับโจทย์นั้นจริง ๆ
เมื่อ AI เข้ามามีบทบาทมากขึ้น ก็ไม่ต้องซีเรียสว่าใครจะอ่านโค้ดยาก ๆ ได้หรือเปล่า เพราะความซับซ้อนของโปรแกรมกำลังจะไม่เป็นปัญหาโดยตรงของนักพัฒนาอีกต่อไปแล้ว
ทิ้งท้าย
ถ้าเราต้องการสร้างโปรดักต์ที่ตอบโจทย์ผู้ใช้ได้เร็วและดูแลได้ง่ายในอนาคต การเลือกภาษาโปรแกรมหรือเทคโนโลยีที่ “ง่ายและมี ecosystem พร้อม” ดูเหมือนจะเป็นตัวเลือกที่เหมาะสมกว่าการกระโดดไปภาษาที่เจ๋ง ๆ cool ๆ
โลกตอนนี้เปลี่ยนไวมาก อะไรที่เราเคยคิดว่า “ซับซ้อนแล้วหรู” เดี๋ยว AI ก็จะทำให้เรื่องนั้นง่ายเหมือนปอกกล้วย การทำอะไรให้ยุ่งยากเกินความจำเป็น หรือหวังว่าจะพึ่งความซับซ้อนพวกนั้นมาใช้ต่อรองกับอุตสาหกรรมในปัจจุบัน อาจจะไม่ใช่ไอเดียที่ดีนัก
ทุกวันนี้การ “แก้ปัญหาได้จริงและไว” สำคัญกว่าการ “โชว์ความเทพ” ของโค้ด และอย่าลืมว่าภาษาทั้งหมดไม่ว่าจะเจ๋งแค่ไหน ก็เป็นแค่ “เครื่องมือ” ที่วันหนึ่งอาจถูกแทนที่ด้วยเครื่องมือใหม่ได้เสมอ :-)