ในฐานะวิศวกรซอฟต์แวร์รุ่นเยาว์ฉันมักอ่านข้อคิดเห็นเกี่ยวกับรหัสที่ฉันได้รับเพื่อเรียนรู้วิธีการเป็นผู้เขียนโค้ดที่ดีขึ้น แต่เมื่อถึงเวลาที่ฉันจะลองทบทวนรหัสครั้งแรกของฉันฉันรู้ว่าประสบการณ์ของฉันไม่ได้เตรียมให้ฉันไปอยู่อีกด้านหนึ่ง
ฉันพัฒนากลุ่มอาการของโรค imposter อย่างรุนแรงและวนคำถาม: ฉันควรแสดงความคิดเห็นในบรรทัดของรหัสนี้หรือไม่คุ้มหรือไม่ ฉันควรค้นหาบทความเพื่อสนับสนุนทุกความคิดเห็นหรือไม่ ฉันจะขัดข้องเว็บไซต์โดยอนุมัตินี้หรือไม่ พวกเขาจะเกลียดฉันหรือไม่ โอเคฉันยอมรับว่าฉันเป็นเกลียวอย่างรวดเร็ว แต่หลังจากพูดคุยกับเพื่อนร่วมงานบางคนฉันรู้ว่าฉันไม่ได้อยู่คนเดียวในความกังวลของฉัน
วิศวกรซอฟต์แวร์รุ่นจูเนียร์อาจถูกโยนลงไปในการตรวจสอบรหัสโดยมีสมมติฐานคล้ายกับ“ คุณรู้วิธีอ่านหนังสือเพื่อให้คุณรู้วิธีการเขียนหนังสือที่ไม่เป็นความจริง” เจสสิก้า Rudder วิศวกรประสบการณ์ของ GitHub กล่าว
มีความคาดหวังที่มาพร้อมกับการตรวจสอบโค้ดและกระบวนการสามารถทำให้โกรธได้ ดังนั้นฉันจึงสัมภาษณ์วิศวกรซอฟต์แวร์อีกเจ็ดคนเพื่อรวบรวมเคล็ดลับเกี่ยวกับวิธีสร้างความคิดการทบทวน
1. คิดเกี่ยวกับผลกระทบโดยรวม
โดยทั่วไปคำขอการดึงที่ดี (PR) ควรส่งผลกระทบต่อส่วนที่ จำกัด ของ codebase เท่านั้น อย่างไรก็ตามขอบเขตที่ จำกัด ไม่ควรป้องกันคุณจากการคิดเกี่ยวกับการเปลี่ยนรหัสภายในบริบทของ codebase ขนาดใหญ่
Nigel Munoz อดีตวิศวกรเต็มกองที่ The Muse และวิศวกรซอฟต์แวร์อิสระปัจจุบันสนับสนุนให้ผู้ตรวจสอบคิดว่า "การเปลี่ยนแปลงนี้มีผลต่อภาพขนาดใหญ่และขนาดเล็กหรือไม่" การพิจารณาภาพที่ใหญ่ขึ้นรวมถึงการค้นหาหนี้ทางเทคนิค - มองหารหัส ที่ซ้ำแล้วซ้ำอีกไม่ใช่โมดูล่าร์หรือไม่เป็นไปตามอนุสัญญามาตรฐานล่าสุดเช่นเดียวกับการวิเคราะห์การดัดแปลงสถาปัตยกรรมของโค้ดเบส
Sam Donow ผู้พัฒนาหลักของ Hudson River Trading เชื่อว่า“ ไม่มีอะไรใหญ่หรือเล็กเกินไปที่จะแสดงความคิดเห็น คำแนะนำสำหรับการปรับปรุงเล็ก ๆ อาจนำไปสู่การปรับปรุงที่ใหญ่ขึ้นในหลาย ๆ ส่วนของ codebase”
คุณสามารถใช้ความคิดเห็น PR ใน GitHub เพื่อให้ข้อเสนอแนะในเชิงบวกเช่นเดียวกับชี้ให้เห็นว่ารหัสอาจแตกต่างจากอนุสัญญามาตรฐานของกรอบการตอบสนอง
ตัวอย่างเช่นในระหว่างการตรวจสอบโค้ดของฉันฉันได้รับความคิดเห็นว่าคุณสมบัติบางอย่างในองค์ประกอบ React ทำให้เกิดความสับสนซึ่งทำให้เกิดคำถามที่กว้างขึ้นเกี่ยวกับวิธีการใช้ส่วนประกอบ ท้ายที่สุดฉันลบคุณสมบัติออกจากส่วนประกอบดั้งเดิมและสร้างส่วนประกอบแยกต่างหากเพื่อชี้แจงพฤติกรรมของแต่ละคนและให้แน่ใจว่าทั้งสองสามารถใช้งานได้ในที่ต่างๆ
2. พิจารณาความปลอดภัย
อย่าลืมว่าการเปลี่ยนแปลงบางอย่างอาจส่งผลกระทบมากกว่าแค่โค้ดเบส Rudder แนะนำให้ประเมินว่าผู้ใช้“ สามารถใช้ฟังก์ชั่นนี้เพื่อก่อกวนใครบางคนหรืออาจใช้ระบบในทางที่ผิด” ตัวอย่างเช่นหากฟีเจอร์ใหม่ในคำขอดึงมีการป้อนข้อมูลของผู้ใช้ให้มองหา SQL injection, data access, cross-site scripting ช่องโหว่ความปลอดภัยอื่น ๆ
3. มุ่งเน้นที่ข้อบกพร่อง
ผู้มีส่วนร่วมในรหัสของคุณไม่ว่าหุ่นยนต์จะเป็นอย่างไร - มนุษย์และมนุษย์อาจทำลายหรือลืมฟังก์ชันการทำงาน ดังนั้นให้แน่ใจว่าคุณ“ ทบทวนการทดสอบที่มีความสำคัญเช่นเดียวกับส่วนที่เหลือของรหัส” ให้คำแนะนำ Abhishek Pillai ผู้นำด้านเทคโนโลยีที่อาจารย์จ่ายอาจารย์ “ พวกเขาจะป้องกันข้อผิดพลาดใหม่ ๆ และใช้เป็นรูปแบบของเอกสารให้กับคนอื่น ๆ ที่ทำงานเกี่ยวกับเรื่องนี้ในอนาคต”
การอ่านการทดสอบสามารถช่วยให้คุณเข้าใจการทำงานของคุณสมบัติใหม่และดูกรณีต่าง ๆ ที่จะนำเสนอในขณะที่การวิเคราะห์การทดสอบสามารถช่วยคุณชี้กรณีที่ขาดหายไปและค้นหาคุณลักษณะที่ไม่อยู่ใน PR นี้ หากไม่มีการทดสอบรวมอยู่ในการเปลี่ยนรหัสและดูเหมือนว่ามีความเกี่ยวข้องควรขอให้ทำการตรวจสอบภายใน
แต่การทดสอบไม่ใช่ทุกอย่าง “ อย่าเชื่อในระบบมากเกินไป” Donow เตือน “ เพียงเพราะการทดสอบวิ่งไม่ได้หมายความว่าไม่มีข้อบกพร่อง”
คุณอาจต้องการ "เรียกใช้แอปในเครื่องเพื่อทดสอบและทำให้แน่ใจว่าใช้งานได้ ถ้ามันใช้ไม่ได้ผลก็จะไม่มีประโยชน์ในการตรวจสอบเพิ่มเติม” Ryan Verner ผู้พัฒนาซอฟต์แวร์ที่ 8th Light กล่าว แม้ว่าผู้ตรวจสอบบางคนไม่คิดว่าการทดสอบด้วยตนเองควรเป็นส่วนหนึ่งของกระบวนการตรวจสอบโค้ดซึ่งส่วนหนึ่งเป็นเพราะเวลาที่ใช้ - เวอร์เนอร์เชื่อว่าเป็นวิธีที่รวดเร็วในการพิจารณาว่าคุณควรลงทุนเวลามากขึ้นในการตรวจสอบรวมถึงกลยุทธ์ การเติบโตของบั๊กที่ค้าง
4. เป็นผู้เล่นทีม
ความคิดโบราณใช้ความหมายใหม่เมื่อพูดถึงการตรวจสอบโค้ด “ ใช้เวลาในการตรวจสอบเพราะมันเป็นรหัสฐานของทุกคน” เวอร์เนอร์ผู้สนับสนุนความรู้สึกของ“ ความเป็นเจ้าของร่วมกัน” คุณในฐานะผู้ตรวจทานควรจะทำงานเพื่อปกป้องงานในมือของแมลงจากการเติบโตที่ใหญ่ขึ้น ทีมทำงานน้อยลงสาย
Pillai ใช้ gif เพื่อเฉลิมฉลองการประชาสัมพันธ์และการผสาน PR ของเพื่อนร่วมทีม
ในเวลาเดียวกัน Charles Luxton ผู้นำด้านเทคโนโลยีของ The Muse สนับสนุนให้ผู้วิจารณ์เข้าใจและจดจำลำดับความสำคัญของทีม ด้วยกำหนดเวลาที่ใกล้เข้ามาและความไม่ลงรอยกันอย่างรวดเร็วบางครั้งการสร้างไอเท็มสิ่งที่ต้องทำสำหรับงานในมือที่ทำให้มั่นใจว่าจะมีการปรับปรุงในอนาคตและแสดงความคิดเห็นเกี่ยวกับรหัสที่เป็นปัญหาในขณะเดียวกันคือ Band-Aid ที่คุณต้องการ ทำให้ทีมของคุณมีความสุข
สุดท้ายถามตัวเองว่ารหัสจะสมเหตุสมผลกับคนที่เพิ่งเข้าร่วมทีมและอ่านรหัสภายในสองสามสัปดาห์แรกจะช่วยให้รหัสของคุณสามารถอ่านและเข้าใจได้
5. ใช้กระบวนการเรียนรู้และการแบ่งปันความรู้
กระบวนการตรวจสอบช่วยให้ทุกคนมีส่วนร่วมในการทำความเข้าใจเพิ่มเติมเกี่ยวกับ codebase ภาษากรอบงานและแนวทางปฏิบัติที่ดีที่สุด
Matt Jeffery ผู้นำด้านเทคโนโลยีของ The Muse แนะนำให้ผู้ตรวจสอบ "เข้าใจการเปลี่ยนแปลงทางสถาปัตยกรรมวิธีหนึ่งคือการอ่านชื่อไฟล์เนื่องจากช่วยในการกำหนดบริบทตัวอย่างเช่นหากคุณกำลังมองการเปลี่ยนแปลงในเลเยอร์การเข้าถึงข้อมูล คุณรู้ว่าคุณไม่ได้จัดการกับตรรกะทางธุรกิจหรือ UI "
คุณสามารถใช้ความคิดเห็น PR ใน GitHub เพื่อแบ่งปันเอกสาร
เมื่อคุณเรียนรู้จากการเปลี่ยนแปลงรหัสคุณยังมีโอกาสแบ่งปันความรู้ “ เป็นการดีที่สุดที่จะอธิบายความคิดเห็นของคุณและสำรองข้อมูลด้วยเอกสาร” Luxton กล่าว ลิงก์ที่คุณให้ไว้เพื่อสนับสนุนหลักฐานและบทความที่น่าเชื่อถือไม่เพียง แต่ช่วยให้ผู้ตรวจสอบและผู้เขียนโค้ดสำรวจแนวทางที่แตกต่างกันเมื่อพวกเขาตัดสินใจขั้นสุดท้าย แต่ยังช่วยเสริมความรู้ในการเขียนโปรแกรม
ในขณะที่คุณคำนึงถึงเคล็ดลับเหล่านี้โปรดจำไว้เช่นกันว่าการทบทวนคือเวลาที่จะฝึกฝนทักษะของผู้คน “ ให้ผู้คนได้รับประโยชน์จากความสงสัยที่พวกเขาคิดเกี่ยวกับวิธีการของพวกเขาและชี้ให้เห็นถึงความเป็นไปได้ที่แตกต่างกันในขณะที่พยายามขจัดความเป็น Defensiveness” Rudder กล่าว “ ฉันแสดงความคิดเห็นไปตลอดและสรุปความเห็น - นี่คือสิ่งที่ดีเยี่ยมนี่คือสิ่งที่สามารถปรับปรุงได้นี่คือสิ่งที่ต้องเปลี่ยนก่อนที่จะรวมเข้าด้วยกัน”
ด้วยวิธีการนี้ไม่เพียง แต่คุณจะปกป้องฐานรหัสของคุณจากหนี้เทคโนโลยีภัยคุกคามความปลอดภัยและข้อบกพร่อง แต่คุณจะสร้างทีมของคุณด้วย
