คำถามติดแท็ก code-reviews

แท็กนี้มีไว้สำหรับคำถามเกี่ยวกับการฝึกฝนการตรวจสอบโค้ดและการแนะนำโค้ด สำหรับความคิดเห็นเกี่ยวกับโค้ดที่ใช้งานได้โปรดดูที่ http://codereview.stackexchange.com

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

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

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

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

3
กลยุทธ์สำหรับการตรวจสอบโค้ดก่อนที่จะรวมไปถึงต้นแบบจากสาขาคุณลักษณะ
ฉันและทีมของฉันใช้สาขาคุณลักษณะ (พร้อมคอมไพล์) ฉันสงสัยว่าเป็นกลยุทธ์ที่ดีที่สุดในการตรวจสอบโค้ดก่อนที่จะรวมกันเป็นหลัก ฉันเช็คเอ้าท์สาขาใหม่จากหลักให้เรียกมันว่า fb_ # 1 ฉันส่งไปสองสามครั้งและต้องการรวมกลับเป็นหลัก ก่อนที่ฉันจะรวมใครบางคนควรทำการตรวจทานโค้ด ตอนนี้มีความเป็นไปได้ 2 แบบ: 1 ฉันรวมต้นแบบเข้ากับ fb_ # 1 ( ไม่ใช่ fb_ # 1 เป็นหลัก) เพื่อทำให้ทันสมัยที่สุด เพื่อนร่วมทีมจะตรวจทานการเปลี่ยนแปลงระหว่างหัวหน้าหลักและหัวหน้า fb_ # 1 หาก fb_ # 1 ไม่เป็นไรเราจะรวม fb_ # 1 เป็นหลัก ข้อดี: ไม่มีรหัสที่ล้าสมัยในการตรวจสอบ ข้อด้อย: ถ้ามีคนอื่นรวมบางอย่างระหว่าง "1. " และ "2. " การเปลี่ยนแปลงของเขาจะปรากฏในการตรวจสอบแม้ว่าจะเป็นของการตรวจสอบอื่น ครั้งที่ 2 เพื่อนร่วมทีมตรวจสอบการเปลี่ยนแปลงระหว่างจุดชำระเงิน …

3
เหมือนคำขอ Github "ดึงคำขอ" โดยไม่มี GitHub
ฉันทำงานเป็นนักวิเคราะห์สำหรับสถาบันการเงินซึ่งเนื่องจากความไวของข้อมูลจะไม่เก็บข้อมูลใด ๆ ในระบบคลาวด์ อย่างไรก็ตามฉันประสบความสำเร็จในการทำให้ทีมของฉันใช้ Git สำหรับการจัดการรหัส ฉันสงสัยว่ามีวิธีใดที่จะใช้คำขอดึงเหมือน Github ในเซิร์ฟเวอร์ของเราเองหรือไม่ คุณลักษณะเฉพาะที่ฉันสนใจคือความสามารถในการส่งเซ็ตการแก้ไขสำหรับความคิดเห็นโดยไม่รวมเข้ากับสาขาที่กำหนด ฉันชอบเวิร์กโฟลว์ของ (1) ส่งการเปลี่ยนแปลง (2) มีการเปลี่ยนแปลงตรวจสอบและแสดงความคิดเห็นและ (3) ยอมรับการกระทำหรือปฏิเสธ สามารถใช้งานได้หรือไม่ (ดียิ่งขึ้นสามารถนำไปใช้งานได้ง่าย ) บนเซิร์ฟเวอร์ของเราเอง?
21 git  code-reviews 

17
วิธีชักชวนโปรแกรมเมอร์ให้ปฏิบัติตามกฎพื้นฐาน
คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่ผ่านมา มีกฎหลายข้อที่ฉันต้องขอให้โปรแกรมเมอร์ทำตามบ่อย ๆ พวกเขาเขียนโค้ดและถ้ามันใช้งานได้งานก็จะเสร็จแล้วสำหรับพวกเขา กฎพื้นฐานส่วนใหญ่อาจเป็น: กำลังคอมมิตการเปลี่ยนแปลง ไม่ได้เขียนปัญหาเกี่ยวกับตัวแบบใน View or Controllers หลีกเลี่ยงการเข้ารหัส คุณช่วยเล่าประสบการณ์ของคุณให้ฉันฟังได้ไหม คุณจัดการสิ่งนี้ได้อย่างไร

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

4
ฉันจะแก้ไขโค้ดจากโปรแกรมเมอร์ที่มีประสบการณ์น้อยกว่าได้อย่างไร?
พื้นหลังเล็กน้อย:ฉันเป็นหนึ่งในสองโปรแกรมเมอร์ของแผนก 10 คนของเรา (ที่เหลือเป็นศิลปินและผู้บริหาร) เราสองคนทำการเข้ารหัสที่จำเป็นเพื่อให้ทุกอย่างราบรื่นและพัฒนาโครงการใด ๆ ที่เกิดขึ้น ฉันเขียนโปรแกรมมาประมาณ 4 ปีแล้วซึ่งนี่เป็นงานแรกของเขา "จริง" (ตามที่เขาวางไว้) โดยทั่วไปเรากำลังทำงานในโครงการต่าง ๆ ในเวลาใดก็ได้ สองสามเดือนที่ผ่านมาฉันได้พัฒนาชุดชั้นเรียน (ไม่สมบูรณ์) ที่จะใช้สำหรับโครงการในภายหลัง ส่วนใหญ่ของโครงการนั้นได้มอบหมายให้เขา (สำหรับเหตุผลด้านการเรียกเก็บเงิน) เพื่อออกแบบและตั้งโปรแกรมอินเทอร์เฟซ GUI ตั้งแต่เขายังใหม่ฉันเลยช่วยออกแบบและบอกว่าจะขอความช่วยเหลือถ้าเขาต้องการมันด้วยส่วนที่เหลือ เขาสร้างอินเทอร์เฟซให้เสร็จเมื่อไม่กี่สัปดาห์ที่ผ่านมาซึ่งเขาสาธิตให้แสดงว่ามันใช้งานได้แม้ว่าจะช้าไปนิด ส่วนต่อไปของโครงการได้เริ่มต้นแล้วซึ่งฉันกำลังดำเนินการอยู่ ฉันเปิดอินเทอร์เฟซเพื่อเริ่มต้นด้วยขั้นตอนถัดไปและพบปัญหาในทันที (ช้าเล็กน้อยคือการพูดน้อยข้อผิดพลาดในการกระทำทั่วไป ฯลฯ ) ฉันค้นหาโค้ดเพื่อดูปัญหาบางอย่างและกำลังค้นหาการO(n^n)โทรที่ควรO(n)พิมพ์สมมติฐานโดยไม่มีการตรวจสอบข้อผิดพลาด (เป็น Python) การอ้างอิงไปยัง GUI ที่เพิ่มเข้ากับรหัสดั้งเดิมและอื่น ๆ ตอนนี้ฉันอยากจะสอนเขาว่ามีอะไรผิดปกติและจะแก้ไขได้อย่างไร แต่เขาได้ย้ายไปยังโครงการต่อไปของเขาแล้วและเมื่อไม่กี่สัปดาห์ที่ผ่านมา ฉันเกรงว่าฉันพูดว่า "กลับไปทำในสิ่งที่ถูกต้อง!" (ด้วยความช่วยเหลือของหลักสูตร) ​​รุนแรงเกินไปและเรายังมีโครงการอื่น ๆ ให้ทำในระหว่างนี้ ตอนนี้ฉันควรจะแก้ไขโค้ดด้วยตัวเองแล้วและพยายามจับสิ่งต่าง ๆ ในอนาคตหรือไม่?
19 code-reviews  bug 

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

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

12
เราควรพยายามตรวจสอบรหัสของเราทั้งหมดหรือไม่
ขณะนี้เรากำลังปรับเปลี่ยนกระบวนการพัฒนาและฉันสงสัยว่าเราควรพยายามรักษาความมุ่งมั่นที่เราตรวจสอบไว้ 100% ประสบการณ์ของคุณเกี่ยวกับการตรวจสอบรหัสคืออะไร คุณมักจะใช้เวลา "มาก" กับพวกเขา (พูด 1/2 ชั่วโมงต่อวัน) หรือแค่อ่านเกิน 5/10 นาทีสูงสุดหรือไม่? คุณมีเวลาที่แน่นอนในการใช้จ่ายต่อวัน / สัปดาห์ / การวิ่ง / โครงการหรือไม่? ที่สำคัญที่สุดคุณคิดว่าเป้าหมายควรเป็น 100% ของรหัสที่จะตรวจสอบโดยเพื่อนหรือไม่จำเป็น 100%

2
กระบวนการที่แนะนำสำหรับการตรวจสอบโค้ดด้วย Mercurial
โดยทั่วไปเราใช้ Perforce และ SmartBear's Code Collaborator ที่Big Corpและตอนนี้เรากำลังจะใช้ Mercurial สำหรับบางโครงการ การทำงานร่วมกันของรหัสสนับสนุน Mercurial (เรากำลังใช้รุ่น 5) และฉันกำลังพยายามที่จะกำหนดเวลาที่ดีที่สุด (ในระหว่างกระบวนการส่ง / ส่งเซิร์ฟเวอร์) เป็นเวลาที่ดีที่สุด / มีประสิทธิภาพสำหรับการตรวจสอบรหัส ขอบคุณ

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.