นำ Mindset การตรวจสอบโค้ดที่ดีต่อสุขภาพมาสู่ทีมของคุณ

'การตรวจสอบโค้ด' เป็นช่วงเวลาในกระบวนการพัฒนาที่ คุณ (ในฐานะนักพัฒนา) และเพื่อนร่วมงานของคุณทำงานร่วมกันและค้นหาจุดบกพร่องภายในโค้ดล่าสุดก่อนที่จะเผยแพร่ ในช่วงเวลาดังกล่าว คุณสามารถเป็นผู้เขียนโค้ดหรือเป็นหนึ่งในผู้ตรวจสอบได้

เมื่อทำการตรวจสอบโค้ด คุณอาจไม่แน่ใจว่ากำลังมองหาอะไรอยู่ ในอีกด้านหนึ่ง เมื่อส่งการตรวจสอบโค้ด คุณอาจไม่รู้ว่าต้องรออะไร การขาดความเห็นอกเห็นใจและความคาดหวังที่ไม่ถูกต้องระหว่างทั้งสองฝ่ายสามารถกระตุ้นสถานการณ์ที่โชคร้ายและเร่งกระบวนการจนกว่าจะจบลงด้วยประสบการณ์ที่ไม่พึงประสงค์สำหรับทั้งสองฝ่าย

ในบทความนี้ ฉันจะแบ่งปันว่าผลลัพธ์นี้สามารถเปลี่ยนแปลงได้อย่างไรโดย เปลี่ยนความคิดของคุณ ระหว่างการตรวจทานโค้ด:

• เป็นทีม
• ในฐานะนักเขียน
• เป็นนักวิจารณ์

ทำงานเป็นทีม

ส่งเสริมวัฒนธรรมแห่งการทำงานร่วมกัน

ก่อนที่เราจะเริ่มต้น สิ่งสำคัญคือต้องเข้าใจถึงคุณค่าของสาเหตุที่โค้ดต้องได้รับการตรวจสอบ การแบ่งปันความรู้และความสามัคคีในทีมเป็นประโยชน์ต่อทุกคน อย่างไรก็ตาม หากทำด้วยความคิดที่ไม่ดี การตรวจสอบโค้ดอาจเป็นเวลาที่ผู้บริโภคจำนวนมากได้รับผลลัพธ์ที่ไม่น่าพอใจ

ทัศนคติและพฤติกรรมของทีมควรยอมรับคุณค่าของการทำงานร่วมกันโดยไม่ตัดสิน โดยมี เป้าหมายร่วมกันในการเรียนรู้และแบ่งปัน โดยไม่คำนึงถึงประสบการณ์ของคนอื่น

รวมรีวิวโค้ดในการประมาณการของคุณ

การตรวจสอบโค้ดที่สมบูรณ์ต้องใช้เวลา หากการเปลี่ยนแปลงใช้เวลาหนึ่งสัปดาห์ในการดำเนินการ อย่าคาดหวังว่าการตรวจสอบโค้ดจะใช้เวลาน้อยกว่าหนึ่งวัน มันใช้งานไม่ได้อย่างนั้น อย่าพยายามเร่งตรวจสอบโค้ดหรือมองว่าเป็นคอขวด

การตรวจสอบโค้ดมีความสำคัญพอๆ กับการเขียนโค้ดจริง ในฐานะทีม อย่าลืม รวมการตรวจทานโค้ดไว้ในเวิร์กโฟลว์ของคุณ และตั้งความคาดหวังเกี่ยวกับระยะเวลาที่การตรวจทานโค้ดอาจใช้เวลานาน เพื่อให้ทุกคนซิงค์และมั่นใจเกี่ยวกับงานของพวกเขา

ประหยัดเวลาด้วยแนวทางและระบบอัตโนมัติ

วิธีที่มีประสิทธิภาพในการรับประกันการมีส่วนร่วมที่สอดคล้องกันคือการผสานรวมเทมเพลต Pull Request ในโครงการ ซึ่งจะช่วยให้ผู้เขียนส่งการประชาสัมพันธ์ที่ดีพร้อมคำอธิบายที่สมบูรณ์ คำอธิบายประชาสัมพันธ์ควรอธิบายว่าจุดประสงค์ของการเปลี่ยนแปลงคืออะไร เหตุผลเบื้องหลัง และวิธีทำซ้ำ ภาพหน้าจอและลิงก์อ้างอิง (ปัญหา Git ไฟล์การออกแบบ และอื่นๆ) เป็นขั้นตอนสุดท้ายสำหรับการส่งที่อธิบายตนเองได้

การทำเช่นนี้จะป้องกันไม่ให้ผู้ตรวจสอบขอรายละเอียดเพิ่มเติมก่อนแสดงความคิดเห็น อีกวิธีหนึ่งในการตรวจทานโค้ดดูไม่ค่อยพิถีพิถันคือการใช้ linters เพื่อค้นหาการจัดรูปแบบโค้ดและปัญหาด้านคุณภาพของโค้ดก่อนที่ผู้ตรวจสอบจะเข้ามาเกี่ยวข้อง เมื่อใดก็ตามที่คุณเห็นความคิดเห็นซ้ำๆ ในระหว่างกระบวนการตรวจสอบ ให้มองหาวิธีที่จะย่อให้เล็กสุด (โดยใช้แนวทางที่ดีกว่าหรือโค้ดอัตโนมัติ)

พักเป็นนักเรียน

ใครๆ ก็สามารถตรวจทานโค้ดได้ และทุกคนต้องได้รับการตรวจทานโค้ด ไม่ว่าระดับอาวุโสจะเป็นอย่างไร รับข้อเสนอแนะใด ๆ อย่างสุดซึ้งเพื่อเป็นโอกาสในการเรียนรู้และแบ่งปันความรู้ มองคำติชมใด ๆ เป็นการสนทนาแบบเปิด มากกว่าปฏิกิริยาการป้องกัน ตามที่ Ryan Holiday พูดว่า:

“มือสมัครเล่นคือตัวรับ มืออาชีพพบว่าการเรียนรู้ (และแม้กระทั่งการแสดงเป็นครั้งคราว) เป็นเรื่องสนุก พวกเขาชอบถูกท้าทายและถ่อมตน และมีส่วนร่วมในการศึกษาเป็นกระบวนการที่ต่อเนื่องและไม่รู้จบ (...)”

— Ryan Holiday, อัตตาคือศัตรู

จงถ่อมตัวเพราะวินาทีที่คุณเลิกเป็นนักเรียน ความรู้ของคุณจะเปราะบาง

ศิลปะแห่งการเลือกผู้วิจารณ์

ในความเห็นของฉัน การเลือกผู้ตรวจสอบเป็นหนึ่งในการตัดสินใจที่สำคัญที่สุดสำหรับการตรวจทานโค้ดที่มีประสิทธิภาพและเหมาะสมในฐานะทีม

สมมติว่าเพื่อนร่วมงานของคุณส่งการตรวจทานโค้ดและตัดสินใจที่จะแท็ก "ทุกคน" เพราะเธอ/เขาอาจต้องการเร่งกระบวนการโดยไม่ได้ตั้งใจ ส่งโค้ดที่ดีที่สุดเท่าที่จะเป็นไปได้ หรือทำให้แน่ใจว่าทุกคนทราบเกี่ยวกับการเปลี่ยนแปลงโค้ด ผู้ตรวจสอบแต่ละคนได้รับการแจ้งเตือน จากนั้นเปิดลิงก์ประชาสัมพันธ์และเห็นผู้คนจำนวนมากติดแท็กเป็นผู้ตรวจสอบ ความคิดที่ว่า "คนอื่นจะทำ" ผุดขึ้นในหัว ทำให้เพิกเฉยต่อการตรวจสอบโค้ดและปิดลิงก์

เนื่องจากยังไม่มีใครเริ่มรีวิว เพื่อนร่วมงานของคุณจะเตือนให้ผู้เขียนรีวิวแต่ละคนทำ เช่น สร้างความกดดันให้พวกเขา เมื่อผู้ตรวจสอบเริ่มดำเนินการ กระบวนการตรวจสอบจะใช้เวลาตลอดไป เนื่องจากทุกคนมีความคิดเห็นของตนเอง และเป็นฝันร้ายที่จะบรรลุข้อตกลงร่วมกัน ในขณะเดียวกัน ใครก็ตามที่ตัดสินใจไม่ตรวจสอบโค้ด จะถูกสแปมด้วยการแจ้งเตือนทางอีเมลนับล้านรายการพร้อมกับความคิดเห็นในการตรวจสอบทั้งหมด ซึ่งจะสร้างเสียงรบกวนในประสิทธิภาพการทำงานของพวกเขา

นี่คือสิ่งที่ฉันเห็นเกิดขึ้นมากกว่าที่ฉันต้องการ: ดึงคำขอที่มีกลุ่มคนที่แท็กเป็นผู้ตรวจสอบและปิดท้าย อย่างแดกดัน ในการตรวจสอบโค้ดที่ไม่ก่อให้เกิดประสิทธิผล

มีขั้นตอนที่มีประสิทธิภาพทั่วไปบางประการในการเลือกผู้ตรวจทาน: ขั้นตอนที่เป็นไปได้คือการเลือกเพื่อนร่วมงานสองถึงสามคนที่คุ้นเคยกับโค้ดและขอให้พวกเขาเป็นผู้ตรวจทาน อีกวิธีหนึ่งที่ทีม Gitlab อธิบายคือต้องมีกระบวนการตรวจสอบแบบผูกมัด โดยผู้เขียนจะเลือกผู้ตรวจสอบรายหนึ่งซึ่งเลือกผู้ตรวจสอบรายอื่น จนกว่าผู้ตรวจสอบอย่างน้อยสองคนจะเห็นด้วยกับโค้ด ไม่ว่าคุณจะเลือกขั้นตอนใด ให้ หลีกเลี่ยงการมีผู้ตรวจสอบมากเกินไป ความสามารถในการไว้วางใจการตัดสินใจของเพื่อนร่วมงานของคุณเป็นกุญแจสำคัญในการดำเนินการตรวจสอบรหัสที่มีประสิทธิภาพและมีสุขภาพดี

มีความเห็นอกเห็นใจ

การระบุโค้ดบางส่วนเพื่อปรับปรุงเป็นเพียงส่วนหนึ่งของการตรวจสอบโค้ดที่ประสบความสำเร็จ สิ่งที่สำคัญไม่แพ้กันก็คือการสื่อสารความคิดเห็นนั้นในทางที่ดีโดยแสดงความเห็นอกเห็นใจต่อเพื่อนร่วมงานของคุณ

ก่อนเขียนความคิดเห็น อย่าลืมใส่ตัวเองให้เข้ากับคนอื่น การเขียนเข้าใจผิดเป็นเรื่องง่าย ดังนั้นโปรดทบทวนคำพูดของคุณเองก่อนส่ง แม้ว่าบทสนทนาจะเริ่มไม่สวยงาม แต่อย่าปล่อยให้มันส่งผลกระทบต่อคุณ จงให้เกียรติเสมอ การพูดดีกับคนอื่นไม่เคยเป็นการตัดสินใจที่ไม่ดี

รู้วิธีประนีประนอม

เมื่อการสนทนาไม่ได้รับการแก้ไขอย่างรวดเร็ว ให้นำไปที่การโทรส่วนตัวหรือแชท วิเคราะห์ร่วมกันว่าเป็นเรื่องที่ควรค่าแก่การทำให้คำขอเปลี่ยนแปลงปัจจุบันเป็นอัมพาตหรือสามารถแก้ไขได้ในคำขออื่น

มีความยืดหยุ่นแต่ปฏิบัติได้จริง และรู้วิธีสร้างสมดุลระหว่างประสิทธิภาพ (การส่งมอบ) และประสิทธิผล (คุณภาพ) เป็นการประนีประนอมที่ต้องทำเป็นทีม ในช่วงเวลาเหล่านี้ ฉันชอบคิดว่าการตรวจสอบโค้ดเป็นการวนซ้ำมากกว่าที่จะเป็นวิธีแก้ปัญหาขั้นสุดท้าย มีช่องว่างสำหรับการปรับปรุงเสมอในรอบต่อไป

การตรวจทานรหัสบุคคล

การรวบรวมผู้เขียนและผู้วิจารณ์เข้าด้วยกันในรูปแบบการเขียนโปรแกรมคู่สามารถมีประสิทธิภาพสูง โดยส่วนตัวแล้ว ฉันชอบแนวทางนี้เมื่อการตรวจทานโค้ดเกี่ยวข้องกับการเปลี่ยนแปลงที่ซับซ้อนหรือมีโอกาสแบ่งปันความรู้เป็นจำนวนมาก แม้ว่าจะเป็นการตรวจสอบโค้ดออฟไลน์ก็ตาม คุณควรแสดงความคิดเห็นออนไลน์เกี่ยวกับการอภิปรายโดยเฉพาะอย่างยิ่งเมื่อจำเป็นต้องทำการเปลี่ยนแปลงหลังการประชุม สิ่งนี้ยังมีประโยชน์ในการทำให้ผู้ตรวจสอบออนไลน์คนอื่นๆ อัปเดตอยู่เสมอ

เรียนรู้จากผลการตรวจสอบโค้ด

เมื่อการตรวจสอบโค้ดได้รับการเปลี่ยนแปลงมากมาย ใช้เวลานานเกินไปหรือมีการอภิปรายมากเกินไป ให้รวบรวมทีมของคุณเข้าด้วยกันและวิเคราะห์สาเหตุและการดำเนินการที่สามารถดำเนินการได้ เมื่อการตรวจทานโค้ดมีความซับซ้อน การแบ่งงานในอนาคตออกเป็นงานย่อยๆ จะทำให้การตรวจทานแต่ละโค้ดง่ายขึ้น

เมื่อช่องว่างของประสบการณ์มีขนาดใหญ่ การใช้โปรแกรมคู่เป็นกลยุทธ์ที่ให้ผลลัพธ์ที่น่าทึ่ง ไม่เพียงแต่สำหรับการแบ่งปันความรู้เท่านั้น แต่ยังรวมถึงการทำงานร่วมกันและการสื่อสารแบบออฟไลน์ด้วย ไม่ว่าผลลัพธ์จะออกมาเป็นอย่างไร ตั้งเป้าให้ทีมมีพลวัตที่แข็งแรงพร้อมความคาดหวังที่ชัดเจนเสมอ

ในฐานะนักเขียน

ข้อกังวลหลักประการหนึ่งเมื่อทำงานในการตรวจสอบโค้ดในฐานะผู้เขียนคือการลดความประหลาดใจของผู้ตรวจทานเมื่ออ่านโค้ดเป็นครั้งแรก นั่นเป็นขั้นตอนแรกในการตรวจสอบโค้ดที่คาดเดาได้และราบรื่น นี่คือวิธีที่คุณสามารถทำได้

สร้างการสื่อสารในช่วงต้น

ไม่ควรพูดคุยกับผู้ตรวจสอบในอนาคตของคุณก่อนที่จะเขียนโค้ดมากเกินไป เมื่อใดก็ตามที่เป็นการสนับสนุนภายในหรือภายนอก คุณสามารถทำการปรับแต่งร่วมกันหรือเขียนโปรแกรมคู่เล็กน้อยในช่วงเริ่มต้นของการพัฒนาเพื่อหารือเกี่ยวกับโซลูชัน

การขอความช่วยเหลือเป็นขั้นตอนแรกไม่ผิด อันที่จริง การทำงานร่วมกันนอกการตรวจสอบเป็นขั้นตอนสำคัญขั้นแรกในการป้องกันข้อผิดพลาดแต่เนิ่นๆ และรับประกันข้อตกลงเบื้องต้น ในขณะเดียวกัน ผู้ตรวจสอบของคุณจะได้รับการตรวจสอบโค้ดในอนาคตที่ต้องทำ

ปฏิบัติตามแนวทาง

เมื่อส่งคำขอดึงเพื่อรับการตรวจสอบ อย่าลืมเพิ่มคำอธิบายและปฏิบัติตามหลักเกณฑ์ วิธีนี้จะช่วยให้ผู้ตรวจสอบไม่ต้องเสียเวลาทำความเข้าใจบริบทของโค้ดใหม่ แม้ว่าผู้ตรวจทานของคุณจะทราบอยู่แล้วว่าเนื้อหาเกี่ยวกับอะไร คุณยังสามารถใช้โอกาสนี้เพื่อพัฒนาทักษะการเขียนและการสื่อสารของคุณ

เป็นผู้ตรวจสอบคนแรกของคุณ

การเห็นโค้ดของคุณเองในบริบทต่างๆ ช่วยให้คุณพบสิ่งที่คุณอาจพลาดในโปรแกรมแก้ไขโค้ด ตรวจสอบรหัสของรหัสของคุณเองก่อนที่จะถามเพื่อนร่วมงาน มีกรอบความคิดของผู้ตรวจทานและอ่านโค้ดทุกบรรทัดจริงๆ

โดยส่วนตัวแล้ว ฉันชอบใส่คำอธิบายประกอบการตรวจทานโค้ดของตัวเอง เพื่อแนะนำผู้ตรวจทานของฉันให้ดีขึ้น เป้าหมายที่นี่คือการป้องกันความคิดเห็นที่เกี่ยวข้องกับการขาดความสนใจที่เป็นไปได้ และทำให้แน่ใจว่าคุณปฏิบัติตามแนวทางการสนับสนุน ตั้งเป้าที่จะส่งการตรวจสอบรหัสเช่นเดียวกับที่คุณต้องการรับ

อดทนไว้

หลังจากส่งการตรวจสอบโค้ดแล้ว อย่าข้ามไปยังข้อความส่วนตัวใหม่ที่ขอให้ผู้เขียนรีวิวของคุณ "ลองดูสิ ใช้เวลาเพียงไม่กี่นาที" และต้องการโดยอ้อมสำหรับอีโมจิที่ยกนิ้วให้ การพยายามเร่งให้เพื่อนร่วมงานทำงานไม่ใช่ความคิดที่ดี ให้ เชื่อถือเวิร์กโฟลว์ของเพื่อนร่วมงาน แทน เนื่องจากพวกเขาไว้ใจให้คุณส่งการตรวจทานโค้ดที่ดี ในระหว่างนี้ รอให้พวกเขาติดต่อกลับเมื่อพร้อมให้บริการ อย่ามองว่าผู้วิจารณ์ของคุณเป็นคอขวด อย่าลืมอดทนเพราะเรื่องยากต้องใช้เวลา

เป็นผู้ฟัง

เมื่อส่งการตรวจสอบโค้ดแล้ว ความคิดเห็นจะปรากฏขึ้น คำถามจะถูกถาม และจะมีการเสนอการเปลี่ยนแปลง กฎทองในที่นี้คือการไม่รับคำติชมใดๆ ว่าเป็นการโจมตีส่วนบุคคล จำไว้ว่า โค้ดใดๆ ก็ตามสามารถได้รับประโยชน์จากมุมมองภายนอก

อย่ามองว่าผู้วิจารณ์ของคุณเป็นศัตรู ให้ใช้เวลานี้เพื่อละทิ้งอัตตาของคุณ ยอมรับว่าคุณทำผิดพลาด และเปิดรับการเรียนรู้จากเพื่อนร่วมงาน เพื่อให้คุณทำงานได้ดีขึ้นในครั้งต่อไป

เป็นนักวิจารณ์

วางแผนล่วงหน้า

เมื่อคุณถูกขอให้เป็นผู้ตรวจทาน อย่าขัดจังหวะสิ่งต่างๆ ในทันที นั่นเป็นข้อผิดพลาดทั่วไปที่ฉันเห็นตลอดเวลา การตรวจสอบโค้ดต้องการความสนใจอย่างเต็มที่ และทุกครั้งที่คุณเปลี่ยนบริบทของโค้ด คุณกำลังลดประสิทธิภาพการทำงานโดยเสียเวลาในการปรับโฟกัสใหม่ ให้วางแผนล่วงหน้าโดยจัดสรรช่วงเวลาในแต่ละวันของคุณเพื่อตรวจทานโค้ด

โดยส่วนตัวแล้ว ฉันชอบที่จะทำการตรวจสอบโค้ดเป็นอย่างแรกในตอนเช้าหรือหลังอาหารกลางวันก่อนที่จะเลือกงานอื่นๆ ของฉัน นั่นคือสิ่งที่ใช้ได้ผลดีที่สุดสำหรับฉันเพราะสมองของฉันยังใหม่อยู่โดยไม่ต้องปิดบริบทของโค้ดก่อนหน้า นอกจากนั้น เมื่อตรวจทานเสร็จแล้ว ฉันสามารถมุ่งความสนใจไปที่งานของตัวเอง ในขณะที่ผู้เขียนสามารถประเมินโค้ดอีกครั้งโดยอิงจากคำติชม

คอยเป็นกำลังใจ

เมื่อคำขอดึงไม่ปฏิบัติตามหลักเกณฑ์การสนับสนุน ให้ให้การสนับสนุน โดยเฉพาะกับผู้มาใหม่ ใช้ช่วงเวลานั้นเป็นโอกาสในการแนะนำผู้เขียนเพื่อปรับปรุงผลงานของเขา/เธอ ในขณะเดียวกันให้พยายามทำความเข้าใจว่าทำไมผู้เขียนไม่ปฏิบัติตามหลักเกณฑ์ตั้งแต่แรก อาจมีช่องว่างสำหรับการปรับปรุง ที่คุณไม่เคยรู้มาก่อน

ตรวจสอบสาขาและเรียกใช้

ขณะตรวจสอบโค้ด ให้เรียกใช้บนคอมพิวเตอร์ของคุณ โดยเฉพาะอย่างยิ่งเมื่อเกี่ยวข้องกับอินเทอร์เฟซผู้ใช้ นิสัยนี้จะช่วยให้คุณเข้าใจโค้ดใหม่ได้ดีขึ้นและมองเห็นสิ่งที่คุณอาจพลาดหากคุณเพิ่งใช้เครื่องมือต่างเริ่มต้นในเบราว์เซอร์ซึ่งจำกัดขอบเขตการตรวจสอบของคุณไว้ที่โค้ดที่เปลี่ยนแปลง (โดยไม่ต้องมีบริบททั้งหมดเหมือนในโปรแกรมแก้ไขโค้ดของคุณ) .

ถามก่อนสันนิษฐาน

เมื่อคุณไม่เข้าใจบางสิ่ง อย่ากลัวที่จะพูดและถามคำถาม เมื่อถาม อย่าลืมอ่านรหัสโดยรอบก่อนและหลีกเลี่ยงการตั้งสมมติฐาน

คำถามส่วนใหญ่อยู่ในสองประเภทนี้:

1. คำถาม “อย่างไร”
   เมื่อคุณไม่เข้าใจว่าบางสิ่งทำงานอย่างไรหรือทำอะไร ให้ประเมินกับผู้เขียนว่าโค้ดมีความชัดเจนเพียงพอหรือไม่ อย่าเข้าใจผิดรหัสง่าย ๆ ด้วยความไม่รู้ มีความแตกต่างระหว่างรหัสที่อ่านยากและรหัสที่คุณไม่ทราบ เปิดใจเรียนรู้และใช้คุณลักษณะภาษาใหม่ แม้ว่าคุณจะยังไม่รู้อย่างลึกซึ้งก็ตาม อย่างไรก็ตาม ใช้เฉพาะในกรณีที่ codebase ง่ายขึ้นเท่านั้น
2. “ทำไม” คำถาม
   เมื่อคุณไม่เข้าใจ "สาเหตุ" อย่ากลัวที่จะแนะนำให้แสดงความคิดเห็นโค้ด โดยเฉพาะอย่างยิ่งหากเป็นกรณีขอบหรือการแก้ไขข้อบกพร่อง โค้ดควรอธิบายได้ด้วยตนเองเมื่อต้องการอธิบายว่าโค้ดนี้ใช้ทำอะไร ความคิดเห็นเป็นส่วนเสริมในการอธิบายสาเหตุที่อยู่เบื้องหลังแนวทางบางอย่าง การอธิบายบริบทนั้นมีค่ามากเมื่อพูดถึงเรื่องการบำรุงรักษา และมันจะช่วยให้ใครบางคนไม่ต้องลบบล็อกของโค้ดที่คิดว่าไม่มีประโยชน์ (โดยส่วนตัว ฉันชอบแสดงความคิดเห็นเกี่ยวกับโค้ดนี้ จนกว่าฉันจะรู้สึกปลอดภัยที่จะลืมมันในภายหลัง)

วิจารณ์เชิงสร้างสรรค์

เมื่อคุณพบโค้ดบางส่วนที่คุณเชื่อว่าควรได้รับการปรับปรุง อย่าลืมจดจำความพยายามของผู้เขียนในการมีส่วนร่วมในโครงการและแสดงออกในรูปแบบที่เปิดกว้างและโปร่งใส

• เปิดอภิปราย.
  หลีกเลี่ยงการทำให้คำติชมของคุณเป็นทางการเป็นคำสั่งหรือข้อกล่าวหา เช่น “คุณควร…” หรือ “คุณลืม…” แสดงความคิดเห็นของคุณในรูปแบบการสนทนาแบบเปิด แทนที่จะเป็นคำขอที่บังคับ อย่าลืมแสดงความคิดเห็นเกี่ยวกับโค้ด ไม่ใช่ผู้เขียน หากความคิดเห็นไม่เกี่ยวกับโค้ด ก็ไม่ควรอยู่ในการตรวจสอบโค้ด อย่างที่เคยบอกไว้เป็นกำลังใจ การใช้เสียงโต้ตอบ การพูดเป็นพหูพจน์ การแสดงคำถามหรือข้อเสนอแนะเป็นวิธีที่ดีในการเน้นย้ำความเห็นอกเห็นใจผู้แต่ง
  

แทนที่จะ “ดึงวิธีนี้ออกจากที่นี่…” ให้เลือก “วิธีนี้ควรถูกดึงออกมา…” หรือ “คุณคิดอย่างไรในการแยกวิธีนี้…”

• ชัดเจน.
  คำติชมสามารถตีความผิดได้ง่าย โดยเฉพาะอย่างยิ่งเมื่อพูดถึงการแสดงความคิดเห็นกับการแบ่งปันข้อเท็จจริงหรือแนวทางปฏิบัติ อย่าลืมล้างความคิดเห็นของคุณทันที

ไม่ชัดเจน: “รหัสนี้ควรเป็น….”

ความคิดเห็น: “ฉันเชื่อว่ารหัสนี้ควรเป็น…”

ข้อเท็จจริง: “ตาม [แนวทางของเรา] รหัสนี้ควรเป็น…”

• อธิบายว่าทำไม.
  สิ่งที่ชัดเจนสำหรับคุณ อาจไม่ใช่สำหรับคนอื่น ไม่เคยอธิบายแรงจูงใจเบื้องหลังความคิดเห็นของคุณมากนัก ดังนั้นผู้เขียนจึงไม่เพียงแต่เข้าใจวิธีเปลี่ยนแปลงบางอย่างเท่านั้น แต่ยังเข้าใจถึงประโยชน์ของความคิดเห็นด้วย

ความคิดเห็น: “ฉันเชื่อว่ารหัสนี้อาจเป็น…”

อธิบาย: “ฉันเชื่อว่ารหัสนี้อาจเป็น (…) เพราะสิ่งนี้จะปรับปรุงความสามารถในการอ่านและทำให้การทดสอบหน่วยง่ายขึ้น”

• ให้ตัวอย่าง
  เมื่อแบ่งปันคุณลักษณะโค้ดหรือรูปแบบที่ผู้เขียนไม่คุ้นเคย ให้เสริมข้อเสนอแนะของคุณด้วยข้อมูลอ้างอิงเป็นแนวทาง เมื่อเป็นไปได้ ให้ไปไกลกว่าเอกสาร MDN และแบ่งปันข้อมูลโค้ดหรือตัวอย่างการทำงานที่ปรับให้เข้ากับสถานการณ์โค้ดปัจจุบัน เมื่อเขียนตัวอย่างซับซ้อนเกินไป ให้สนับสนุน และเสนอให้ความช่วยเหลือด้วยตนเองหรือโดยแฮงเอาท์วิดีโอ

นอกจากจะพูดบางอย่างเช่น “การใช้ตัวกรองจะช่วยให้เรา [แรงจูงใจ]” ให้พูดว่า “ในกรณีนี้ อาจมีลักษณะดังนี้: [ตัวอย่างโค้ด] คุณสามารถตรวจสอบ [ตัวอย่างได้ที่ Finder.js] ข้อสงสัยใด ๆ อย่าลังเลที่จะ ping ฉันใน Slack”

• มีเหตุผล
  หากข้อผิดพลาดเดียวกันเกิดขึ้นหลายครั้ง ให้แสดงความคิดเห็นเพียงความคิดเห็นเดียวเกี่ยวกับข้อผิดพลาดนั้น และจำไว้ว่าผู้เขียนต้องเขียนรีวิวในที่อื่นๆ ด้วย การเพิ่มความคิดเห็นที่ซ้ำซ้อนจะทำให้เกิดเสียงรบกวนและอาจส่งผลตรงกันข้าม

รักษาโฟกัส

หลีกเลี่ยงการเสนอการเปลี่ยนแปลงรหัสที่ไม่เกี่ยวข้องกับรหัสปัจจุบัน ก่อนเสนอแนะการเปลี่ยนแปลง ให้ถามตัวเองว่าจำเป็นอย่างยิ่งในขณะนั้นหรือไม่ คำติชมประเภทนี้พบได้บ่อยในรีแฟคเตอร์ เป็นหนึ่งในข้อแลกเปลี่ยนระหว่างประสิทธิภาพและประสิทธิผลที่เราต้องทำเป็นทีม

เมื่อพูดถึงการปรับโครงสร้างใหม่ โดยส่วนตัวแล้ว ฉันมักจะชอบ การปรับปรุงเล็กๆ น้อยๆ แต่มีประสิทธิภาพ สิ่งเหล่านี้ง่ายต่อการตรวจสอบและมีโอกาสน้อยที่จะมีความขัดแย้งของรหัสเมื่ออัปเดตสาขาด้วยสาขาเป้าหมาย

ตั้งความคาดหวัง

หากคุณปล่อยให้การตรวจสอบโค้ดเสร็จสิ้นไปครึ่งหนึ่ง แจ้งให้ผู้เขียนทราบเพื่อควบคุมเวลาที่คาดไว้ ในท้ายที่สุด โปรดแจ้งให้ผู้เขียนทราบด้วยว่าคุณเห็นด้วยกับรหัสใหม่หรือหากคุณต้องการตรวจทานใหม่อีกครั้งในภายหลัง

ก่อนอนุมัติการตรวจทานโค้ด ให้ถามตัวเองว่าคุณสะดวกใจที่จะสัมผัสโค้ดนั้นในอนาคตหรือไม่ ถ้าใช่ แสดงว่าคุณตรวจสอบโค้ดสำเร็จแล้ว!

เรียนรู้ที่จะปฏิเสธการตรวจสอบรหัส

แม้ว่าจะไม่มีใครยอมรับ แต่บางครั้งคุณต้องปฏิเสธการตรวจสอบโค้ด ทันทีที่คุณตัดสินใจยอมรับการตรวจสอบโค้ดแต่พยายามเร่งรัด คุณภาพของโครงการกำลังถูกลดทอนลง เช่นเดียวกับความคิดของทีมของคุณ

เมื่อคุณยอมรับที่จะตรวจทานโค้ดของคนอื่น แสดงว่าบุคคลนั้นเชื่อมั่นในความสามารถของคุณ นั่นคือความมุ่งมั่น หากคุณไม่มีเวลาเป็นนักวิจารณ์ แค่ปฏิเสธเพื่อนร่วมงานของคุณ ฉันหมายความตามนั้นจริงๆ อย่าปล่อยให้เพื่อนร่วมงานของคุณรอการตรวจสอบโค้ดที่ไม่มีวันเสร็จสิ้น อย่าลืมสื่อสารและคาดหวังให้ชัดเจน ซื่อสัตย์กับทีมของคุณและ — ดียิ่งขึ้น — กับตัวคุณเอง ไม่ว่าคุณจะเลือกอะไรก็ตาม จงทำมันให้ถูกสุขภาพ และทำมันให้ถูกต้อง

บทสรุป

หากมีเวลาและประสบการณ์เพียงพอ การตรวจสอบโค้ดจะสอนคุณมากกว่าความรู้ด้านเทคนิค คุณจะได้เรียนรู้ที่จะให้และรับข้อเสนอแนะจากผู้อื่น รวมทั้งตัดสินใจด้วยความคิดที่มากขึ้น

การตรวจสอบโค้ดแต่ละครั้งเป็นโอกาสในการเติบโตในฐานะชุมชนและเป็นรายบุคคล แม้แต่การตรวจสอบโค้ดจากภายนอก อย่าลืมส่งเสริมความคิดที่ดีจนถึงวันที่เป็นเรื่องปกติสำหรับคุณและเพื่อนร่วมงาน เพราะการแบ่งปันคือสิ่งที่ทำให้เราดีขึ้น!

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

• การทำงานร่วมกัน: นักออกแบบและนักพัฒนาสามารถสื่อสารกันอย่างไรเพื่อสร้างโครงการที่ดีขึ้น
• การทำงานร่วมกันที่ดีขึ้นโดยนำนักออกแบบเข้าสู่กระบวนการตรวจสอบโค้ด
• พอดคาสต์ใดที่นักออกแบบเว็บไซต์และนักพัฒนาควรรับฟัง
• วิธีการประดิษฐ์ประวัติย่อสำหรับนักพัฒนาเว็บที่สมบูรณ์แบบ