เห็นเพื่อน ๆ ทำการ share บทความจาก Dev.to
เรื่องเกี่ยวกับนิสัยที่ไม่ดีของนักพัฒนา software คือ
เห็นว่าน่าสนใจดีและน่าจะมีประโยชน์
จึงทำการสรุปไว้นิดหน่อย
ข้อที่ 1 ไม่มี code structure และ coding standard ที่ชัดเจน
เป็นเรื่องที่น่าสนใจมาก ๆ สำหรับการพัฒนา software
ถ้าระบบงานไม่ใหญ่ ทีมงานไม่เยอะ
เรื่องของโครงสร้างและ coding standard อาจจะไม่มีผลเท่าใดนัก
แต่เมื่อระบบงานใหญ่ขึ้น จำนวนคนในทีมเยอะขึ้น
เรื่องนี้จึงสำคัญเป็นอันดับต้น ๆ
มิเช่นนั้นแล้ว การจัดการ การพูดคุยและการทำงานร่วมกันจะยากมาก ๆ
คำถามที่น่าสนใจคือ
วันนี้ระบบงานที่กำลังพัฒนาอยู่มีการตกลงเรื่องนี้หรือไม่
ถ้าตกลงแล้ว ทำตามหรือไม่
มีการ review และปรับปรุงกันหรือไม่
ข้อที่ 2 ยังทำงานกันหามรุ่งหามค่ำ
เป็นเรื่องที่นักพัฒนาทุกคนต้องทำและเคยทำอย่างแน่นอน
สาเหตุหลักของการทำงานหามรุ่งหามค่ำ
นั้นมีหลากหลายเหตุผล
แต่หนึ่งเหตุผลที่มักได้รับคือ
เป็นช่วงที่ไม่มีใครมายุ่งหรือรบกวน
ทั้งการถามจากคนอื่น
ทั้งการประชุม
และปัญหาอีกมากมาย
ดังนั้นช่วงนี้ นักพัฒนาจึงคิดว่าเป็นช่วงที่มี productivity ที่สุด
ได้ focus กับงานอย่างจริงจัง
แต่ productivity มันจริงไหมนะ ?
งานที่ทำในตอนกลางคืนนั้น ต้อง rework หรือไม่
บ่อยครั้งต้องทิ้งชิ้นงานเหล่านั้นหรือไม่
ไม่พอนะ
ตอนเช้าก็ต้องรีบตื่นมาเข้าทำงานให้ทันเวลาอีก
ยิ่งก่อให้เกิดความกดดันและเครียดเพิ่มเข้าไปอีก
ส่งผลให้ป่วยบ่อย
ส่งผลให้งานที่ออกมาแย่ลงเรื่อย ๆ
ส่งผลให้ burnout อีก
คำถามที่น่าสนใจคือ
การทำงานในรูปแบบนี้มันดีจริง ๆ ไหมนะ
เราจะแก้ไขหรือปรับปรุงอย่างไรดี
ข้อที่ 3 ขาดการเขียนเอกสารที่ดี
บ่อยครั้งที่การเขียนเอกสารนั้น
มักจะเป็นของแสลงกับนักพัฒนา
เพราะว่าเป็นงานที่ไม่ถนัด ไม่ชอบ บางคนอาจจะบอกว่า ไม่ใช่หน้าที่ด้วยซ้ำ
แต่เอกสารที่กำลังพูดถึงคือ
เอกสารของการพัฒนาระบบงาน
ว่าระบบงานเป็นอย่างไรบ้าง
มีโครงสร้างอย่างไร
แต่ละส่วนมีการทำงานอย่างไร
เพื่อช่วยให้นักพัฒนาคนอื่น ๆ หรือแม้กระทั้งคนที่เข้ามาใหม่ได้อ่านและทำความเข้าใจ
เอกสารเหล่านี้มีประโยชน์อย่างมาก
ดังนั้นนักพัฒนาที่ดี
ควรหัดเขียนเอกสารอธิบายสิ่งที่ตนเองทำไว้
อย่างน้อยก็เพื่อตัวเราเอง
ถ้ากลับมาอ่านแล้วไม่เข้าใจ ก็ควรปรับปรุงให้ดีขึ้น
คำถามที่น่าสนใจคือ วันนี้นักพัฒนาเขียนเอกสารกันแล้วหรือยัง
ข้อที่ 4 ชอบ copy-and-paste โดยไม่เข้าใจ
การ copy-and-patse นั้นจะไม่มีปัญหาเลย
ถ้านักพัฒนารู้และเข้าใจว่า code เหล่านั้นทำงานอย่างไร
แต่บ่อยครั้งกลับพบว่า
นักพัฒนาชอบไปค้นหา solution ใน google
จากนั้นก็ไป copy solution มาใส่ใน project
ถ้าทำงานได้ตามที่คาดหวังก็ถือว่า งานจบแล้ว
แต่ไม่ได้ทำความเข้าใจต่อ code ชุดนั้นจริง ๆ
ดังนั้นถ้าเจอปัญหาลักษณะเดิมอีกครั้ง
ก็จะค้นหาเหมือนเดิม
และ copy-and-paste แบบเดิม
ซึ่งไม่น่าจะเป็นพฤติกรรมของนักพัฒนาที่ดีหรือไม่
คำถามที่น่าสนใจคือ
Code ที่นักพัฒนา copy มาใช้ เข้าใจมันจริง ๆ แล้วหรือยัง
ข้อที่ 5 ไม่เขียน Test
เป็นเรื่องที่ถูกพูดคุยกันเยอะมากขึ้นเรื่อย ๆ
ว่า code ที่นักพัฒนาเขียนขึ้นมานั้น
- ทำงานตามความคาดหวังหรือไม่
- ไม่สร้างผลกระทบต่อส่วนงานอื่น ๆ ใช่หรือไม่
นักพัฒนาจำเป็นต้องตอบคำถามทั้งสองให้ได้
เพื่อทำให้เราและคนอื่น ๆ มั่นใจในสิ่งที่เราทำหรือเขียน code ไปนั่นเอง
หนึ่งในวิธีการที่จะช่วยตอบคำถามคือ การเขียน Test
ดังนั้น นักพัฒนาเขียน Test แล้วหรือยัง
ไม่ว่าจะเขียนก่อนหรือหลังจากที่เขียน code ก็ตาม
ข้อที่ 6 ทำงานหลาย project พร้อม ๆ กัน
ปัญหาที่เจอเยอะมาก ๆ คือ งานมากกว่าคน แต่ทุกงานสำคัญหมด
ส่งผลให้นักพัฒนาแต่ละคน มีงานอยู่ในมือจนล้น
ทั้ง project เดียว
ทั้งมีมากกว่า 1 project
ผลที่ตามมาคือ
ไม่เสร็จสัก project !! หรือหนักกว่านั้นคือ bug เพียบ
ดังนั้นการแก้ไขปัญหาคือ แก้ที่ต้นเหตุ
นั่นคือ คนมีเท่าไร งานก็เท่านั้น
งานอื่น ๆ ต้องเข้าคิว
คนจัดคิวต้องจัดคิวตามความสำคัญให้ได้
มิเช่นนั้น มีแต่พังกับพัง
ดังเห็นได้จากสิ่งที่เรากำลังทำอยู่
