วันนี้ได้อ่านบทความเรื่อง How to prevent eventual crappiness ซึ่งได้อธิบายไว้ว่า Eventual crappiness – eventually all software will become crap มาดูกันว่ามันคืออะไร ? มีข้อเสียอะไรบ้าง ? และเราสามารถป้องกันได้อย่างไร
code-review Archive
ทำไมต้องทำ Code Review ด้วยล่ะ ?
ผมเชื่อว่า หลาย ๆ บริษัท หลาย ๆ ทีม มีการนำ Code Review มาใช้งานแล้ว เนื่องจากมันมีเหตุผลดี ๆ มากมาย แต่กลับพบว่า ผู้นำไปใช้งานกลับหลงลืม เป้าหมายพื้นฐานของ Code Review ไปเสียหมด !! ทำให้ Code Review กลับกลายเป็นกิจกรรมที่น่ารังเกียจ Code Review กลับกลายเป็นกิจกรรมที่น่ากลัว Code Review กลับกลายเป็นกิจกรรมที่ไม่มีใครชอบ Code Review กลับกลายเป็นกิจกรรมที่กล่าวโทษ Code Review กลับกลายเป็นกิจกรรมที่หาคนผิดมาลงโทษ ทำไมนะ
สิ่งที่ได้เรียนรู้จากการทำ Code Review
บ่อยครั้งมีโอกาสทำการ review code ของระบบต่าง ๆ โดยก่อนที่จะเริ่ม review นั้น มักจะถามก่อนว่า เป้าหมายของการ review code คืออะไร ? ผลลัพธ์ที่คาดหวังจากการ review code เป็นอย่างไร ? ทำการตัดสินใจต่อไปอย่างไร หลังจากการ review ? สิ่งที่น่าแปลกใจก็คือ เราจะรู้ว่าเรามีปัญหาเรื่อง คุณภาพ ก็ต่อเมื่อมันทำให้เราช้าลงไปอย่างมาก ทำไมนะ
เราทำการ refactor code มากน้อยเพียงใด
ตามแนวคิด TDD (Test-Driven Development) นั้น การ refactoring นั้นถือได้ว่าเป็นสิ่งที่มีประโยชน์อย่างมากมาย เนื่องจาก ถ้าขาดการ refactoring แล้ว จะทำให้ code ในระบบของเรานั้นมี technical debt เพิ่มมากขึ้นเรื่อยๆ สุดท้ายถ้ามีมากขึ้นเรื่อยๆ จนต้องโยน code ชุดนี้ไป และต้อง rewrite ระบบเดิมขึ้นมาใหม่
Java Code Smell :: ทำไมถึงต้องใช้ cast type และ instanceof
วันนี้ทำการ review code มาเจอ code ที่น่าสนใจ เกี่ยวกับการ cast type ของ object และการใช้ instanceof มาเพื่อตรวจสอบว่า เป็น instance ของ class ที่เราต้องการหรือไม่ มาดูกันว่ามันเป็นอย่างไร
How to kill Code Review ?
กิจกรรม code review นั้น เป็นสิ่งที่ขาดไม่ได้เลยในการพัฒนา software เพื่อช่วยปรับปรุง code ที่เราพัฒนาขึ้นมา ให้มันดียิ่งขึ้น รวมทั้งเป็นการแบ่งปันความรู้ต่างๆ ซึ่งกันและกัน แต่ในการทำงานจริงๆ แทบจะไม่มีใครทำ code review เลย !! มันแปลกดีนะ … หรือมีก็มีตำแหน่ง code reviewer ขึ้นมา ซึ่งก็กลายเป็นคอขวด หรือ ปัญหาขึ้นมาอีก โดยไม่ได้ปรับปรุง code และ กระบวนการพัฒนา software มันดีขึ้นเลย หลายครั้งกลับทำให้เลวร้ายลงไปอีก เนื่องจาก code review กลายเป็นการจับผิดไปซะอย่างนั้น !!
4 No สำหรับการทำ code review
Code review หรือ peer review มันคือ แนวปฏิบัติหลักของการพัฒนา software ซึ่งทีมพัฒนา software จะต้องปฏิบัติอยู่อย่างสม่ำเสมอ สามารถทำได้หลายลักษณะเช่น Pre-merge ทำการ review code ก่อน merge code เข้า branch หลัก เพื่อป้องกันความผิดพลาดต่างๆ Post-merge ทำการ review หลังจากที่ทำการ merge code แล้ว โดยมักจะเป็นกิจกรรมที่ถูกกำหนดไว้แล้ว (regular review) เพื่อหาข้อผิดพลาด และ สิ่งที่ผิดปกติต่างๆ โดยในบางทีมทำทั้งสองแบบก็จะเยี่ยมมากๆ นะ แต่เท่าที่เห็น แค่มี Code review ก็ยากลำบากล่ะ !!
ในปี 2015 คุณอยากทำอะไร เพื่อทำให้การพัฒนา software ดีขึ้น
ในปี 2015 นี้ คุณในฐานนะที่เป็นนักพัฒนา software นั้น ถ้าให้เลือกทำ technical practice อย่างใดอย่างหนึ่ง เพื่อทำให้การพัฒนา software ดีขึ้น คุณอยากจะทำอะไร
ตอนที่ 02 :: 97 สิ่งที่ developer ควรรู้ :: Code Review
เรื่องที่สองที่นักพัฒนาควรรู้ และ เข้าใจก็คือ Code Review เป็นเรื่องที่ทีมพัฒนาควรจะต้องทำกันเลย คำถาม ทำไมเราถึงต้องทำล่ะ ? คำตอบ เพราะว่าเราต้องการเพิ่มคุณภาพของ code และลดจำนวน defect/bug ลงไงล่ะ แต่เหตุผลมันคงไม่เพียงพอมั้ง เพราะว่านักพัฒนาส่วนใหญ่ก็ไม่ทำกัน !!
ทุกวันนี้คุณตรวจสุขภาพของ Software ที่พัฒนากันอย่างไร
ในการพัฒนา software นั้น ยิ่งนานไปก็ยิ่งมีความซับซ้อนเพิ่มขึ้นเรื่อยๆ ซึ่งถ้าเราไม่สามารถจัดการความซับซ้อนเหล่านี้ได้ จะส่งผลให้ software ที่เราพัฒนาขึ้นมามันแย่ หรืออาจจะล้มไม่เป็นท่าก็ได้ ดังนั้น ถ้าเราสามารถรู้ได้ว่าใน software ที่เราสร้าง มีอัตราความซับซ้อนเพิ่มขึ้นอย่างไร และ เท่าไร ก็น่าจะทำให้เห็นว่าสิ่งที่เราพัฒนามีความเสี่ยงอย่างไร และจะแก้ไขอย่างไร ใช่ไหม ? แต่เราจะวัดค่าความซับซ้อน รวมทั้งค่าอื่นๆ ใน software ของเราอย่างไรดีล่ะ