การเริ่มต้นในสิ่งใหม่ ๆ มันคือความท้าทาย และยากเสมอ
การเริ่มต้นสำหรับนักพัฒนาก็เช่นกัน
ทั้งการเรียนรู้งาน
ทั้งการเรียนรู้คน
ทั้งการเรียนรู้ 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 มากจนเกินไป