ในฐานนะนักพัฒนา software นั้น
ผมมักได้ยินคำถามเหล่านี้ออกมาเสมอ หรือ บ่อยครั้งที่ตัวเราเองพูดออกมา
เมื่อทำการเปิด และ อ่าน code เช่น
- ใครมันเขียน code แบบนี้ว่ะ ?
- เขาคิดว่า code แบบนี้มันดีแล้วหรือว่ะ ?
แต่เชื่อไหมว่า
นักพัฒนาทุกคนมักเขียน code ที่แย่ๆ ออกมาเสมอ
ไม่ว่าจะเป็นนักพัฒนาระดับไหน
แต่สิ่งที่แตกต่างกันก็คือ จะแย่มาก หรือ น้อยเท่านั้นเอง
ทำไมนะ ?
มันมีเหตุมาจากอะไรบ้างนะ ?
1. code ที่มันแย่ๆ เขียนง่ายไงล่ะ !!
เป็นเหตุผลยอดนิยมสำหรับนักพัฒนา
แน่นอนว่า สิ่งที่เราต้องทำให้เสร็จก่อนคือ Make it work
ตรงตาม requirement ที่ได้รับมอบหมาย
เพื่อส่งมอบคุณค่าไปยังลูกค้า
แต่ถ้าต้องการให้ code มันสวย และ ดีขึ้น
เราต้องการเวลาเพิ่มเติม สำหรับการแก้ไข code ให้มันดีขึ้นกว่าเดิม
แต่เชื่อเถอะว่า ไม่มีใครมาลงทุนเพื่อทำให้ code มันสวยขึ้นหรอกนะ
มีแต่ให้พัฒนาเสร็จให้เร็วที่สุดเท่าที่จะเป็นไปได้
แต่บ่อยครั้งเมื่อเรา สนใจเพียงส่งมอบคุณค่าให้ลูกค้า
โดยไม่สนใจในเรื่อง code เลย
มักจะพบว่า เราจะต้องใช้ค่าใช้จ่ายในการดูแลรักษา และ แก้ไข code มากขึ้นทุกวัน
สุดท้ายก็มาถึงทางตัน และเส้นทางที่มักจะเลือกก็คือ การเขียน code ใหม่
และมันก็วนอยู๋แบบนี้ไปเรื่อยๆ ซ้ำแล้วซ้ำอีก
ดังนั้น สิ่งที่คุณทำไว้มันเสร็จจริงๆ หรือ ? ( Getting done )
2. ไม่รู้ว่า code ที่มันมีการออกแบบดี เป็นอย่างไร ?
นักพัฒนาส่วนใหญ่มักได้รับความเจ็บปวดจาก code ที่ออกแบบมาไม่ดี
มักจะรู้ว่า codeที่มันแย่ๆ เป็นอย่างไร และไม่ชอบเลย
แต่กลับไม่รู้ว่า code ที่มันดีๆ เป็นอย่างไร และ สร้างขึ้นมาอย่างไร ?
มันแปลกดีนะ !!
เมื่อพูดถึงคำว่า code ที่มีการออกแบบที่ดี มักจะมีคำว่า
Low coupling และ High cohesion
ซึ่งมัน abstract มากๆ ใช่ไหม
มันยากไหมล่ะ ที่จะวัดว่า code ที่เราเขียนขึ้นมา
มันมีคุณสมบัตินี้ไหม ?
ดังนั้น เราควรที่จะเรียนรู้เพิ่มเติมบ้างแล้วนะ ?
3. เราไม่รู้ว่า เราต้องการอะไรจริงๆ กันแน่
ก่อนที่นักพัฒนาจะเริ่มเขียนโปรแกรม
มักจะมีคำถามมากมายที่ไม่ถูกตอบ เช่น
ลูกค้าของเราต้องการอะไรกันแน่จากสิ่งที่เราสร้าง ?
feature ที่เราสร้างนั้น ลูกค้าต้องการ หรือ มันจำเป็นต่อลูกค้าหรือไม่นะ ?
พฤติกรรมการทำงานที่แท้จริงของระบบมีอะไรบ้างที่ต้องการ และ จำเป็น ?
code ที่มีโครงสร้างดีๆ เป็นอย่างไร คืออะไร
แล้วสิ่งที่เรากำลังจะสร้างขึ้นมานั้น มันส่งผลให้เราทำงานยากในอนาคตหรือไม่ ?
ถ้ามัวแต่มานั่งตอบคำถามเหล่านี้
มักจะเจอว่า คำตอบที่เราได้มานั้น มันผิดอยู่เสมอ
เช่น ถ้าใช้เวลาในการออกแบบ code ที่ดีเป็นเวลานานๆ
พบว่าอีกวันมันไม่ดีแล้ว ดังนั้น เวลาที่เราเสียไปคืออะไร ไร้ประโยชน์มากๆ
ดังนั้น เริ่มต้นเขียน code เลยดีไหม
เพื่อให้ได้รับ feedback กลับมารวดเร็วที่สุด
หรือเรียนรู้ในช่วงเวลาสั้นๆ
มันคือ เส้นทางลัดเพื่อให้งานมันเสร็จได้ดี และ เร็ว
และพยายามเรียนรู้จาก code ที่มันแย่ๆ
เรียนรู้ว่ามันแย่ตรงไหน เพราะว่าอะไร
แล้วทำการวิเคราะห์ เพื่อทำการแก้ไขให้มันดีขึ้นอย่างไร
นั่นคือ คุณกำลังเรียนรู้การ refactor code นั่นเอง
4. เราไม่รู้จักการ refactor code
เมื่อเราต้องเข้าไปทำงานกับ code ที่มันแย่ๆ
มักจะเจอว่า code เหล่านั้นมันทำให้ลูกค้าไม่พอใจ
เมื่อจะทำการแก้ไข จำเป็นต้องใช้เวลาสูงมาก
และอาจจะมีใครบางคนบอกว่า
ถึงเวลาเราต้อง refactor code แล้วนะ
เพื่อทำให้มันดีขึ้น
เมื่อคุณได้ยินคำนี้ขึ้นมา ก็อาจจะบอกไปว่า
ดีเลย มันทำเพียงเล็กน้อย และ เราต้องการการทดสอบที่ดีๆ ด้วยนะ
แต่ต้องมีเวลาให้มากพอ … ถ้าคุณตอบในลักษณะนี้
แสดงว่า คุณยังไม่รู้ และ เข้าใจคำว่า refactor code มากพอ !!
ดังนั้น จงเรียนรู้ซะ ว่าการ refactor code มันเป็นอย่างไร ทำแบบไหน
ทางที่ดีที่สุดคือ เรียนรู้จาก code ที่มันแย่ๆ แล้วทำการ refactor มันซะ
5. คุณเดินก้าวใหญ่ไป
เมื่อเห็น code ที่มันแย่ๆ เรามักตัดสินใจทันทีเลยว่า
เราต้องทำให้ code ทั้งหมดมันดีขึ้นเลยนะ
แต่ในความเป็นจริง คุณมักจะถูกรบกวนจากสิ่งต่างๆ มากมาย
จนคุณไม่มีเวลาแก้ไข code ให้มันดีขึ้น
ดังนั้น เปลี่ยนแนวคิดก่อนดีไหม
โดยให้ทำการแก้ไขทีละเล็กละน้อย
code ใหม่ก็ไม่ให้มันแย่
code เก่าก็ค่อยๆ ปรับแก้กันไปอย่างต่อเนื่อง
ทำให้มันดีขึ้นวันต่อวัน
ทำให้มันดีขึ้นวสัปดาห์ต่อสัปดาห์
ทำให้มันดีขึ้นปีต่อปี
น่าจะเป็นแนวทางที่น่าสนใจกว่าใช่ไหมครับ
6. สุดท้าย นักพัฒนาไม่เคยร้องเรียกหาความช่วยเหลือ !!
นักพัฒนามักจะบอกว่างานไม่เสร็จตอนไหนนะ ?
แต่นั่นไม่ใช่ประเด็นเท่าไร
สิ่งที่จะเน้นคือ
คุณเคยทำ pair programming กันไหม ?
คุณเคยทำ code review กันไหม ?
ถ้ายัง เริ่มทำเลยครับ
ดังนั้น ถ้าคุณอยู่ในสถานการณ์แบบนี้
ได้เวลาที่คุณต้องเรียนรู้ ฝึกฝนทักษะเหล่านี้แล้วนะครับ
ไม่เช่นนั้น คุณก็จะเดินย่ำอยู่กับที่ต่อไปเช่นเดิม !!
