When situation called, do double work
บล็อกนี้ได้แรงบันดาลใจจากวิดีโอนี้
วิดีโอนี้เขาพูดถึงเรื่องที่ว่าการนำ Template language เข้ามาใน Codebase นั้น มีต้นทุนในการเพิ่มสิ่งที่ต้องเรียนรู้ และ Cost อื่นๆ ที่อาจจะง่ายกว่าที่จะใช้ Javascript โดยตรงทำไปเลย และการนำ Tooling เพิ่มใน Codebase ไม่ใช่เรื่องดีเสมอไป ถ้าสนใจรายละเอียดผมแนะนำให้ดู เป็นวิดีโอนึงที่ดีมาก
ประเด็นของผมเลยคือ ทำไมส่วนมากเราชอบนำ Tooling หรือ Library เข้ามาใน Codebase กันนะ ทั้งๆ ที่บางอันอย่าง Templating เนี่ย เขียนด้วย Javascript ล้วนก็ได้
ผมพบว่าเรามักจะเข้าใจผิดกันในเรื่องนี้เยอะมาก ว่าเวลาไหนควรนำ Tool เข้ามาใช้
Loss aversion bias
สมมติเราต้องการวาด HTML จาก Javascript สิ่งที่เรามักทำได้ คือ ถ้าเราไม่ นำ Engine หรือ Library เข้ามาใช้ ก็ต้องเขียนสดด้วยตัวเราเอง
ปัญหาคือ เวลาในการนำเข้ามาใช้ ผมพบว่า เรามักจะคิดกันแบบนี้
- คนที่ชอบใช้ Library ก็มักจะบอกว่า ให้เอา Library มาใช้ตั้งแต่ Day 1 เลย ทุกคนจะได้เริ่มเรียนรู้ แล้วสุดท้ายปัญหาคือว่าเราเพิ่ม Complexity ให้กับ Codebase โดยไม่คุ้มค่า
- คนที่ชอบเขียนเอง ก็มักจะเริ่มเขียนเองไปซักพักนึง จนความซับซ้อนมันเริ่มมากขึ้น แล้วเราก็ต้องพยายาม Maintain ทั้ง Documentation ทั้ง Interface ทั้ง Library ด้วยตัวเองเพื่อใช้งานระยะยาว
ผมคิดว่ามันกลับด้านกัน
ผมคิดว่า Timing ที่ดีกว่าคือ
- ตอน Requirement มันง่ายๆ ไม่ซับซ้อน เราควรเริ่มต้นจากการเขียนเองก่อน เพราะจังหวะนี้การนำ Library ที่ซับซ้อนต้องมี Learning curve สูงเข้ามาใช้ทันทีมันไม่คุ้ม
- พอซักพักนึงพอเราต้องเริ่ม Maintain มันเยอะๆ แล้ว เราก็เห็นแล้วว่าไม่คุ้มค่าที่จะรักษาโค้ดนั้นไว้ เราลบโค้ดที่เราทำในข้อ 1 ออกซะ แล้วเอา Standard library เข้ามาเสียบแทน จะได้ไม่ต้อง Maintain มันอีก
ปัญหาที่ผมมักจะพบคือ โปรแกรมเมอร์ก็เป็นมนุษย์
แล้วมนุษย์ก็มี Loss aversion bias
เรามักจะรู้สึกเวลาที่เราเขียนโค้ดลงไปเยอะๆ เราไม่อยากจะลบมัน เราอยากจะดูแลรักษามันต่อ
หรือถ้าจำเป็นต้องลบจริง ความเสียดายที่เราต้องลบทิ้งในรอบนี้ ก็มักจะทำให้รอบหน้าเราพยายามทำคิดในลักษณะ รอบหน้าฉันไม่เขียนแล้ว มันสิ้นเปลือง ฉันรีบเอา Library มาใช้ตั้งแต่ Day 1 เลยดีกว่า ซึ่งก็สร้างปัญหาเวลาที่ Requirement มันไม่เปลี่ยนแทน เกิด Unnecessary complexity ขึ้น
ผมถึงได้ ไฮไลท์ คำว่า “เราลบโค้ดที่เราทำในข้อ 1 ออกซะ”
เพราะนั่นเป็นเรื่องที่ผมพบว่า เรามักจะทำได้ยาก เรามักจะอยากหลีกเลี่ยง เรามักจะชอบเกลียดการลบของที่เราทำไปแล้วทิ้ง แล้วเขียนใหม่
ซึ่งผมคิดว่านั่นเป็น ความเข้าใจผิด อาจจะพูดได้ว่าเป็น Expectation ที่ผิดเลยก็ว่าได้ที่คิดว่า Productive developer จะคิดมาอย่างดีแล้วเขียนทีเดียวเสร็จ
อย่างน้อยผมพูดได้ว่าจาก Career ที่ผมผ่านพบมาซึ่งก็ไม่เยอะนักหรอก ผมพบว่า Developer ที่เก่ง มักจะสนใจและทำการ Refactor บ่อยๆ
คำว่า Refactor ภาษาบ้านๆ ก็คือ ลบแล้วเขียนใหม่นั่นแหละ นั่นคือนิยามของมันเลยไม่ได้ซับซ้อนหรูหราอะไรไปกว่านั้น
ดังนั้นในอีกแง่นึงคือ ผมพบว่าคนเก่งนั้นเขียนโค้ดแล้วลบทิ้งบ่อยมาก ไม่ใช่ว่าคิดมาอย่างดีแล้วเขียนทีเดียวจบซักเท่าไหร่
อย่ากังวลที่ต้องลบโค้ดตัวเอง เพื่อสิ่งที่ดีขึ้น
อย่ากลัวที่จะต้องเขียนโค้ดที่ทำงานแบบเดียวกันซ้ำไปซ้ำมาหลายรอบ
Coding and fireworks
ผมพบว่าปัญหาที่มักจะทำให้เรานำ Library มาใช้ใน Timing ที่ไม่เหมาะสม
สาเหตุของปัญหาก็คือการที่เรามี Loss aversion นี่แหละครับ ความไม่อยากลบโค้ด ไม่อยากทำงานซ้ำ
ซึ่งถ้าเท่าทันตัวเองเข้าใจตัวเองในเรื่องนี้
แล้วลองเขียนโปรแกรมแบบ “ฉันจะทำซ้ำเท่าที่จำเป็น”
ไม่ต้องหลีกเลี่ยงมัน แค่ยอมรับว่ามันเกิดขึ้นได้ เป็นธรรมชาติของงาน Software development ที่จะต้องทำซ้ำเป็นปกติ ลบโค้ดที่ทำไปแล้วไม่เวิร์คเป็นปกติ
ไม่ต้องหงุดหงิด ไม่ต้องอารมณ์เสีย แค่ยอมรับว่ามันเป็นธรรมชาติ แค่ยอมรับว่างานโค้ดดิ้งจริงๆ มันเหมือนกับทำดอกไม้ไฟ โชติช่วงแค่พริบตา แล้วก็หายไปเมื่อกาลเวลาเปลี่ยน
โค้ดมันไม่คงทน โปรแกรมเมอร์ผมว่าก็เหมือนช่างทำดอกไม้ไฟชั้นเลิศ ที่ทุ่มเทหยาดเหงื่อนับปีเพียงแค่เพื่อพริบตาช่วงเวลาเดียวเท่านั้น
งานโค้ดดิ้งผมพบว่าธรรมชาติก็เป็นแบบนั้น เหมือนทำดอกไม้ไฟ เราทุ่มเทเพียงเพื่อให้มันอยู่ได้ช่วงเวลานึง แล้วเราก็ต้องทำใหม่ (ถึงแม้ว่าช่วงเวลานั้นอาจจะนานกว่าดอกไม้ไฟพอสมควรก็ตาม)
ผมพบว่าการยอมรับแบบนี้จะช่วยให้เราเขียนโปรแกรมได้ดีขึ้นมากเลยครับ แนะนำให้ลองยอมรับมันดู แล้วจะเข้าใจงานของเราง่ายขึ้น ใช้ชีวิตง่ายขึ้นจริงๆ ครับ
