การเริ่มต้นในสิ่งใหม่ ๆ มันคือความท้าทาย และยากเสมอ
การเริ่มต้นสำหรับนักพัฒนาก็เช่นกัน
ทั้งการเรียนรู้งาน
ทั้งการเรียนรู้คน
ทั้งการเรียนรู้ process
ทั้งการเรียนรู้เครื่องมือ

แต่ส่วนใหญ่มักทำสิ่งผิดพลาดต่าง ๆ ดังต่อไปนี้
เลยทำการสรุปไว้เพื่อเตือนตัวเอง

ปล. แม้แต่นักพัฒนามือเก๋าและเก่าก็ยังพลาดเช่นกัน

ไม่ถามและชอบคิดไปเอง

เมื่อได้รับมอบหมายงาน
ส่วนใหญ่จะตั้งใจฟัง เพื่อให้เข้าใจ
จากนั้นก็กลับไปทำเลย
โดยที่ไม่ถามสิ่งใด หรือ ถามน้อยมาก ๆ

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

ดังนั้นหัดตั้งคำถามที่สิ่งที่ไม่ชัดเจน
หรือแม้เราจะเข้าใจแล้ว ลองถามเพื่อให้มั่นใจว่าเข้าใจถูกต้อง

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

แก้ไขปัญหาใหญ่ ๆ ในครั้งเดียว

เมื่อได้งานไปทำ ไม่ว่าจะมีขนาดเล็กหรือใหญ่
ก็มักจะลงมือทำไปเรื่อย ๆ แก้ไขไปเรื่อย ๆ
เขียน code ไปเรื่อย ๆ
ก็ให้เกิด spaghetti code หรือ arrow function (ไม่ใช่ JavaScript นะ)
บางครั้งก็แก้ไขปัญหาวนไปวนมา
แก้ตรงนั้นพังตรงนี้

ดังนั้นก่อนจะลงมือทำอะไร
ขอให้ทำการวางแผนก่อน
แบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาเล็ก ๆ
แบ่ง component ใหม่ ๆ ออกเป็น component เล็ก ๆ
จากนั้นจึงลงมือแก้ไขปัญหา เขียน code ในแต่ละส่วน
จะทำให้ผลที่ได้ดีกว่าเดิมอย่างมาก

แต่ปัญหาที่เจอคือ
ไม่ชอบถาม
ไม่สามารถแบ่งปัญหาออกมาได้ (Work break down)
ดังนั้นจำเป็นต้องฝึกครับ

ประเมินเวลาได้แย่มาก ๆ

ในข้อนี้คิดว่าเป็นทุกคน
เนื่องจากการประเมินที่แย่มี 2 แบบหลัก ๆ คือ
ประเมินมากเกินไป (Over estomation)
ประเมินน้อยเกินไป (Under estimation)

ปัญหาของการประเมินเวลาในโลกของการพัฒนา software นั้น
มีสิ่งที่เราไม่รู้เพียบ
ทั้งเรื่องคน process เครื่องมือ และสิ่งแวดล้อมรอบข้าง

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

ปล. เราทำการประเมินงานระยะยาวเป็นปี ๆ กันได้อย่างไร ?
สิ่งเหล่านั้นมันคือการโกหกใช่ไหม ?

ไม่เขียนชุดการทดสอบเลย

การเขียนชุดการทดสอบนั้น
นักพัฒนาส่วนใหญ่ที่รู้มักบอกว่า มันดีนะแต่ …
ต้องใช้เวลาเยอะขึ้น
ต้องใช้เวลาในการดูแลรักษา

ยิ่งไปคุยกับหัวหน้าหรือฝ่าย management ที่ไม่เข้าใจ
หรือสนใจแต่ส่งให้ทันตามแผน
เรื่องของการเขียนชุดการทดสอบก็ตกไปโดยอัตโนมัติ
และก็ไปเผางานในช่วงท้าย ๆ หรือบน production กันบ่อย ๆ แต่ก็ไม่จำหรือเรียนรู้

ดังนั้นสำหรับนักพัฒนามือใหม่
เมื่อไปเจอสิ่งแวดล้อมเช่นนี้ ก็ไม่ทำแน่นอน !!

แต่ขอแนะนำว่า
ให้ลองเขียนชุดการทดสอบเข้าไปในระบบงานที่ได้รับมอบหมาย
ถ้า code เก่ามันทำได้ยาก ก็ให้ทำกับส่วนใหม่ ๆ
ไม่เช่นนั้นก็ทำการปรับปรุง code ให้ทดสอบได้ง่าย
อย่าเอาแต่พูดแต่บ่นว่าไม่ดีอย่างนั้นอย่างนี้ ลงมือทำให้มันดีขึ้นซะ
แล้วคุณจะพบว่า มันช่วยเหลือเราอย่างมากมายตนคาดไม่ถึง

แต่ก่อนอื่นลงมือเขียน ทำก่อนนะ

ยังมีเรื่องอื่น ๆ อีกนะ ยกตัวอย่างเช่น

  • Over Engineer
  • ไม่ใช้ Version Control ที่ดี
  • ใช้ 3-party library/framework มากจนเกินไป

ขอให้สนุกกับการ coding นะครับ

Tags: