จาก JavaScript สู่ TypeScript: ประสบการณ์การเอาตัวรอดในโลกของ Code ที่ไม่มีวันจบสิ้น

ย้อนกลับไปเมื่อ 5 ปีก่อน ผมยังเป็นนักพัฒนาสาย JavaScript ตัวยงที่หลงใหลในความยืดหยุ่นของมัน ผมชอบที่สามารถเขียน Code อะไรก็ได้ตามใจนึก ไม่ต้องประกาศ Type ไม่ต้องกังวลเรื่องโครงสร้างที่เข้มงวด JavaScript ทำให้ผมส่งงานได้เร็วในช่วงแรก แต่นั่นแหละครับคือจุดเริ่มต้นของฝันร้ายที่ค่อยๆ คืบคลานเข้ามาเมื่อโปรเจกต์เริ่มขยายตัวใหญ่ขึ้น

ปัญหาที่ผมเจอเป็นประจำคือ “Runtime Error” ที่มักจะโผล่มาทักทายตอนตีสอง หรือตอนที่กำลัง Demo ให้ลูกค้าดู คำว่า ‘undefined is not a function’ กลายเป็นคำที่ผมเกลียดที่สุดในชีวิตการทำงาน การต้องไล่หาว่าตัวแปรตัวหนึ่งที่ถูกส่งผ่านมา 5-6 ฟังก์ชันนั้นหายไปตรงไหน หรือสะกดผิดที่บรรทัดไหน เป็นเรื่องที่เสียเวลาและบั่นทอนกำลังใจอย่างมาก นั่นคือจุดเปลี่ยนที่ทำให้ผมตัดสินใจหันมามอง TypeScript อย่างจริงจัง

1. ความเจ็บปวดที่เกิดจากความยืดหยุ่นเกินไปของ JavaScript

Photo by anshul kumar on Pexels

ในโลกของ JavaScript ทุกอย่างดูง่ายไปหมดจนบางครั้งมันง่ายเกินไป (Too easy) ผมเคยทำโปรเจกต์ E-commerce ขนาดใหญ่ที่มีทีมงาน 10 คน ทุกคนต่างคนต่างเขียนฟังก์ชันของตัวเอง ปัญหาใหญ่ที่เจอคือเราไม่รู้เลยว่าฟังก์ชันที่เพื่อนเขียนต้องการ Input หน้าตาเป็นอย่างไร เราต้องคอยเปิดไฟล์สลับไปมาเพื่อดูว่า Object นี้มี Property ชื่ออะไรบ้าง บางคนใช้ ‘userId’ บางคนใช้ ‘user_id’ ความไม่สอดคล้องกันนี้ทำให้เกิด Bug มหาศาล

การ Refactor Code ใน JavaScript คือความเสี่ยงระดับชาติ ทุกครั้งที่ผมต้องการเปลี่ยนชื่อตัวแปรหรือโครงสร้าง Data ผมต้องใช้เครื่องมือ ‘Find and Replace’ แล้วภาวนาว่าอย่าให้มันไปเปลี่ยนโดนจุดที่ไม่เกี่ยวข้อง หรือพลาดจุดที่ควรเปลี่ยนไป ความไม่มั่นใจนี้ทำให้ Code Base ของเราเริ่มเน่า (Code Rot) เพราะไม่มีใครกล้าแตะต้องส่วนที่คนอื่นเขียนไว้ กลัวว่าแก้นิดเดียวแล้วระบบจะพังทั้งแถบ

เมื่อ ‘any’ กลายเป็นศัตรูที่มองไม่เห็น

แม้ว่าเราจะพยายามคุมมาตรฐานด้วยการเขียน Documentation แต่มันก็มักจะไม่อัปเดตตาม Code จริง สุดท้าย JavaScript ก็ปล่อยให้เราส่งอะไรก็ได้เข้าไปในฟังก์ชัน จนเกิดเหตุการณ์ที่ข้อมูลประเภท String หลุดเข้าไปคำนวณทางคณิตศาสตร์ ผลลัพธ์ที่ได้คือ ‘NaN’ หรือการต่อ String ที่ผิดเพี้ยน ซึ่งกว่าจะรู้ตัวก็ตอนที่ข้อมูลเหล่านั้นถูกบันทึกลง Database ไปเรียบร้อยแล้ว

2. TypeScript: อัศวินขี่ม้าขาวที่มาพร้อมกับ Type System

การเริ่มต้นกับ TypeScript ในช่วงแรกบอกเลยว่า “น่ารำคาญ” มากครับ จากเดิมที่เคยเขียนปรื๊ดเดียวเสร็จ กลับต้องมานั่งนิยาม Interface, Type และคอยแก้ขีดเส้นใต้สีแดงที่ IDE ฟ้องอยู่ตลอดเวลา แต่พอผ่านไปสักพัก ผมเริ่มตระหนักว่าไอ้เส้นแดงๆ นั่นแหละคือ “เพื่อนแท้” มันบอกผมตั้งแต่วินาทีที่ผมพิมพ์ผิดว่า “เฮ้ย ตรงนี้แกส่งค่าผิดประเภทนะ” ไม่ต้องรอไปลุ้นตอน Run ระบบ

TypeScript เปลี่ยนวิธีการคิดของผมจากการเขียนไปเรื่อยๆ เป็นการ “ออกแบบก่อนเขียน” (Design First) ผมต้องคิดก่อนว่า Data ที่ไหลในระบบมีหน้าตาเป็นอย่างไร การมี Static Typing ทำให้ผมสามารถใช้ฟีเจอร์ Autocomplete ใน VS Code ได้อย่างเต็มประสิทธิภาพ เพียงแค่พิมพ์จุด (.) รายการ Property ทั้งหมดก็โผล่มาให้เลือก ลดการสะกดผิดไปได้เกือบ 100%

// ตัวอย่าง JavaScript ที่เสี่ยงต่อการพัง
function calculateTotal(items) {
    return items.reduce((total, item) => total + item.price, 0);
}
// ถ้าส่ง items เป็น null หรือ item ไม่มี price ระบบจะพังทันที

// ตัวอย่าง TypeScript ที่ปลอดภัยกว่า
interface Product {
    id: number;
    name: string;
    price: number;
}

function calculateTotalTS(items: Product[]): number {
    return items.reduce((total, item) => total + item.price, 0);
}
// Compiler จะดักไว้เลยถ้าเราเผลอส่ง Data ผิดรูปแบบ

3. การปรับตัวและวิธีแก้ปัญหาเมื่อต้องย้ายค่าย

ปัญหาที่ใหญ่ที่สุดตอนย้ายจาก JS มา TS คือ “ความใจร้อน” ครับ หลายคนรวมถึงผมในช่วงแรกชอบใช้ ‘any’ เพื่อให้ Error มันหายๆ ไปก่อน แต่นั่นคือกับดัก เพราะการใช้ any คือการทำลายพลังของ TypeScript ทิ้งไปเลย วิธีแก้ของผมคือการฝึกเขียน Interface ให้ครอบคลุม และเริ่มใช้ ‘unknown’ แทน ‘any’ ในกรณีที่เราไม่แน่ใจจริงๆ เพื่อบังคับให้เราต้องทำ Type Guard ก่อนใช้งาน

อีกเรื่องคือการตั้งค่า `tsconfig.json` ที่ต้องเข้มงวด (Strict Mode) ตั้งแต่แรก ผมเคยพลาดตั้งค่าแบบหลวมๆ เพื่อความสะดวก แต่สุดท้ายก็เจอปัญหาเดิมๆ กลับมาหลอกหลอน การเปิด `strict: true` อาจจะทำให้ชีวิตยากขึ้นในช่วงแรก แต่มันคือการลงทุนที่คุ้มค่าในระยะยาว เพราะมันจะบังคับให้เราจัดการกับกรณีที่ค่าอาจจะเป็น null หรือ undefined อย่างเป็นระบบ

การจัดการกับ Library ภายนอก

ในอดีต Library บางตัวไม่มี Type Definition มาให้ ทำให้การใช้งานร่วมกับ TypeScript เป็นเรื่องยาก แต่ปัจจุบันเกือบทุก Library ยอดนิยมจะมี `@types/` มาให้ติดตั้งเสมอ หรือเขียนด้วย TS มาตั้งแต่ต้น ประสบการณ์ของผมคือ ถ้า Library ไหนไม่มี Type Support ให้พิจารณาเปลี่ยนไปใช้ตัวเลือกอื่นแทน เพราะมันจะกลายเป็นจุดอ่อนในระบบของคุณ

4. ประสิทธิภาพในการทำงานทีม: เมื่อ Code คือเอกสารในตัวมันเอง

สิ่งที่ผมชอบที่สุดหลังจากเปลี่ยนมาใช้ TypeScript คือการ Onboard พนักงานใหม่ เมื่อก่อนผมต้องใช้เวลาหลายชั่วโมงอธิบายว่า Function นี้รับอะไร คืนค่าอะไร แต่ตอนนี้พนักงานใหม่แค่เปิด Code ดู Interface เขาก็เข้าใจโครงสร้างข้อมูลได้ทันที TypeScript ทำหน้าที่เป็น Documentation ที่ไม่มีวันล้าสมัย เพราะถ้า Code เปลี่ยนแต่ Type ไม่เปลี่ยน มันจะ Compile ไม่ผ่านทันที

การรีวิว Code (Code Review) ก็ทำได้ง่ายขึ้นมาก ผมสามารถโฟกัสไปที่ Logic ของโปรแกรมได้จริงๆ แทนที่จะต้องมาคอยจับผิดเรื่องการสะกดชื่อตัวแปรหรือการส่ง Parameter สลับตำแหน่งกัน ความมั่นใจในการ Refactor Code เพิ่มขึ้นมหาศาล ผมสามารถเปลี่ยนชื่อ Method สำคัญๆ ของทั้งโปรเจกต์ได้ภายในคลิกเดียว โดยรู้ว่า TypeScript จะตามไปแก้ให้ทุกจุด และเตือนถ้ามีจุดไหนที่แก้ไม่ได้

// ประสบการณ์จริง: การใช้ Union Types และ Type Narrowing
type UserState = "Guest" | "Member" | "Admin";

interface User {
    id: string;
    role: UserState;
    email?: string; // Optional property
}

function getWelcomeMessage(user: User): string {
    switch (user.role) {
        case "Guest":
            return "Welcome, Guest!";
        case "Member":
            return `Welcome back, ${user.email}`;
        case "Admin":
            return "Accessing Admin Dashboard...";
        default:
            const _exhaustiveCheck: never = user.role;
            return _exhaustiveCheck;
    }
}
// ถ้าอนาคตมีการเพิ่ม Role ใหม่แต่ลืมแก้ switch-case ตรงนี้จะฟ้อง Error ทันที

5. ความเชื่อผิดๆ: TypeScript ทำให้รันช้าลงจริงหรือ?

มีคำถามหนึ่งที่ผมมักจะโดนถามบ่อยๆ คือ “TypeScript ทำให้แอปฯ รันช้าลงไหม?” คำตอบคือ “ไม่เลยครับ” เพราะ TypeScript จะถูกแปลง (Transpile) กลับไปเป็น JavaScript ธรรมดาก่อนที่จะนำไปรันบน Browser หรือ Node.js ตัว Type ทั้งหมดที่เราเขียนจะถูกลบทิ้งไปในช่วง Build Time ดังนั้นสิ่งที่ User ได้รับคือ JavaScript ที่สะอาดและผ่านการตรวจสอบมาอย่างดีแล้ว

ในแง่ของ Development Speed ช่วงแรกอาจจะดูช้าลงเพราะต้องเขียน Type เพิ่มขึ้นประมาณ 10-20% แต่ถ้ามองในระยะยาว (Maintenance Phase) TypeScript ช่วยประหยัดเวลาในการหา Bug ไปได้มหาศาล ผมเคยเก็บสถิติส่วนตัว พบว่าเวลาที่เสียไปกับการ Debug ลดลงกว่า 50% หลังจากเปลี่ยนมาใช้ TypeScript อย่างเต็มตัว ซึ่งเวลาที่ประหยัดได้ตรงนี้มันมากกว่าเวลาที่เสียไปกับการเขียน Type หลายเท่าตัวนัก

อนาคตของนักพัฒนาเว็บ

ปัจจุบัน TypeScript กลายเป็นมาตรฐานอุตสาหกรรมไปแล้ว Framework ดังๆ อย่าง Angular บังคับใช้ ส่วน React และ Vue ก็แนะนำให้ใช้เป็นทางเลือกหลัก หากคุณยังติดอยู่กับ JavaScript แบบเดิม คุณกำลังพลาดเครื่องมือที่จะช่วยยกระดับความเป็นมืออาชีพและลดความเครียดในการทำงานไปอย่างน่าเสียดาย

• JavaScript: เหมาะสำหรับโปรเจกต์ขนาดเล็กมาก, การทำ Prototype รวดเร็ว, หรือผู้ที่เพิ่งเริ่มเรียนเขียนโปรแกรม
• TypeScript: เหมาะสำหรับโปรเจกต์ขนาดกลางถึงใหญ่, การทำงานเป็นทีม, และระบบที่ต้องการความเสถียรสูง
• การ Refactor: TypeScript ชนะขาดลอยด้วยความสามารถในการตรวจสอบความถูกต้องทั่วทั้งโปรเจกต์
• การเรียนรู้: มี Learning Curve ในช่วงแรก แต่คุ้มค่าต่อการลงทุนในระยะยาวสำหรับอาชีพ Developer
• Tooling: การสนับสนุนจาก IDE (VS Code) ยอดเยี่ยมมาก ช่วยลดความผิดพลาดจากความประมาทได้ดี

สรุป

จากการเดินทางของผมที่เริ่มจากสาวก JavaScript ผู้รักอิสระ จนกลายมาเป็นแฟนพันธุ์แท้ TypeScript ผมบอกได้เลยว่ามันไม่ใช่แค่การเพิ่ม Type เข้าไปในภาษา แต่มันคือการเปลี่ยน Mindset ในการเขียนโปรแกรมให้มีความรับผิดชอบมากขึ้น ปลอดภัยมากขึ้น และสื่อสารกับคนในทีมได้ดีขึ้น แม้ JavaScript จะยังคงเป็นพื้นฐานที่สำคัญ แต่ TypeScript คือเครื่องมือที่จะช่วยให้คุณก้าวข้ามขีดจำกัดเดิมๆ และสร้าง Software ที่มีคุณภาพระดับสูงได้อย่างมั่นใจ

ถ้าคุณยังลังเล ผมแนะนำให้ลองเริ่มจากโปรเจกต์เล็กๆ หรือค่อยๆ เปลี่ยนไฟล์ .js เป็น .ts ทีละไฟล์ดูครับ แล้วคุณจะพบว่าความรู้สึกที่ “เขียน Code แล้วนอนหลับฝันดี” เพราะรู้ว่าไม่มี Bug โง่ๆ ซ่อนอยู่นั้น มันมีค่ามากแค่ไหนในชีวิตของนักพัฒนาคนหนึ่ง