วิธีประสบความสำเร็จด้วย Code Review
Code Review เป็นหัวข้อที่มีความเกี่ยวข้องอย่างมากในทุกวันนี้ ผู้คนจำนวนมากคิดเกี่ยวกับเรื่องนี้เหมือนเป็นคอขวด และคนอื่นๆ ก็ให้ความสำคัญกับเรื่องนี้เป็นอย่างมาก เรามาพูดถึงวิธีประสบความสำเร็จ (สำหรับทั้งทีม ไม่ใช่แค่คุณ) ในส่วนสำคัญอย่างยิ่งนี้ในกระบวนการสร้างซอฟต์แวร์
ปัญหาและวิธีแก้ไข (หรือหลีกเลี่ยง)
โดยปกติ เมื่อคุณพัฒนาคุณลักษณะใหม่บางอย่างเสร็จแล้ว และคุณมี Pull Request ที่พร้อมสำหรับการตรวจสอบ ปัญหาบางอย่างจะเกิดขึ้น:
ไม่มีใครทำรีวิว.
ใช่ นี่เป็นเรื่องธรรมดามาก คุณใช้ความพยายามทั้งหมดในการทำสิ่งที่ดีที่สุดเท่าที่จะทำได้และไม่มีใครตรวจสอบ
มีบางสิ่งที่คุณสามารถปรับปรุงได้:
- คุณแจ้งเตือนผู้อื่นในทางที่ผิด: บางทีการมอบหมายใครสักคนบน Github PR อาจไม่เพียงพอใช่ไหม ส่งลิงก์อย่างสนุกสนานในช่อง Slack บางช่องเพื่อดึงดูดความสนใจหรือถามโดยตรง
- เพื่อนตรวจสอบโค้ด: ใช่ เพียงสร้างเพื่อนช่วยตรวจสอบโค้ด (อย่างน้อยหนึ่งคน) คุณสามารถตรวจสอบการประชาสัมพันธ์ของกันและกันได้ตลอดเวลาและทำงานของคุณอย่างรวดเร็ว เป็นการประนีประนอมที่ต้องทบทวนซึ่งกันและกัน
- ทำหน้าที่ของคุณ: จำไว้ว่าส่วนหนึ่งของเกมนี้คือคุณต้องแสดงความคิดเห็น ขอเปลี่ยนแปลง และอนุมัติการประชาสัมพันธ์ผู้คนของผู้อื่น หากคุณช่วยผู้อื่นปรับปรุงโค้ดของพวกเขา พวกเขาจะช่วยคุณในลักษณะเดียวกัน (หรือเป็นไปได้มากกว่าที่พวกเขาจะแสดงความคิดเห็นและอนุมัติในที่สุด)
- มีการเปลี่ยนแปลงมากเกินไป: หนึ่งในสาเหตุที่น่าจะเป็นไปได้มากที่สุดก็คือ PR ของคุณใหญ่เกินไป! ดังนั้น พยายามทำให้การเปลี่ยนแปลงของคุณสั้นและกระชับ อย่าไปปรับโครงสร้างใหม่อย่างบ้าคลั่ง (การสอดแนมเด็ก) และพยายามแบ่งงานของคุณเป็นคำขอดึงให้มากขึ้น บางทีการแบ่งงานในส่วนนี้อาจเริ่มต้นจากการวางแผนทีมหรือการประชุมปรับแต่ง :)
คนรีวิวเยอะมาก
และเรายังมีปัญหาตรงกันข้ามอีกด้วย คุณใส่ข้อความตรวจสอบโค้ดในช่อง "ทั่วไป" ใน Slack และทันใดนั้น ผู้ชายจำนวนมากก็มีเวลาตรวจสอบโค้ด PR ของคุณ ตอนนี้คุณมีการเปลี่ยนแปลงและคำขอการเปลี่ยนแปลงมากเกินไปที่คุณต้องแก้ไขเพื่อให้คุณสามารถรวมการเปลี่ยนแปลงของคุณได้
- เริ่มขอให้คนเพียงคนเดียวตรวจสอบ คุณสามารถลองทำเช่นนี้กับเพื่อนร่วมงานคนหนึ่งที่คุณรู้ว่าจะตรวจสอบทุกอย่างได้ดีมากและคุณไว้วางใจ แก้ไขความคิดเห็นของเขาก่อน จากนั้นคุณจะสามารถปรับปรุง PR ของคุณให้ละเอียดยิ่งขึ้นและด้วยการอนุมัติเบื้องต้นเพียงครั้งเดียว จากนั้น สื่อสารให้ผู้อื่นทราบในวงกว้างยิ่งขึ้นเพื่อตรวจสอบ ณ จุดนี้ ผู้คนควรแสดงความคิดเห็นและการอนุมัติเพียงเล็กน้อยเท่านั้น
- เพื่อนที่คอยตรวจสอบโค้ด (ใช่แล้ว วิธีนี้ใช้ได้ผลดีในการป้องกันปัญหานี้ด้วย)
- แก้ไขความคิดเห็นทั้งหมดและขอรอบที่สองพร้อมกัน: อย่าไปแก้ไขความคิดเห็นโดยนักพัฒนาเท่านั้น แต่ให้แก้ไขทุกอย่างก่อน
การอภิปรายทางเทคนิคเกี่ยวกับความคิดเห็น
โดยปกติแล้ว นักพัฒนาซอฟต์แวร์ชอบที่จะถกเถียงทางเทคนิคเป็นครั้งคราว โดยทั่วไป นี่เป็นสิ่งที่ดีและทำให้คุณเรียนรู้มากขึ้นและสามารถระบุเทคโนโลยีหรือแนวคิดทางเทคนิคใหม่ๆ ที่คุณไม่เคยรู้มาก่อน แต่ปัญหาคือบางคนมักจะทำเช่นนี้ใน Code Review
เมื่อประสบปัญหานี้ และการอภิปรายเกี่ยวกับการเปลี่ยนแปลงบางอย่างร้อนแรงเกินไปหรือยืดเยื้อเกินไป คุณสามารถทำสิ่งต่อไปนี้:
- หยุดทันที: ติดต่อนักพัฒนารายอื่นเป็นการส่วนตัวเพื่อหารือเกี่ยวกับความคิดเห็น บางครั้งคุณทั้งคู่ต้องการคำอธิบายแบบเห็นหน้ากันเพื่อทำความเข้าใจข้อโต้แย้งและข้อเสนอแนะอย่างถ่องแท้
- อย่าถือเป็นเรื่องส่วนตัว: ทำให้เป็นมืออาชีพ
- อธิบายตัวเองโดยใช้ข้อโต้แย้งที่แท้จริงและสอดคล้องกัน: เช่น รูปแบบการออกแบบ สถาปัตยกรรม แนวทางสไตล์ หรือแม้แต่ประสบการณ์ก่อนหน้านี้ พยายามไม่เพียงแค่อยู่กับความคิดเห็นเท่านั้น
- รักษาจุดมุ่งเน้นในการนำเสนอคุณลักษณะนี้ให้กับลูกค้า: บางครั้ง มีคนแนะนำแนวทางที่แตกต่างกันในการทำสิ่งเดียวกัน เปรียบเทียบข้อดีข้อเสียของการใช้งานทั้งสองแบบ อาจไม่จำเป็นต้องปรับปรุงเวลาดำเนินการ 0.0001ms หรือคำแนะนำของเขาอาจปรับปรุงการบำรุงรักษาโค้ดของคุณได้มาก หากเวลาที่ใช้ในการแก้ไขไม่มากนักและเพิ่มมูลค่าที่แท้จริง ให้ปรับปรุงให้ดีขึ้น!
- เมื่อคุณทั้งคู่บรรลุข้อตกลงให้เขียนข้อสรุปในการประชาสัมพันธ์
สิ่งที่ดี
เมื่อคุณมีจังหวะการทำงานที่ดีและเพื่อนร่วมงานของคุณแสดงความคิดเห็นที่เป็นประโยชน์ คุณจะเห็นประโยชน์มากมายเกี่ยวกับเรื่องนี้:
- ลดความเสี่ยงที่จะมีปัญหากับ QA
- มอบคุณสมบัติที่มีคุณภาพ
- คุณเรียนรู้มากมายจากนักพัฒนาคนอื่นๆ และคนอื่นๆ เรียนรู้จากคุณ (การถ่ายทอดความรู้)
- ความผูกพันในการทำงานเป็นทีมที่ดีขึ้น คุณลักษณะนี้ไม่เพียงแต่พัฒนาโดยคุณเท่านั้น แต่ยังรวมถึงทักษะของเพื่อนร่วมงานและความสำเร็จของคุณลักษณะนี้จะถูกแบ่งปันระหว่างทั้งทีม
บทสรุป
โปรดจำไว้ว่าการทำงานเป็นทีมเป็นสิ่งสำคัญที่นี่ การตรวจสอบโค้ดไม่ควรปิดกั้นคุณหรือทีมของคุณ เป็นโอกาสที่ดีที่จะสร้างสิ่งที่ยอดเยี่ยมร่วมกันและเรียนรู้จากกันและกัน
หากคุณคิดว่าฉันต้องเพิ่มบางอย่าง เพียงแจ้งให้เราทราบในความคิดเห็น และแบ่งปันประสบการณ์ของคุณด้วย!
หวังว่าพวกคุณจะชอบบทความนี้ ขอให้มีวันดีๆ นะ!
กอนซาโล พี.
