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

แค่คิดออกมาดัง ๆ - พวกเราโปรแกรมเมอร์ชอบทุกอย่างในการลงคะแนน / ตรา / ตัวแทนสิ่งนี้ดังนั้นรูปแบบนี้จะถูกนำไปใช้ในกระบวนการตรวจสอบรหัส บริษัท เพื่อส่งเสริมการเข้ารหัสที่ดีขึ้น สิ่งที่ต้องการ คุณ (หรือคนอื่น ๆ ในนามของคุณ) สามารถโพสต์ความเห็น (อาจเป็นตัวอย่าง, การกระทำเดียวหรือหลายชุด) สำหรับการตรวจสอบโค้ด คนอื่นสามารถแสดงความคิดเห็นได้ (คล้ายกับคำตอบใน SE) สามารถให้ / แนะนำป้าย (บางคนอาจดีบางคนอาจไม่ดีเช่น "Comment Desert" หรือบางอย่าง) คุณสามารถลงคะแนนขึ้น / ลงบนตัวรหัสและความคิดเห็นและป้าย (เช่นถ้ามีคนแนะนำป้ายและคุณทำ / ไม่เห็นด้วย) เป้าหมายของโครงการเช่นนี้จะเป็น แนะนำความสนุกเล็กน้อยเพื่อกระตุ้นการใช้บทวิจารณ์โค้ด ปรับปรุงคุณภาพ (ในรูปแบบนี้ทั้งผู้ตรวจสอบโค้ดและผู้ตรวจทานมีแนวโน้มที่จะเรียนรู้) ลดโอกาสของการวิจารณ์รหัสที่เกิดประกายไฟ 'ego wars' ให้ตัวชี้วัดเพื่อช่วยวัดประสิทธิภาพการทำงานของแต่ละบุคคล ใช้งานได้ไหม คิด?

17 code-quality  code-reviews  motivation 

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

16 teamwork  code-reviews 

บริษัท ของฉันเพิ่งเริ่มทำการตรวจสอบโค้ดอย่างเป็นทางการ กระบวนการดังกล่าวเป็นเช่นนี้: คุณส่งไปยัง GitHub, ร้องขอการดึง, โค้ดจะได้รับการตรวจสอบโดยคนประมาณสามคนจากนั้นถ้าผ่านไปทั้งหมด, รหัสของคุณจะเข้า กระบวนการดูเหมือนยุติธรรม แต่คนสามคนที่ทำรีวิวโค้ดดูเหมือนจะไม่ยุติธรรม ฉันสังเกตเห็นว่าเมื่อฉันใส่รหัสของฉันในการตรวจสอบฉันได้ทุกที่ระหว่าง 100-200 ความคิดเห็น หมายเลขสูงสุดสำหรับฉันคือ 300 ความคิดเห็นครั้งเดียว แน่นอนว่าคุณคิดว่ามันเป็นการเปลี่ยนแปลงครั้งใหญ่ แต่นี่อาจเป็นการเปลี่ยนแปลงเล็กน้อยมากพร้อมกับรหัสน้อยกว่า 50 บรรทัด (ซึ่งรวมถึงการทดสอบหน่วย) ความคิดเห็นทั้งหมดได้รับการพิจารณาว่า "ต้องทำ" และไม่มีข้อโต้แย้ง โดยที่ในใจปัญหาหลักของฉันที่นี่คือดูเหมือนว่ามากเกินไป ฉันได้พูดคุยกับกลุ่มและพวกเขาบอกฉันโดยทั่วไปว่าเพียงเพราะฉันมีเวลาหลายปีในการพัฒนา php ไม่ได้หมายความว่าฉันเป็น "นักพัฒนา" ของหลักสูตรนี้ดูเหมือนจะเป็นอันตรายมากกว่าไม่ นอกจากนี้ฉันสังเกตเห็นว่าภายในกลุ่มพวกเขาไม่ได้แสดงความคิดเห็นมากนักและส่วนใหญ่พวกเขาเพิกเฉยหรือไม่สนใจข้อคิดเห็นหรือคำแนะนำอื่น ๆ ที่ไม่ค่อยยอมรับว่าเป็นจุดที่ถูกต้องแม้ว่าจะมีบางอย่างขาดหายไป ดังนั้นคำถามของฉันคือถ้านี้ยุติธรรม หรือเป็นเรื่องธรรมดา?

16 teamwork  code-reviews 

ปัจจัยพื้นฐาน ทีมใช้ DVCS IDE รองรับการแยกวิเคราะห์ความคิดเห็น (เช่นสิ่งที่ต้องทำและอื่น ๆ ) เครื่องมือเช่น CodeCollaborator มีราคาแพงสำหรับงบประมาณ เครื่องมือเช่น gerrit นั้นซับซ้อนเกินไปสำหรับการติดตั้งหรือไม่สามารถใช้งานได้ ขั้นตอนการทำงาน ผู้เขียนเผยแพร่บางแห่งในสาขาฟีเจอร์ repo กลาง ผู้ตรวจทานดึงข้อมูลและเริ่มตรวจสอบ ในกรณีที่ผู้ตรวจสอบคำถาม / ปัญหาสร้างความคิดเห็นด้วยป้ายกำกับพิเศษเช่น "REV" ป้ายกำกับดังกล่าวต้องไม่อยู่ในรหัสการผลิต - เฉพาะในขั้นตอนการตรวจสอบ: $somevar = 123; // REV Why do echo this here? echo $somevar; เมื่อผู้ตรวจทานโพสต์ความคิดเห็นเสร็จ - เพียงแค่คอมเม้นต์ด้วยข้อความ "ความคิดเห็น" ที่งี่เง่าและดันกลับมา ผู้เขียนดึงฟีเจอร์แบรนช์กลับมาและตอบความคิดเห็นในลักษณะเดียวกันหรือปรับปรุงโค้ดแล้วดันกลับ เมื่อความคิดเห็น "REV" หายไปเราสามารถคิดได้ว่าการตรวจทานเสร็จสิ้นแล้ว ผู้เขียนจะทำการย่อกิ่งก้านสาขาที่มีลักษณะโต้ตอบ, กำจัดมันเพื่อลบ "ความคิดเห็น" …

16 teamwork  code-reviews  workflows  dvcs 

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

16 learning  project-management  freelancing  code-reviews  billing 

หลาย ๆ ทีมที่ บริษัท ของฉันฝึกฝนเวิร์กโฟลว์การตรวจสอบโค้ดที่ฉันไม่เคยเห็นมาก่อน ฉันพยายามเข้าใจความคิดเบื้องหลังด้วยความคิดที่ว่ามีคุณค่าในการทำให้ บริษัท ทั้งหมดสอดคล้องกัน (ฉันมีส่วนร่วมกับรหัสฐานหลายและถูกเพิ่มขึ้นตามความแตกต่างในอดีต) ผู้เขียนโค้ดส่งคำขอการดึง ผู้ตรวจสอบตรวจสอบรหัส หากผู้ตรวจสอบอนุมัติพวกเขาจะแสดงความคิดเห็นตามบรรทัดของ "ดูดีรู้สึกอิสระที่จะผสาน" หากผู้ตรวจสอบมีข้อกังวลพวกเขาแสดงความคิดเห็นเช่น "โปรดแก้ไขปัญหาเล็กน้อย X และ Y จากนั้นรวม" (สำหรับการเปลี่ยนแปลงที่สำคัญกลับไปที่ขั้นตอนที่ 2) ผู้สร้างรหัสทำการเปลี่ยนแปลงหากจำเป็นจากนั้นรวมคำขอดึงของเขาหรือเธอเอง ฉันมีข้อกังวลดังต่อไปนี้: ในกรณีที่ได้รับการอนุมัติในขั้นตอนที่ 3 เวิร์กโฟลว์นี้จะสร้างการเดินทางไปกลับที่ไม่จำเป็นสำหรับผู้เขียนคำขอดึง ผู้ตรวจทานซึ่งกำลังดูรหัสอยู่แล้วสามารถรวมมันได้ทันที ในกรณีที่มีการร้องขอการเปลี่ยนแปลงในขั้นตอนที่ 3 หน่วยงานที่จะรวมคำขอดึงข้อมูลจะอยู่กับผู้แต่งของ PR เท่านั้น ไม่มีใครนอกจากผู้เขียนจะดูการเปลี่ยนแปลงก่อนที่จะรวม อะไรคือข้อดีหรือข้อเสียของเวิร์กโฟลว์นี้ เวิร์กโฟลว์นี้เป็นเรื่องปกติในทีมวิศวกรรมอื่น ๆ หรือไม่

16 code-reviews  pull-requests 

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

16 c#  asp.net  code-reviews 

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

15 agile  code-reviews  scrum 

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

15 unit-testing  code-reviews 

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

14 code-quality  code-reviews  clean-code  team-leader  process-improvement 

เพื่อหลีกเลี่ยงตัวเลขเวทย์มนตร์เรามักได้ยินว่าเราควรให้ชื่อที่มีความหมายตามตัวอักษร เช่น: //THIS CODE COMES FROM THE CLEAN CODE BOOK for (int j = 0; j < 34; j++) { s += (t[j] * 4) / 5; } -------------------- Change to -------------------- int realDaysPerIdealDay = 4; const int WORK_DAYS_PER_WEEK = 5; int sum = 0; for (int j = 0; …

14 coding-style  code-quality  clean-code  code-reviews 

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

14 project-management  agile  teamwork  code-reviews  sdlc 

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

14 agile  code-reviews  pair-programming  extreme-programming 

ฉันเป็นส่วนหนึ่งของทีมนักพัฒนาเจ็ดคนใน บริษัท ซอฟต์แวร์ขนาดเล็กและฉันพยายามแนะนำรหัสกลุ่มและบทวิจารณ์การออกแบบ เราได้ทำการวิจารณ์บางอย่างในอดีต แต่มันก็เป็นระยะ ๆ ฉันต้องการทำให้เป็นเรื่องปกติมากขึ้น ฉันได้อ่าน Code Complete และแหล่งข้อมูลอื่นที่คล้ายคลึงกันแล้วและพวกเขาพูดถึงกลไกของวิธีการตรวจสอบโค้ด แต่ฉันไม่สามารถหาแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับวิธีเลือกสิ่งที่ต้องการตรวจสอบได้ เรามีฐานรหัสที่มีอายุมากกว่าแปดปีและครอบคลุมภาษาที่หลากหลายดังนั้นจึงมีมากมายที่สามารถดูได้ นี่คือปัจจัยบางอย่างที่ฉันสามารถคิดได้ซึ่งอาจส่งผลกระทบต่อตัวเลือก: ภาษา: C, Java, SQL, PL / SQL อายุรหัส: รหัสใหม่กับรหัสเก่า การใช้รหัส: รหัสที่ใช้บ่อยเทียบกับรหัสที่ใช้งานได้ไม่เต็มประสิทธิภาพ ความสำคัญของรหัส: รหัสที่สำคัญกับรหัสที่ไม่สำคัญ ผู้พัฒนา: รหัสนักพัฒนาซอฟต์แวร์ระดับสูงและรหัสผู้พัฒนาอาวุโส ฉันเข้าใจว่านี่ไม่ใช่คำถามที่มีคำตอบที่ชัดเจน แต่คำแนะนำใด ๆ ที่มีประโยชน์ บางคำถามที่เกี่ยวข้องกับอุปกรณ์ต่อพ่วง: แนวทางการตรวจสอบรหัส (กล่าวถึงการตรวจสอบส่วนที่สำคัญและรหัสนักพัฒนาซอฟต์แวร์ใหม่) เราควรพยายามตรวจสอบรหัสของเราทั้งหมดหรือไม่

14 code-reviews 

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

14 scrum  code-reviews  quality