ในการตรวจสอบรหัสผู้ตรวจทานควรเสนอวิธีแก้ปัญหาหรือไม่ [ปิด]

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

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

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

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

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

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

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

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

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

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

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

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

ในความคิดเห็นของรหัสควรวิจารณ์มักจะนำเสนอวิธีการแก้ปัญหาสำหรับปัญหาหรือไม่?

ไม่ถ้าคุณทำอย่างนั้นคุณไม่ใช่ผู้ตรวจทานคุณเป็นผู้เขียนโค้ดคนต่อไป

ในการตรวจสอบรหัสผู้ตรวจทานควรไม่เคยเสนอวิธีแก้ไขปัญหาหรือไม่

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

ผู้ตรวจสอบควรเสนอวิธีแก้ไขปัญหาเมื่อใด

เมื่อใดจึงเป็นวิธีที่มีประสิทธิภาพที่สุดในการสื่อสาร เรารหัสลิงไม่ใช่วิชาเอกภาษาอังกฤษ บางครั้งวิธีที่ดีที่สุดในการแสดงให้เห็นว่า code sucks ... น้อยกว่าดีที่สุด ... คือการแสดงโค้ดที่ sucks น้อยกว่า ... ก็คือ ... opt มากกว่า ... โอ้คุณรู้ไหมว่าฉันหมายถึงอะไร

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

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

โปรแกรมเมอร์ที่ไม่ดีมีอยู่สองประเภท: ประเภทที่ไม่ปฏิบัติตามมาตรฐานการปฏิบัติและผู้ที่ "เท่านั้น" ปฏิบัติตามแนวทางปฏิบัติมาตรฐาน

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

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

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

ฉันรู้ว่านี่เป็นวิธีการแก้ปัญหามากกว่าวิธีการแก้ปัญหาที่ชัดเจน จะมีความแปรปรวนมากเกินไปที่จะครอบคลุมทุกสถานการณ์

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

ความคิดเห็นของฉันจะแข็งแกร่งขึ้นต่อการไม่ให้รหัสในกรณีส่วนใหญ่ด้วยเหตุผลหลายประการ:

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

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

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

ฉันคิดว่ากุญแจสำคัญในการตรวจสอบรหัสคือการเห็นด้วยกับกฎก่อนการตรวจสอบ

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

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

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

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

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

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

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

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

ตัวต่อตัวแบนด์วิดท์สูงกว่ามากและมีช่องสัญญาณด้านอารมณ์เพื่อป้องกันการเป็นปรปักษ์

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