Good Developer หรือนักพัฒนาที่ดี ไม่ได้เป็นกันง่ายๆ แต่ถ้าใครต้องการพัฒนาตัวเอง ปรับปรุงตัวเอง ยกระดับความสามารถของตัวเองละก็ ต้องไม่มองข้ามเรื่องต่อไปนี้เด็ดขาด
ขึ้นชื่อว่านักพัฒนาแล้ว ส่วนใหญ่เราไม่มองกันแค่ เรื่องของ Code แล้วครับ เพราะการ Code ค่อนข้างที่จะเป็นเรื่องที่ มือใหม่สามารถเข้าใจได้ง่าย ศึกษาได้ง่าย อ่านมาจาก Document หรือ Tutorial ก็สามารถทำตามได้เลย แบบนี้ส่วนใหญ่ จะสามารถทำงานได้จบ แก้ปัญหาในส่วนที่ต้องการได้ ทำงานได้จริง แต่มีประสิทธิภาพและคุณภาพไหม อันนี้อาจจะอีกเรื่องนะครับ
แต่วันนี้จะมาช่วยคุยเรื่องที่ นักพัฒนาหลายคนอาจมองข้าม หรือยังไม่ให้ความสนใจกับตอนแรก อาจจะด้วยเวลาที่เร่งรีบในการส่งงาน หรือข้อกำหนดมากมายในตอนรับ Requirements จำนวนมาก การออกแบบระบบแบบเร่งรีบ เพื่อขึ้นงาน หรือเพื่อแบ่งงานกันในทีม
เรื่องอะไรบ้าง ที่มักถูกมองข้ามไป ถ้ายังไม่เป็น Good Developer
1.Requirement ไม่ใช่ทุกอย่าง
อยากจะบอกว่า เมื่อลูกค้าแจ้งความต้องการมา ว่าเค้าต้องการอะไรบ้าง จากระบบของเรา มันต้องทำงานแบบนั้น แบบนี้ คือกดตรงนั้น เพื่อให้แสดงแบบนี้ แล้วก็ส่งข้อมูลไปแบบนั้น เพื่อให้อีกฝ่ายได้ข้อมูลแบบนี้ จริงๆเรามองมันว่า มันคือ Logic นั้นแหละครับ แต่มันไม่ใช่ทุกอย่างของวิธีทำเท่านั้นเอง
วิธีการทำงาน มันไม่ใช่แค่การ เพิ่มปุ่มกดขึ้นมาแค่ 1 ปุ่มเอง ไม่เห็นจะยากเลย แต่ความเป็นจริงแล้ว การส่งข้อมูลออกมาจากจุดนึง ไปยังอีกจุดนึง เราต้องคำนวณแล้วว่า เหตุการณ์นั้น จะเป็นแค่การใช้ JavaScript เพิ่มปุ่มขึ้นมา 1 ปุ่ม Add ตัว Data ออกไปจากปุ่มแล้วส่งไปอีกหน้าก็พอ เก็บลงเป็น LocalStorage ก็ได้ หรือจะต้อง ทำการส่งข้อมูล Paremeter ไป Query ที่ Database แบบ API แล้วค่อยส่งมันกลับมาเพื่อไปอีกหน้าแล้วแสดงข้อมูลแทน
เราจะไม่คิดแค่ว่า เหตุการณ์แบบนี้ แค่เพิ่มปุ่ม 1 ปุ่ม เขียน Code แบบนี้ก็จบ แต่เราต้องมองข้ามไปว่า การเพิ่มปุ่มนี้ขึ้นมา จะแก้ปัญหาตรงนี้อย่างไร จำเป็นต้องเพิ่มไหม ถ้าไม่เพิ่ม ให้ระบบทำงานต่อไปเองเลยได้ไหม เพิ่มแล้วมีผลกระทบอย่างไร มีผลอะไรกับทรัพยากรหรือไม่ ดังนั้นต้องคิดไปให้ไกลกว่า การแค่ Code แต่ไม่ใช่มองทุกอย่างเป็นปัญหานะ เราแค่หาทางที่ดีที่สุด ในการแก้ปัญหานั้นเอง
2.ไม่รู้จักการ Config Architecture
ไม่น่าเชื่อ ว่ามีนักพัฒนาจำนวนมาก สามารถ Set config ระบบโครงสร้างต่างๆได้แค่เพียง เล็กน้อย ได้แค่เพียงทำงานได้ Run งานได้จริงเท่านั้น แต่ไม่สามารถแยกความแตกต่างของ Environment Production กับ Development ได้ นี้นับว่าเป็นปัญหาที่น่ากลัวมากๆ
เพราะ Architecture จะสามารถกำหนการ Code ได้ในระดับนึง เพราะมันสามารถระบุจำนวนการใช้งาน ความสามารถในการดึงข้อมูล ปริมาณ Ram, CPU, Bandwidth ที่ใช้ หรือแม้แต่ความรววดเร็วในการดึงหรือส่งข้อมูลในแต่ละครั้ง
จริงๆเรื่องนี้ นับว่าแก้ไขได้ง่าย ไม่ยากเลย เพียงเรารู้จักการทำงานของ Stack ของเราให้ดี ว่าใช้งานอะไรบ้าง หา Lab ทดลอง Set เล่นไม่กี่ครั้งก็น่าจะรู้จักไม่ยากแล้ว แต่เวลาพัฒนาจริงๆ ต้องนำข้อมูลมา Test ดูตลอดเวลา ว่าแต่ละ function ของเรานั้นทำงานอย่างไร ได้ผลลัพท์เป็นอย่างไร ปรับจูนตรงไหนเพิ่ม หรือแก้ไขตรงไหนได้หรือเปล่า
ยิ่งถ้ามีการใช้งาน npm, Docker, git หรือ Kubernetes อะไรแบบนี้ด้วยแล้ว คนที่เข้ามาร่วมใช้งาน ร่วมพัฒนาด้วยกัน ยิ่งต้องจำเป็นต้องรู้เลย ไม่ใช่แค่ให้ใครซักคน Set มาให้ คนที่เหลือใช้ตามนั้นก็พอ
3.Technical Dept ติดไว้ก่อนแล้วกัน
เรื่องนี้ไม่ควรเกิดขึ้นเลยจริงๆ เจ้านี่มันคือ หนี้ทางเทคนิค (คำไทย) ที่มักจะสร้างปัญหาให้เรา ตามหลังมาหลักจากที่ส่งมอบงานไปแล้ว หรือทำงานผ่านขุดนั้นไปแล้ว โดยปกติเป็นได้ทั้งตัวโครงสร้างของระบบที่เป็นปัญหา หรือขั้นตอนการพัฒนาและ Code ที่เป็นปัญหา
ปกติ Technical Dept มักเป็นเจ้ากรรมนายเวร ที่มาจากตอนที่ เราพยายามจะทำงานให้มันเสร็จๆไปก่อน ทำงานเร็วๆ ผ่านๆไปก่อน โดยไม่ทันได้มานั่งดู เรื่องของคุณภาพ ความเหมาะสม และแน่นอนว่า หากเราไม่ต้องการเจอกับสิ่งนี้ เราจำเป็นจะต้อง แก้ไขด้วยวิธีการต่างๆ ที่อาจถูกมองจากหัวหน้างาน หรือลูกค้า ว่าเสียเวลา ไม่จำเป็น
ตัวอย่างอาการของ Technical Dept ที่เกิดขึ้นได้บ่อยๆ เช่น ทำให้ใช้เวลาในการพัฒนานานมากขึ้น ต้องหาวิธีที่สั้นสุด ไม่ใช้ดีสุด มี Code ซ้ำๆกันเต็มไปหมด มี Code ไม่จำเป็นเกิดขึ้น มีค่า Code Coverage ต่ำกว่าที่ควร แถมยังอ่านยาก ทำความเข้าใจยาก
ส่วนการแก้ไขนั้นก็มีนะ แต่ต้องให้ความสำคัญกับมันมากๆ เช่น ถ้า Code ไม่ดี ต้องขอเวลาเพิ่ม ต้องเพิ่มขึ้นตอนในการทดสอบทั้ง Test-Drivent หรือทำการ Unit Testing ตลอดเวลาที่ Code และต้องใช้แนวคิดการ Clean code, Reuseable มาปรับใช้
ถ้าคุณมองว่า 3 ข้อนี้ไม่ใช่เรื่องสำคัญเมื่อไหร่ แปลว่าเรายังหลุดพ้นจากการทำงานที่มีมาตรฐานาสูงไม่ได้นะครับ และ 3 อย่างนี้ เป็นเรื่องพื้นฐานจริงๆ ที่เหล่า Goode Developer ควรจะยึดมั่น เอาไว้ในการทำงานของตัวเอง อยู่เสมอ เพื่อให้งานของเค้า มีประสิทธิภาพที่ดีครับ
ขอให้สนุกกับการ Develop และ Learning ตอลดเวลาครับ
คุณอาจสนใจเรื่อง เมื่อนักพัฒนายุคใหม่ ไม่ค่อยสนใจพื้นฐาน Fundamental
ขอบคุณภาพสวยๆจาก Emile Perron on Unsplash
