วิธีการให้ข้อเสนอแนะหลังจากกระบวนการตรวจสอบรหัส

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

1. ฉันควรแก้ไขรหัสด้วยตัวเองหรือไม่?

2. ฉันควรให้ข้อเสนอแนะแก่พวกเขาเกี่ยวกับกระบวนการตรวจสอบและให้พวกเขาแก้ไขตามคำแนะนำของฉัน และถ้าเป็นเช่นนั้นฉันจะให้ข้อเสนอแนะนี้ได้อย่างไรฉันจะกรอกเอกสารเทมเพลตบางส่วนและส่งไปให้พวกเขาหรือมีซอฟต์แวร์บางอย่างที่จะช่วยให้ฉันทำเครื่องหมายสิ่งต่าง ๆ ที่มีปัญหาภายในไฟล์รหัสที่พวกเขาสามารถตรวจสอบได้ในภายหลัง (ฉันใช้ Visual Studio)

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

คำตอบสั้น ๆ

ฉันควรแก้ไขรหัสด้วยตัวเองหรือไม่?

เลขที่

ฉันควรให้ข้อเสนอแนะแก่พวกเขาเกี่ยวกับกระบวนการตรวจสอบและให้พวกเขาแก้ไขตามคำแนะนำของฉัน

ใช่. ตามที่คุณเสนอแนะไม่คำแนะนำ คำแนะนำฟังดูน่าเชื่อถือเกินไป

และถ้าเป็นเช่นนั้นฉันจะให้ข้อเสนอแนะนี้ได้อย่างไรฉันจะกรอกเอกสารเทมเพลตบางส่วนและส่งไปให้พวกเขาหรือมีซอฟต์แวร์บางอย่างที่จะช่วยให้ฉันทำเครื่องหมายสิ่งต่าง ๆ ที่มีปัญหาภายในไฟล์รหัสที่พวกเขาสามารถตรวจสอบได้ในภายหลัง (ฉันใช้ Visual Studio)

ใช้เครื่องมือเพื่อแสดงความคิดเห็น คุณสามารถใช้ Visual Studio

คำตอบยาว ๆ

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

เครื่องมือนี้ยังช่วยในกระบวนการกลับไปกลับมาพูดคุย ฯลฯ

กระบวนการมากหรือน้อยมีดังต่อไปนี้:

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

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

เลือกใช้ถ้อยคำไม่ดี

ฉันตรวจสอบรหัสของคุณและมีบางรายการที่คุณต้องเปลี่ยน

ฉันพูดแบบนี้แทน:

ทางเลือกที่ดีกว่าของถ้อยคำ

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

สิ่งนี้ทำให้ผู้เขียนคิดว่า:

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

การเลือกคำง่ายๆเหล่านี้ช่วยฉันได้อย่างมากมาย

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

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

คุณช่วยรีวิวโค้ดให้ฉันหน่อยได้ไหมเพราะฉันหามันไม่ได้

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

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

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

พวกเขารู้สึกมีพลังที่จะดูงานของฉันและพูดว่า: "ใช่การเปลี่ยนแปลงของคุณดีฉันปิดปัญหา"

ฉันไม่เคยแก้ไขรหัสด้วยตัวเองเพราะ:

1. ผู้เขียนจะไม่เรียนรู้จากสิ่งนั้น
2. มันเหมือนกับที่ฉันพูดว่า: "หลีกทางให้ฉันแสดงให้คุณเห็นว่ามันทำอย่างไรรหัสของฉันดีกว่าของคุณ"
3. ทำไมฉัน มันทำงานได้มากกว่าสำหรับฉัน

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

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

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

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

ถ้าฉันทำรีวิวฉันตรวจสอบให้แน่ใจว่าได้ติดตามหรือไม่มีใครจะตรวจสอบอย่างจริงจัง

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

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

ตอบคำถามที่มีหมายเลขของคุณ

1- ฉันควรแก้ไขรหัสด้วยตัวเองหรือไม่

ไม่โปรดดูเหตุผลที่ฉันระบุไว้ข้างต้น

2- ฉันควรให้ข้อเสนอแนะแก่พวกเขาเกี่ยวกับกระบวนการตรวจสอบและให้พวกเขาทำการแก้ไขตามคำแนะนำของฉัน

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

ฉันจะให้ข้อเสนอแนะนี้ฉันจะกรอกเอกสารแม่แบบบางอย่างและส่งไปยังพวกเขาหรือมีซอฟต์แวร์บางอย่างที่จะช่วยให้ฉันทำเครื่องหมายสิ่งที่มีปัญหาภายในไฟล์รหัสที่พวกเขาสามารถตรวจสอบได้ในภายหลัง? (ฉันใช้ Visual Studio)

อย่างที่ฉันพูดคุณสามารถใช้เครื่องมือที่ฉันใช้หรือเครื่องมืออื่น อย่าใช้อีเมลหรือเอกสารคำเพราะเอกสารสูญหายและยากต่อการติดตาม

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

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

ความคิดสุดท้าย

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

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

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

1. ให้นักพัฒนาแก้ไขรหัส สิ่งนี้จะช่วยให้พวกเขาเข้าใจความคิดเห็นของคุณได้ดีขึ้น (หรือรู้ว่าพวกเขาไม่เข้าใจและถามอย่างเต็มที่) และการทำงานเป็นวิธีการเรียนรู้ที่ดีกว่าการอ่านเพียงเกี่ยวกับเรื่องนี้
2. ซอฟต์แวร์สำหรับการตรวจสอบรหัสเป็นวิธีที่จะไป มีตัวเลือกมากมายทั้งโอเพนซอร์ซและกรรมสิทธิ์ ส่วนใหญ่ทำงานกับคอมไพล์ ทีมของฉันใช้ BitBucket (เดิมชื่อ Stash) นอกจากนี้ยังมี GitLab และ GitHub, Gerrit (ซึ่งโดยส่วนตัวแล้วฉันไม่ใช่แฟนของ) และอีกหลายคน แอพเหล่านี้ส่วนใหญ่ใช้เว็บดังนั้นจึงไม่สำคัญว่าคุณจะใช้ IDE อะไร แต่ก็มีปลั๊กอินสำหรับ IDE หลายตัวด้วยดังนั้นฉันจึงมั่นใจว่ามีบางอย่างสำหรับ Visual Studio ด้วย ซอฟต์แวร์เช่นนี้ช่วยให้คุณสามารถตรวจสอบรหัสก่อนที่จะถูกรวมเข้ากับสาขาหลัก (โดยทั่วไปผ่านคำขอการดึง) และจะแสดงชิ้นส่วนที่แก้ไขและบรรทัดบริบทบางรอบการเปลี่ยนแปลงแต่ละครั้ง ทำให้การตรวจสอบรหัสทำได้อย่างคล่องแคล่วและไม่ยุ่งยาก

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

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

ฉันลงคะแนนให้ตัวเลือกที่สอง จูเนียร์อาจมี "เส้นโค้งที่ดีขึ้น" เมื่อทำการเปลี่ยนแปลงด้วยตนเอง

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