วิธีการปฏิเสธการตรวจสอบรหัสที่คุณเชื่อว่าไม่จำเป็น?

89

ฉันอยู่ในตำแหน่งที่ฉันถูกขอให้ตรวจสอบรหัสบางอย่างที่แก้ไขปัญหาที่ฉันไม่เชื่อว่ามีอยู่

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

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

code-reviews

— เจมส์
แหล่งที่มา

113

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

— user16764

86

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

— Michael Shaw

15

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

8

C และ C ++ เต็มไปด้วยสิ่งที่ดูเหมือนจะใช้งานได้ แต่เป็นพฤติกรรมที่ไม่ได้กำหนดจริงๆ UB เป็นข้อบกพร่องจริงแม้ว่าคุณจะไม่สามารถเขียนการทดสอบที่แสดงว่ามันไม่ทำงานอย่างที่ควรจะเป็น ตัวอย่างเช่นคอมไพเลอร์จำนวนมากใช้ UB เป็นโอกาสในการปรับให้เหมาะสมโดยสมมติว่ากรณีที่ไม่ได้กำหนดไม่เคยเกิดขึ้น ตัวอย่างเช่นหากคุณใช้size > size+1เพื่อตรวจสอบโอเวอร์โฟลว์บนจำนวนเต็มที่ลงนามคอมไพเลอร์อาจแทนที่นิพจน์นี้ด้วยfalseเนื่องจากการโอเวอร์โฟลว์ของจำนวนเต็มที่ลงนามแล้วนั้นไม่ได้กำหนดไว้ ดูblog.llvm.org/2011/05/…

— CodesInChaos

5

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

— jwenting

274

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

หากเขาไม่สามารถสร้างขึ้นมาได้คุณใช้มันเป็นเหตุผล

ถ้าเขาสามารถสร้างได้คุณต้องอธิบายว่าทำไมการทดสอบนั้นไม่ถูกต้อง

— เครก
แหล่งที่มา

245

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

— แม็กเคเล็บ

99

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

— CodesInChaos

29

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

— Mike Weller

62

"ขอให้เขาพิสูจน์ว่าทำไมมันถึงจำเป็น ... "อาจขอให้เขาสอนคุณว่าทำไมมันถึงจำเป็น

— Mike Sherrill 'Cat Recall'

8

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

— MSalters

152

ผู้ตรวจสอบควรมีวัตถุประสงค์

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

พิจารณาแนวทางของทีม

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

การปฏิเสธเป็นส่วนหนึ่งของกระบวนการตรวจสอบรหัส

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

ความรับผิดชอบตัดทั้งสองวิธี

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

จดบันทึก.

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

— คาเลบ
แหล่งที่มา

24

+1 นี่เป็นวิธีที่มีประโยชน์มากกว่าคำตอบที่ยอมรับ

— Simon Bergot

2

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

— Florian Margaine

40

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

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

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

นอกจากนี้หากผู้ให้บริการเกี่ยวข้องกับเจ้าของโปรดอย่าลืมคำตอบนี้

— แดนพิเชลมาน
แหล่งที่มา

9

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

31

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

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

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

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

— อัศวินดำ
แหล่งที่มา

8

จุดดีเลิศ แต่ฉันไม่เข้าใจว่าตัวอย่างที่ด้านล่างสัมพันธ์กันอย่างไร (ฉันไม่ได้อ้างว่ามันไม่เกี่ยวข้องเลยนอกหลักสูตรเพียงชี้ให้เห็นว่าฉันไม่เข้าใจความสัมพันธ์)

— ugoren

8

@ugoren ฮ่า ๆ ฉันชอบสิ่งที่คุณทำที่นั่น!

— TheDarkKnight

1

@ugoren ความสัมพันธ์คือ 'ถ้าคุณไม่สามารถเห็นภาพรวมทั้งหมดได้โปรดอย่าแสดงความคิดเห็นที่เป็นรูปธรรม'

— RhysW

2

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

— PhilDin

2

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

— แอนดี้

9

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

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

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

รหัสปัญหาคือ:

int d[16];

int SATD (void)
{
   int satd = 0, dd, k;
   for (dd=d[k=0]; k<16; dd=d[++k]) {
     satd += (dd < 0 ? -dd : dd);
   }
   return satd;
 }

ในระหว่างการทำซ้ำครั้งล่าสุดd[++k] => d[++15] => d[16]มีการเข้าถึง เนื่องจากโดยปกติแล้วองค์ประกอบต่อไปคือหน่วยความจำที่ถูกกฎหมาย (ในแง่ของการเพจไม่ใช่โมเดลหน่วยความจำ C) แม้แต่คอมไพเลอร์เล็กน้อยก็ไม่ได้ผลิตไฟล์ใด ๆ ที่ปฏิบัติการได้ด้วยพฤติกรรมแปลก ๆ วิธีเดียวในการเขียนกรณีทดสอบคือการหาแพลตฟอร์มที่มีโมเดลหน่วยความจำเหมือนกับ C (อาจเป็น VM)

อย่างไรก็ตาม gcc 4.8 prerelase จะเห็นว่าd[++k]มีการดำเนินการในทุกลูป ดังนั้นk < 16มิฉะนั้นการเข้าถึงจะผิดกฎหมายและถูกต้องตามกฎหมายของโปรแกรมที่ส่งไปยังคอมไพเลอร์เป็นส่วนหนึ่งของสัญญา ดังนั้นเงื่อนไขลูปจึงเป็นจริงเสมอตามสมมติฐานที่กำหนดดังนั้นจึงเป็นลูปไม่สิ้นสุด นี่อาจฟังดูแปลก แต่มันก็เป็นการเพิ่มประสิทธิภาพทางกฎหมายอย่างสมบูรณ์ - การเปล่งsystem("dd if=/dev/zero of=/dev/sda"); system("format c:")ก็จะเป็นการแทนที่ที่ถูกต้องสำหรับลูป มีวิธีที่ลึกซึ้งยิ่งขึ้นที่คุณสามารถเลือกแสดงพฤติกรรมได้ ตัวอย่างเช่นระหว่างการบรรยายเกี่ยวกับTransactional Memoryฉันจำได้ว่าผู้นำเสนอพยายามหลายครั้งเพื่อให้ได้ค่าที่ผิดเมื่อ 2 เธรดเพิ่มค่าเดียวกัน

อย่างไรก็ตาม C / C ++ ตรงข้ามกับบางภาษามีมาตรฐานดังนั้นข้อพิพาทดังกล่าวสามารถทำได้โดยอ้างอิงแหล่งที่มาของวัตถุประสงค์:

หากคุณคิดว่านี่ไม่ใช่ปัญหาลองพิสูจน์โดยใช้มาตรฐาน C / C ++ (เช่นนำไปสู่คุณค่าและพฤติกรรมที่กำหนดไว้)
หากเขาคิดว่านี่เป็นปัญหาขอให้เขาพิสูจน์โดยใช้มาตรฐาน C / C ++ (เช่นนำไปสู่ค่าหรือพฤติกรรมที่ไม่ได้กำหนด)

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

— Maciej Piechotka
แหล่งที่มา

4

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

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

— djechlin
แหล่งที่มา

1

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

— สตีเฟ่นซี

4

@StephenC ใช่และฉันยืนตามความเห็นว่า OP ควรให้ประโยชน์กับข้อสงสัยในกรณีนี้ หรืออย่างอื่นก็จะเป็นการทบทวนแบบเผชิญหน้า

— djechlin

3

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

แน่นอนว่าอาจมีความอ่อนไหวทางการเมืองภายในในเรื่องนี้ แต่นี่คือวิธีที่ฉันจะไป (อร่อย)

— SnakeDoc
แหล่งที่มา