ใน go 1.26 นั้นทางทีมพัฒนาได้ปล่อย go fix ออกมาเขียนใหม่หมดเลย โดยที่มีโครงสร้างเหมือนกับ go vetนั่นคือใช้งาน go analysis frameworkโดยใน go fix จะมี analyzer สำหรับภาษา go ใหม่ ๆมาให้เพียบน่าจะช่วยให้ง่ายต่อการปรับปรุง code ให้ดียิ่งขึ้น และ modern มากขึ้นดังนั้นมาลองใช้งานกัน
วันนี้ทำการ review code ที่เขียนด้วยภาษา Go กับทีมพบว่ามี pattern แปลก ๆ มาใน code ด้วยอาจจะเรียกได้ว่าเป็น B.A.D code ก็ได้ซึ่งขึ้ยอยู่กับ use case ด้วยเช่นกันเลยทำการสรุปไว้นิดหน่อย เพื่อใช้ในการปรับปรุงต่อไป
การทำ code review ในขั้นตอนการพัฒนา software นั้น เป็นสิ่งที่จำเป็น และ ควรเป็นสิ่งที่เกิดขึ้นอยู๋ตลอดเวลาหรือบ่อยที่สุดโดยไม่รู้เหมือนกันว่าจะทำตอนไหนอย่างไร ?เพราะว่า มันขึ้นอยู่กับสถานการณ์ หรือ ข้อจำกัดอะไรบางอย่างแต่ควรทำให้บ่อย ๆ และงด drama ให้มากที่สุด
เช้านี้เจอการ์ตูนเกี่ยวกับ Code Review เรื่อง The secret of a successful code reviewมีความคิดเห็นอย่างไรกันบ้าง กับแนวคิดนี้ !!!
วันนี้ทำการ review code นิดหน่อย พบ code ที่น่าสนใจเยอะพอสมควร หนึ่งในนั้นคือ code เกี่ยวกับการ mapping error code โดยมีขั้นตอนดังนี้ ทำการตรวจสอบว่า Exception แต่ละตัวจากนั้นกำหนด error code ให้ ทำการดึงรายละเอียดของ error ด้วย error code จาก Database !! ปล. ดึงข้อมูลจาก database ไม่ค่อยดีนะ !!
จากหนังสือ Programming Beyond Practices (Be more than just a code monkey) ได้แนะนำขั้นตอนการ review code ที่น่าสนใจดังนั้น ลองคิดดูสิว่า ถ้าเราเป็นลูกค้า หรือ ผู้ว่าจ้าง โดยที่รู้ด้วยว่าการเปลี่ยนแปลง code ต่าง ๆ จะเกิดผลกระทบ หรือ มีความเสี่ยงอะไรบ้าง ? เราน่าจะลดขั้นตอนการ review ต่าง ๆ ลงไป แล้วมาพยายามส่งมอบระบบงานให้ได้บ่อย ๆ ดีกว่าไหม
ในการพัฒนา software นั้นการทำงานเป็นทีมมันสำคัญมาก ๆ ยิ่งเรื่องของ code ที่มีคุณภาพ (Code Quality) ยิ่งสำคัญมากขึ้นไปอีก แต่สิ่งยากกว่าคือ จะทำการ review code อย่างไรดี ? เนื่องจากแต่ละคนในทีมล้วน มีสิ่งที่ต้องทำ มีสิ่งที่ต้องแก้ไข มีการเรียงลำดับความสำคัญของงานที่ต่างกัน ที่สำคัญคือ ทีมส่วนใหญ่เน้นการทำให้เสร็จมาก่อนทำให้ดี !! สิ่งที่ตามมาคือ การ rework หรือแก้งานเดิม ๆ อยู่ตลอดเวลา ดังนั้นก่อนอื่นเรามาทำความเข้าใจกับการ review code ก่อนว่า มันมีเป้าหมายอะไรบ้าง ? เพื่อทำให้ทุกคนในทีมมีความเข้าใจตรงกันและเห็นความสำคัญอีกด้วย
วันนี้ Swift developer ทำการตรวจสอบรูปแบบของ source code กันหรือไม่ ? มีข้อตกลงในการเขียน code ( Code convention ) หรือไม่ ? ถ้ายังไม่มีขอแนะนำ SwiftLint ซึ่งจะช่วยเหลือเรื่องดังกล่าวอย่างมาก โดยอ้างอิงรูปแบบจาก Swift style guide ดังนั้นมาดูการใช้งานกันนิดหน่อย
ข้อมูลจากผลแบบสำรวจ State of code quality 2016 โดย Smartbear.com โดยผู้ทำแบบสำรวจเป็น software developer และ tester กว่า 600 คน เป้าหมายเพื่อสอบถามว่า มีความพึงพอใจกับคุณภาพของ code ที่พัฒนาขึ้นมาหรือไม่ ? และทำการปรับปรุงคุณภาพขึ้นมาได้อย่างไร ? ซึ่งเป็นสิ่งที่สำคัญอย่างมากในการพัฒนา software ดังนั้นมาดูผลสรุปที่น่าสนใจกันนิดหน่อย
Code Review เป็นแนวปฏิบัติที่ช่วยเหลือเรา และ ทีม เพื่อปรับปรุงความสามารถ และ สร้าง software คุณภาพดี ๆ ออกมา ซึ่งทีมส่วนใหญ่รู้ และ เข้าใจว่ามันมีประโยชน์อย่างมาก แต่ปัญหาที่มักเกิดขึ้นคือ การประยุกต์เพื่อนำมาใช้งาน !! ทำไมนะ