การตอบรับเชิงบวกมีความสำคัญมากเพียงใดในการตรวจสอบโค้ด

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

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

ควรมีความสมดุลระหว่างความคิดเห็นเชิงบวกและเชิงลบหรือไม่?

การปรับปรุงคุณภาพและกำลังใจในการทำงานโดยใช้ความคิดเห็น Peer รหัส
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

สิ่งที่ทุกคนควรทำ: ตรวจสอบรหัส
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

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

ดังนั้นฉันว่ามันสำคัญมาก ใครอยากไปประชุมและถูกวิพากษ์วิจารณ์เท่านั้น

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

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

ฉันคิดว่าการถ่ายโอนความเข้าใจอย่างง่ายเป็นการสรรเสริญวิศวกรคนอื่นเพราะเราทุกคนต้องการให้คนอื่นเข้าใจรหัสของเรามันให้การตรวจสอบโดยนัย

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

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

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

"ฉันเห็นว่าคุณมีที่เก็บ DI ที่นี่แล้วคุณจะมีข้อต่อหลวมกับที่เก็บ"

"อามีพจนานุกรมแบบคงที่ที่นี่ถ้ามีหลายกระทู้กำลังสัมผัสพจนานุกรมนั้นเราอาจพบเจอกับสภาพการแข่งขันบางอย่าง"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

วลีที่ฉันเรียนรู้มากที่สุดจากหลายปีที่ผ่านมา:

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

เวิร์กโฟลว์ที่ฉันชอบมากที่สุดในการรีวิวโค้ดคือ:

1. Dev ส่งแพทช์ในรายการส่งเมล / เครื่องมือออนไลน์
2. ทุกคนที่ต้องการดูแลดูแพทช์แนะนำการปรับปรุง
3. Dev กลับไปที่ # 1
4. หากไม่ต้องการการปรับปรุงผู้คนจะพูดว่า "ทำงานได้ดี <- ข้อเสนอแนะในเชิงบวก รหัสทั้งหมดที่ได้รับการยอมรับเป็นสิ่งที่ดี คนน้อยต้องบอกให้คุณเปลี่ยนสิ่งต่าง ๆ ที่คุณกำลังทำดีกว่า
5. Dev กระทำ, ย้ายไปยังรายการถัดไป

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

ประโยชน์ของวิธีนี้คือ:

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

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

ฉันไม่สามารถนึกถึงเวลาที่ฉันเคยเห็นโค้ดในบทวิจารณ์ที่จะทำให้ฉันไป 'โอ้เยี่ยมมาก' ฉันสามารถสันนิษฐานได้ว่าถ้าฉันพบโค้ดเช่นนี้มันจะตกอยู่ในค่าย Cool-Yet-Unacceptable

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

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

ปล่อยแบ็กสแมปไปที่ผับ

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

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

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

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

หากคุณไม่ได้รับความคิดเห็นใด ๆ คุณสามารถพิจารณาได้ว่าคุณทำได้ดีมาก

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

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

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

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

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