วิธีการค้นหาสิ่งที่ดีในการตรวจสอบรหัส?


184

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

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

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

ในทางเทคนิคเราสามารถปฏิเสธการรวมทำให้มันกลับไปสู่การพัฒนา ในความเป็นจริงสิ่งนี้จะจบลงบ่อยครั้งที่หัวหน้าของเราเรียกร้องให้ส่งมอบตรงเวลา

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

ในปัจจุบันการพัฒนานั้นดำเนินการในสาขาการพัฒนาใน SVN หลังจากนักพัฒนาคิดว่าเขาพร้อมเขามอบหมายตั๋วในระบบตั๋วของเราให้กับผู้จัดการของเรา จากนั้นผู้จัดการมอบหมายให้เรา

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

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

ในทางกลับกันตอนนี้ฉันรู้แล้วว่าเป็นลาเพื่อชี้ให้เห็นปัญหาเกี่ยวกับรหัสที่ได้ตกลงไว้

ฉันไม่คิดว่ามาตรฐานของฉันสูงเกินไป

รายการตรวจสอบของฉันในขณะนี้คือ:

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

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

สิ่งที่ฉันขาดคือความสามารถในการค้นหาสิ่งที่ชี้ให้เห็นว่า "ดี" ฉันอ่านว่าควรพยายามทำข่าวร้ายในข่าวประเสริฐ

แต่ฉันมีเวลายากที่จะหาสิ่งที่ดี "เฮ้คราวนี้คุณทำทุกสิ่งที่คุณทำจริง ๆ " จะช่วยวางตัวดีกว่าหรือดีกว่า

ตัวอย่างรหัสตรวจสอบ

เฮ้โจ

ฉันมีคำถามบางอย่างเกี่ยวกับการเปลี่ยนแปลงของคุณใน Library \ ACME \ ExtractOrderMail Class

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

... (ประเด็นอื่น ๆ ที่ไม่สามารถใช้งานได้)

คะแนนรอง:

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

8
โปรดอย่าทำแซนวิชเป็นเงิน $ h! t เพื่อให้ได้มาซึ่งสมดุลที่ดีและไม่ดี หากพวกเขาทำสิ่งที่ดีให้บอกพวกเขาเช่นนั้นถ้าพวกเขาทำบางสิ่งที่ต้องการการแก้ไขให้พวกเขารู้ การผสมดีและไม่ดีเจือจางข้อความ หากพวกเขาได้รับข้อเสนอแนะเชิงลบมากกว่าเชิงบวกพวกเขาอาจจะรู้ว่าพวกเขาจำเป็นต้องเปลี่ยน วิธีแซนวิชของคุณให้อัตราส่วน 2: 1 สำหรับทุกค่าลบดังนั้นมันจึงเป็นค่าบวกสุทธินั่นคือข้อความที่คุณต้องการส่ง
cdk เลิก

14
หยุดใช้คนที่ 2 รหัสเป็นเรื่องไม่ใช่รหัส ยกตัวอย่างเช่นเขียน: SaveAndSend ควรจะเปลี่ยนชื่อเพื่อให้พอดีกับพฤติกรรมของมันเหมือนเช่น SendErrorMail ตอนนี้ดูเหมือนว่าคุณจะสั่งให้เพื่อนร่วมงานของคุณจริงๆแม้จะมี "คุณโปรด" ที่คุณทะลักไปหมด ฉันจะไม่ยอมรับสิ่งนี้จากผู้ตรวจสอบ ฉันต้องการคนที่เอาจริงเอาจังว่า "สิ่งนี้ต้องทำ" มากกว่าที่จะขอให้ฉันทำอะไรบางอย่าง
Arthur Havlicek

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

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

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

คำตอบ:


124

วิธีการค้นหาสิ่งที่ดีในการตรวจสอบรหัส?

หลังจากปัญหาคุณภาพที่ร้ายแรงในปีที่ผ่านมา บริษัท ของฉันเพิ่งเปิดตัวบทวิจารณ์โค้ด

เยี่ยมมากคุณมีโอกาสจริงในการสร้างมูลค่าให้กับ บริษัท ของคุณ

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

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

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

ในทางกลับกันตอนนี้ฉันรู้แล้วว่าเป็นลาเพื่อชี้ให้เห็นปัญหาเกี่ยวกับรหัสที่ได้ตกลงไว้

นั่นคือโชคร้ายที่คุณบอกว่าคุณมีไหวพริบ คุณสามารถหาคำสรรเสริญได้มากขึ้นถ้าคุณมีมากกว่าที่จะมองหา

วิจารณ์รหัสไม่ใช่ผู้เขียน

คุณยกตัวอย่าง:

ฉันมีคำถามบางอย่างเกี่ยวกับการเปลี่ยนแปลงของคุณ

หลีกเลี่ยงการใช้คำว่า "คุณ" และ "ของคุณ" พูด "เปลี่ยน" แทน

ฉันพลาดอะไรไปหรือเปล่า? [... ] ทำไมถึงเป็นอย่างนั้น?

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

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

ยกระดับโดยให้ข้อเสนอแนะในเชิงบวก

มันยกระดับการยกย่องนักพัฒนาเพื่อนของคุณเมื่อพวกเขาได้มาตรฐานที่สูงขึ้น นั่นหมายถึงคำถาม

วิธีการค้นหาสิ่งที่ดีในการตรวจสอบรหัส?

เป็นคนดีและควรพูดถึง

คุณสามารถชี้ให้เห็นว่าโค้ดตรงกับอุดมคติของการทำรหัสระดับสูง

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

แนวทางปฏิบัติที่ดีที่สุดเฉพาะภาษา

หากภาษานั้นรองรับเอกสารในโค้ดเนมสเปซการเขียนโปรแกรมเชิงวัตถุหรือฟังก์ชั่นการใช้งานคุณสามารถเรียกสิ่งเหล่านั้นออกมาและแสดงความยินดีกับผู้เขียนเกี่ยวกับการใช้ภาษาเหล่านั้นตามความเหมาะสม เรื่องเหล่านี้มักจะตกอยู่ภายใต้แนวทางแบบ:

  • มันเป็นไปตามมาตรฐานคู่มือสไตล์ภาษาในบ้านหรือไม่?
  • มันเป็นไปตามคู่มือสไตล์เผด็จการมากที่สุดสำหรับภาษา (ซึ่งอาจเข้มงวดกว่าในบ้าน - และดังนั้นจึงยังสอดคล้องกับรูปแบบในบ้าน)?

วิธีปฏิบัติที่ดีที่สุดทั่วไป

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

มองหา:

  • การทดสอบหน่วยที่ทดสอบเฉพาะฟังก์ชั่นเรื่อง - เยาะเย้ยฟังก์ชั่นราคาแพงที่ไม่ได้ตั้งใจจะทดสอบ
  • การครอบคลุมโค้ดในระดับสูงพร้อมการทดสอบ API ที่สมบูรณ์และฟังก์ชั่นการใช้ความหมายแบบสาธารณะ
  • การทดสอบการยอมรับและการทดสอบควันที่ทดสอบการใช้งานแบบ end-to-end รวมถึงฟังก์ชั่นที่จำลองการทดสอบหน่วย
  • การตั้งชื่อที่ดีจุดข้อมูลที่เป็นที่ยอมรับดังนั้นโค้ดคือ DRY (อย่าทำซ้ำตัวเอง) ไม่มีสตริงมายากลหรือตัวเลข
  • การตั้งชื่อตัวแปรทำได้ดีมากความคิดเห็นส่วนใหญ่ซ้ำซ้อน
  • การล้างข้อมูลการปรับปรุงวัตถุประสงค์ (โดยไม่มีการแลกเปลี่ยน) และการปรับโครงสร้างใหม่ที่เหมาะสมซึ่งจะลดบรรทัดของรหัสและหนี้ทางเทคนิคโดยไม่ทำให้โค้ดต่างประเทศสมบูรณ์สำหรับนักเขียนต้นฉบับ

ฟังก์ชั่นการเขียนโปรแกรม

หากภาษานั้นใช้งานได้หรือสนับสนุนกระบวนทัศน์การทำงานให้มองหาอุดมคติเหล่านี้:

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

การเขียนโปรแกรมเชิงวัตถุ (OOP)

หากภาษารองรับ OOP คุณสามารถชมการใช้งานคุณสมบัติเหล่านี้ได้อย่างเหมาะสม:

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

ภายใต้ OOP ยังมีหลักการที่เป็นของแข็ง (บางทีความซ้ำซ้อนของคุณสมบัติ OOP):

  • ความรับผิดชอบเดียว - แต่ละวัตถุมีหนึ่งผู้มีส่วนได้เสีย / เจ้าของ
  • open / closed - ไม่แก้ไขส่วนต่อประสานของวัตถุที่สร้างขึ้น
  • การทดแทน Liskov - คลาสย่อยสามารถทดแทนได้สำหรับอินสแตนซ์ของผู้ปกครอง
  • การแยกส่วนต่อประสาน - ส่วนต่อประสานที่จัดทำโดยองค์ประกอบอาจเป็นส่วนผสม
  • การผกผันของการพึ่งพา - การกำหนดอินเทอร์เฟซ - polymorphism ...

หลักการเขียนโปรแกรม Unix :

หลักการของ Unix นั้นเป็นแบบแยกส่วน, ความชัดเจน, องค์ประกอบ, การแยก, ความเรียบง่าย, parsimony, ความโปร่งใส, ความทนทาน, การเป็นตัวแทน, ความประหลาดใจน้อยที่สุด, ความเงียบ, การซ่อมแซม, เศรษฐกิจ, การสร้าง, การเพิ่มประสิทธิภาพความหลากหลาย

โดยทั่วไปหลักการเหล่านี้สามารถนำไปใช้ภายใต้กระบวนทัศน์จำนวนมาก

เกณฑ์ของคุณ

สิ่งเหล่านี้ไม่สำคัญเกินไป - ฉันจะรู้สึกถูกบีบบังคับหากได้รับการยกย่องในเรื่องนี้:

  • รหัสจะรวบรวม
  • มีอย่างน้อยหนึ่งวิธีที่รหัสจะทำงานได้
  • รหัสจะทำงานกับกรณีปกติส่วนใหญ่

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

  • รหัสจะทำงานกับกรณีขอบส่วนใหญ่
  • รหัสจะมีข้อยกเว้นที่สมเหตุสมผลหากข้อมูลที่ใส่ไม่ถูกต้อง

เขียนกฎสำหรับการตรวจสอบรหัสผ่านหรือไม่

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

กฎข้อเดียวที่ฉันคิดได้ในการปฏิเสธรหัสคือไม่มีอะไรที่น่าเกรงขามเลยที่ฉันจะไม่ใช้งานมัน ชื่อที่ไม่ดีจริง ๆ คือสิ่งที่ฉันยินดีที่จะหยุดการผลิต - แต่คุณไม่สามารถสร้างกฎนั้นได้

ข้อสรุป

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


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

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

4
@Aaron: เห็นด้วยกับคุณในแนวทาง คำตอบมากมายที่นี่บอกว่า "อย่าห่อหุ้มน้ำตาล" แต่ฉันเข้าใจว่ามันไม่เกี่ยวกับความพอใจของทุกคน ผู้คนมีแนวโน้มที่จะปฏิบัติตามแนวทางที่ดีเมื่อมีการเสริมความดี แต่ไม่ใช่เมื่อบอกว่าผิด พวกเขาสำคัญที่นี่คือจะมีไหวพริบ แต่สอดคล้องกับสิ่งที่ต้องทำ จากคำอธิบายของ OP เขาอยู่ในทีมการเขียนโค้ดที่ไม่สมบูรณ์แบบพร้อมกับสมาชิกเก่าที่คุ้นเคยกับการเดินทางของพวกเขา พวกเขาจะเปิดกว้างต่อการเข้าใกล้ที่อ่อนโยนยิ่งขึ้น
Hoàng Long

@ HoàngLongไม่ใช่ทุก 'ตัวจับเวลาเก่า' ที่จำเป็นต้องมี มีบางคนที่ไม่มีเหตุผลเสมอไป ตัวอย่างเช่นฉันเคยทำงานกับคนที่ยืนยันใน 'การย้าย' การปฏิบัติที่ดีที่สุดของ Perl ไปยัง Python และการโค่นล้มของ Git และมีการร้องเรียนบางครั้งทุกครั้งที่มีการเรียกใช้โดยไม่คำนึงว่ามันจะเป็นอย่างไร การอธิบายเหตุผล เนื่องจากในขณะนั้นความรับผิดชอบของฉันอยู่บนตักของฉัน (ฉันเป็นคนเดียวที่มีทั้ง Python และ Git) ฉันคิดว่าบางคนอาจรู้สึกว่าถูกคุกคาม (?) และตอบสนองตามนั้น ...
code_dredd

104

อย่าไปเลือกสิ่งที่ดีเว้นแต่เป็นตัวอย่างที่กระชับและเกี่ยวข้องโดยตรงกับปัญหาที่มุ่งเน้น

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

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

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

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

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

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


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

7
@ GregBurghardt เฮ้พวกเขาไม่เรียกมันว่าการเมืองในสำนักงาน
plast1k

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

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

2
"ตรวจสอบให้แน่ใจว่าคุณกำลังตำหนิรหัสไม่ใช่ผู้แต่ง". เห็นด้วย แต่คนที่ไม่ปลอดภัย / เด็กอ่อนจะไม่ทำแบบนั้น
MetalMikester

95

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

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

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

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

หากคุณไม่ชอบกฎให้จัดการประชุมเพื่อเปลี่ยนแปลง


56
"วิธีเดียวที่จะตรวจสอบให้แน่ใจว่าคุณหลีกเลี่ยงปัญหานี้คือการเขียนกฎสำหรับการส่งรหัสตรวจทาน" นี้. คุณควรตรวจสอบทุกอย่างกับมาตรฐานที่กำหนดไว้สำหรับโครงการโดยรวมไม่ใช่ความคิดส่วนตัวของคุณว่าอะไรดี แต่ความคิดส่วนบุคคลของคุณอาจจะลึกซึ้ง
alephzero

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

20
-1 ฉันชอบวิธีที่คุณข้ามไปจากการวิพากษ์ "nerd wars" แล้วพูดว่า "วิธีเดียวที่จะทำให้คุณหลีกเลี่ยงปัญหานี้ได้"
tymtam

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

15
มีประโยชน์มากกว่ามาตรฐานการเข้ารหัสคือนักพัฒนาและผู้ตรวจสอบที่สามารถทำหน้าที่เป็นผู้ใหญ่ที่เหมาะสม
gnasher729

25

ฉันจะไม่ใส่ความคิดเห็นของคุณเพราะอาจถือเป็นการอุปถัมภ์

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

มันเป็นการตรวจสอบโค้ดไม่ใช่การตรวจสอบโดยนักพัฒนาดังนั้น:

  • "สิ่งนี้ขณะที่การวนซ้ำอาจไม่เสร็จสิ้น" ไม่ใช่ "การวนซ้ำของคุณอาจไม่เสร็จสิ้น"
  • "กรณีทดสอบจำเป็นสำหรับสถานการณ์ X" ไม่ใช่ "คุณไม่ได้เขียนการทดสอบเพื่อให้ครอบคลุมสถานการณ์นี้"

นอกจากนี้ยังเป็นสิ่งสำคัญมากที่จะใช้กฎเดียวกันขณะพูดคุยเกี่ยวกับความเห็นกับผู้อื่น:

  • "แอนน์คุณคิดอย่างไรเกี่ยวกับรหัสนี้" ไม่ใช่ "แอนคุณคิดอย่างไรเกี่ยวกับรหัสของจอน"

การตรวจสอบรหัสไม่ใช่เวลาสำหรับการตรวจสอบประสิทธิภาพ - ควรทำแยกต่างหาก


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

15

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

เหตุใดคุณจึงตรวจสอบคำขอรวมทั้งหมดในข้อความเดียว

ประสบการณ์ของฉันในการตรวจสอบโค้ดคือผ่าน GitLab; ฉันมักจะจินตนาการว่าเครื่องมือตรวจสอบรหัสอื่น ๆ จะทำงานในทำนองเดียวกัน

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

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

ด้วยเวิร์กโฟลว์นี้การตรวจสอบโค้ดจะกลายเป็นแบบแยกส่วนและเหนียวแน่นน้อยลง บรรทัดจากการตรวจสอบโค้ดสามารถพูดได้ว่า

วิธีการที่ดีห่อสิ่งนี้ในฟังก์ชั่นเฉพาะ!

หรืออาจพูดว่า

ชื่อวัตถุนี้ไม่ตรงกับวัตถุประสงค์ของวัตถุจริงๆ บางทีเราอาจใช้ชื่อเช่น 'XYZ' แทนก็ได้

หรือหากมีปัญหาสำคัญกับส่วนฉันอาจเขียน:

ฉันเห็นว่ารหัสนี้ใช้งานได้ (และฉันเห็นว่าทำไมมันทำงาน) แต่มันต้องมีการศึกษาที่มุ่งเน้นที่จะเข้าใจมัน คุณช่วยกรุณา refactor มันเป็นฟังก์ชั่นที่แยกต่างหากดังนั้นมันจะง่ายต่อการรักษาในอนาคต?

(ตัวอย่าง: ฟังก์ชั่น ABC กำลังทำสามสิ่งอยู่ที่นี่: ทำให้งงงวย foo, ยกเว้น boz และ fripping zorf. ทั้งหมดนั้นอาจเป็นฟังก์ชั่นที่แยกจากกัน)

หลังจากเขียนทั้งหมดข้างต้นฉันสามารถสร้างความคิดเห็นสรุปเกี่ยวกับคำขอรวมทั้งหมดได้ดังนี้:

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


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

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

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

ฉันกำลังปิดคำขอรวมที่รอการเขียนใหม่ทั้งหมด


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


12

ฉันแปลกใจจริงๆที่ไม่มีใครเลือกมา แต่มีบางอย่างผิดปกติกับรีวิวตัวอย่างที่โพสต์

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

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

นี่คือตัวอย่างของการปรับปรุงเนื้อหาที่นำมาจากความเห็นของคุณ:

  • ก่อนที่เราจะดึงการเปลี่ยนแปลงใน Library \ ACME \ ExtractOrderMail Class เราต้องแก้ไขปัญหาเล็กน้อย
  • หากฉันไม่ได้รับบางสิ่งบางอย่าง "TempFilesToDelete" ไม่ควรอยู่นิ่ง
  • ในอนาคตเราอาจเรียกใช้ฟังก์ชันมากกว่าหนึ่งครั้งต่อการเรียกใช้นี่คือสาเหตุที่เราต้องการ (สิ่งที่ต้องทำที่นี่)
  • ฉันต้องเข้าใจว่าทำไม "GetErrorMailBody" จึงถือเป็นข้อยกเว้น (และฉันกำลังอยู่ที่นี่เพราะตอนนี้คุณควรมีข้อสรุปอยู่แล้ว)
  • SaveAndSend ควรเปลี่ยนชื่อเพื่อให้เหมาะกับพฤติกรรมของมันมากขึ้นเช่นเช่น "SendErrorMail"
  • ควรลบรหัสที่ใส่ความเห็นออกเพื่อความสะดวกในการอ่าน เราใช้การโค่นล้มสำหรับการย้อนกลับในที่สุด

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

ตอนนี้คุณจะกล่าวถึงเหตุผลที่รีวิวรหัสเหตุผลที่เพิ่มความตึงเครียดโดยนำปัจจัยมนุษย์ออกมาจากสมการ


ตัวอย่างรีวิวเป็นส่วนเสริมล่าสุดของคำถามผู้ตอบส่วนใหญ่ไม่เห็น
Izkata

8

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

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

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

มันเป็นเรื่องทางวัฒนธรรมและต้องการความไว้วางใจและการสื่อสารมากมาย และเวลาในการทำงานกับผลลัพธ์


2
"จุดตรวจสอบโค้ดทั้งหมดคือการค้นหาปัญหา" จริง - แต่สิ่งนี้ไม่ตอบคำถามตามที่ถาม
แอรอนฮอลล์

3
เขากำลังถามปัญหา xy ผิดดูmeta.stackexchange.com/questions/66377/what-is-the-the-xy-problem
Eiko

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

6

ฉันคิดว่าสิ่งที่ดีที่ต้องทำคือได้รับฉันทามติเกี่ยวกับมาตรฐานการเข้ารหัสก่อนที่จะทำการตรวจสอบ คนอื่นมักจะซื้ออะไรเพิ่มเติมเมื่อพวกเขามีอินพุต

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

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

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

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


4

สิ่งนี้อาจรุนแรง แต่ไม่ต้องกังวลกับการตอบรับที่ดีหากไม่มีสิ่งใดที่ดีในการวัด

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

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

  1. คุณจะเปลี่ยนอะไรเกี่ยวกับรหัสนี้ถ้าคุณมีเวลา
  2. คุณจะปรับปรุงส่วนนี้ของ codebase อย่างไร

ถามตอนนี้และถามหกเดือนนับจากนี้ มีประสบการณ์การเรียนรู้อยู่ที่นี่

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


1
"ไม่ต้องกังวลเกี่ยวกับการให้ข้อเสนอแนะที่ดีถ้าไม่มีอะไรดีในการวัด" ฉันคิดว่ามันยากที่จะเชื่อว่าเขาไม่สามารถหาสิ่งที่ดีที่จะพูดเกี่ยวกับโค้ดที่เขียนโดยโปรแกรมเมอร์มืออาชีพคนอื่น ๆ ในขณะที่ยังคงเพิ่มความคาดหวัง รหัส. นี่ไม่ได้ตอบคำถาม - มันเป็นความขัดแย้ง
Aaron Hall

2
@AaronHall: "รหัสของคุณสามารถเป็นตัวอย่างที่ดีว่าจะไม่เขียนโค้ด" ได้อย่างไร นั่นเป็นบวกหรือไม่
gnasher729

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

4

คุณภาพไม่ตึงเครียด

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

เคล็ดลับเก่าของการทำแซนวิช“ ข่าวดีในข่าวดี” อาจย้อนกลับมา นักพัฒนามีแนวโน้มที่จะเห็นว่ามันคืออะไร: สิ่งประดิษฐ์

องค์กรของคุณมีปัญหาจากบนลงล่าง

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

ทำไมถามเราว่าคุณต้องทำให้ทีมของคุณมีความสุขทำไม? คุณคิดว่าจะถามทีมของคุณหรือยัง?

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

การสร้างวัฒนธรรมแห่งคุณภาพ

วัฒนธรรมที่มีคุณภาพจะต้องได้รับการเลี้ยงดูให้เติบโตจากล่างขึ้นบน

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

พบกับทีมของคุณ ทำตัวแบบพฤติกรรมที่คุณต้องการเห็นในทีมของคุณ: ความอ่อนน้อมถ่อมตนความเคารพและความมุ่งมั่นที่จะปรับปรุง

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

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

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

ความคิดเห็นเกี่ยวกับรหัสความร่วมมือ

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

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

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

คุณภาพคือการเดินทาง

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

แต่ถ้ามันไม่ได้ผล ...

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


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

4

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

บางครั้งก็ถามว่าทำไมบางสิ่งบางอย่างถูกนำมาใช้ในทางที่เฉพาะเจาะจง เมื่อฉันคิดว่ามันไม่ดีฉันชี้ให้เห็นว่าฉันจะต้องพัฒนามันในอีกทางหนึ่ง

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

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

ตัวอย่าง:

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

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

ดี:

  • "ชื่อของตัวแปรนี้จำเป็นต้องเปลี่ยนเพื่อให้ตรงกับมาตรฐานการเข้ารหัสของเรา"

  • "'b' ในชื่อฟังก์ชันนี้จำเป็นต้องเป็นตัวพิมพ์ใหญ่เพื่อให้เป็น PascalCase"

  • "โค้ดของฟังก์ชันนี้ไม่ได้ถูกเยื้องอย่างเหมาะสม"

  • "รหัสนี้เป็นรหัสซ้ำที่พบในABC::XYZ()และควรใช้ฟังก์ชันนั้นแทน"

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

  • "ฟังก์ชันนี้ต้องได้รับการปรับโครงสร้างใหม่เพื่อให้เป็นไปตามมาตรฐานความซับซ้อน n-path ของเรา"

แย่:

  • "ฉันคิดว่าคุณสามารถปรับปรุงโค้ดนี้ได้โดยการเปลี่ยนชื่อตัวแปรเพื่อให้ตรงกับมาตรฐานของเรา"

  • " อาจเป็นการดีกว่าถ้าใช้การลองกับทรัพยากรเพื่อปิดสิ่งต่าง ๆ ในฟังก์ชันนี้อย่างถูกต้อง"

  • "มันอาจเป็นที่พึงปรารถนาที่จะพิจารณาเงื่อนไขทั้งหมดในฟังก์ชั่นนี้อีกครั้งความซับซ้อนของ N-path นั้นเกินความซับซ้อนที่อนุญาตสูงสุดของมาตรฐาน"

  • "ทำไมเครื่องหมายย่อหน้าถึงที่นี่ 2 ช่องว่างแทนที่จะเป็น 4 มาตรฐานของเรา"

  • "ทำไมคุณถึงเขียนฟังก์ชั่นที่ทำลายมาตรฐานความซับซ้อน n-path ของเรา"

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

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


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

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

3

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

หากนักพัฒนาซอฟต์แวร์ไม่ชอบโค้ดที่ดึงดูดการวิจารณ์แสดงว่าโซลูชันนั้นง่าย: เขียนโค้ดที่ดีกว่า คุณบอกว่าคุณมีปัญหาร้ายแรงเกี่ยวกับคุณภาพของรหัส นั่นหมายถึงต้องการรหัสที่ดีกว่า

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

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


+1 ผู้พัฒนาอาจรู้ว่าฟังก์ชั่นการตั้งชื่อย่อยอย่างเหมาะสมของเขาทำอะไร แต่จะเกิดอะไรขึ้นเมื่อเขาไปอยู่ใต้รถบัส
Mawg

3

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

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

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

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

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

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

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


+1 สำหรับการตรวจสอบโค้ดด้วยตนเองแทนการใช้ระบบอิเล็กทรอนิกส์ - ซึ่งจะทำให้ไม่ได้รับการวิจารณ์
alexanderbird

3

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

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

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


1

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

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


ไม่แน่ใจว่าทำไม downvote นี้ (downvotes ที่ไม่มีความคิดเห็นใด ๆ ที่โง่เขลาอย่างบ้าคลั่งในกระทู้เกี่ยวกับการตรวจสอบโค้ดที่ดี) ทุกคนที่ตรวจสอบควรเป็นขั้นตอนมาตรฐาน บนกระดาน Kanban จะมีคอลัมน์สำหรับการตรวจสอบโค้ดและผู้ใดก็ตามในทีมที่หยิบรายการต่อไปควรทำการตรวจสอบ (ด้วยคำเตือน; มือใหม่ไม่ควรเลือกบทวิจารณ์สักครู่แล้วควรเริ่มจากสิ่งที่ต้องการ ความรู้เกี่ยวกับโดเมนเพียงเล็กน้อย) บนกระดานต่อสู้คล้ายหลัก: ทำงานจากซ้ายไปขวา
Dewi Morgan

1

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

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

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


1

อาคารสถานที่ ...

โปรแกรมเมอร์เป็นนักแก้ปัญหา เรามีเงื่อนไขในการเริ่มแก้ไขข้อบกพร่องเมื่อพบปัญหาหรือข้อผิดพลาด

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

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

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

สรุปผลการวิจัย ...

ดังนั้นรายการตรวจสอบโค้ดเพิ่มเติมสามารถรวมเข้ากับเครื่องมืออัตโนมัติได้ดียิ่งขึ้นพวกเขาจะได้รับ

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

ตัวอย่างคำติชมข้อเสนอแนะรหัส ...

การเขียนซ้ำของตัวอย่างที่ได้รับรวมเทคนิคเหล่านี้:

  • เรื่อง:

    • Library \ ACME \ ExtractOrderMail Class
  • ปัญหาหลัก ...

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

0

หากคุณไม่มีอะไรดีที่จะพูดเกี่ยวกับรหัสที่มีอยู่ (ซึ่งฟังดูเข้าใจดี) ให้ลองมีส่วนร่วมในการพัฒนา

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

ที่ไหนเปลี่ยนชื่อ refactoring และการเปลี่ยนแปลงอื่น ๆ ที่มีการระบุไว้ทำพวกเขาในแพทช์ที่แยกจากกันก่อนหรือหลัง

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

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

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

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

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


ไม่ว่าจะเป็นการแยกแพทช์หรือไม่นโยบายของหน้าต่างที่แตกจะต้องได้รับการติดตั้งด้วยรหัสดั้งเดิมไม่ว่าจะเป็นนโยบายที่ "ไม่แก้ไข windows ที่เสียหาย" หรือ "เฉพาะใน [วิธี / คลาส / ไฟล์?] ที่ได้รับการแก้ไข " จากประสบการณ์ของฉันการป้องกันไม่ให้นักพัฒนาแก้ไขหน้าต่างที่แตกเป็นพิษต่อขวัญกำลังใจของทีม
Dewi Morgan

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

ตกลงกัน! นโยบายที่ถูกผลักออกจากทีมแทนที่จะบังคับจากภายนอกเป็นประเภทเดียวที่สามารถทำงานได้ฉันรู้สึก
Dewi Morgan

0

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

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

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

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

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

[1] ไม่สามารถแก้ไขได้เพราะมีคนพูดว่า "โอเค" หรือหยุดการต่อสู้ ไม่มีใครอยากเป็นคนที่จะบอกว่า X ไม่เหมาะสำหรับ {สติปัญญาประสบการณ์พลังคนกำหนดเวลา ฯลฯ } แต่นั่นไม่ได้หมายความว่าเมื่อมันมาถึงอินสแตนซ์ที่เฉพาะเจาะจงของการทำ X ...


-1

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

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

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


ไม่แน่ใจว่าทำไม downvote นี้ (downvotes ที่ไม่มีความคิดเห็นใด ๆ ที่โง่เขลาอย่างบ้าคลั่งในกระทู้เกี่ยวกับการตรวจสอบโค้ดที่ดี) ทุกคนที่ตรวจสอบควรเป็นขั้นตอนมาตรฐาน บนกระดาน Kanban จะมีคอลัมน์สำหรับการตรวจสอบโค้ดและผู้ใดก็ตามในทีมที่หยิบรายการต่อไปควรทำการตรวจสอบ (ด้วยคำเตือน; มือใหม่ไม่ควรเลือกบทวิจารณ์สักครู่แล้วควรเริ่มจากสิ่งที่ต้องการ ความรู้เกี่ยวกับโดเมนเพียงเล็กน้อย) บนกระดานต่อสู้คล้ายหลัก: ทำงานจากซ้ายไปขวา
Dewi Morgan

2
@DewMorgan ฉันไม่เห็นด้วยกับ "มือใหม่ไม่ควรรับความคิดเห็นในขณะที่" ความคิดเห็นจากมือใหม่เป็นวิธีที่ยอดเยี่ยมสำหรับพวกเขาในการทำความคุ้นเคยกับรหัสฐาน ที่กล่าวว่าพวกเขาไม่ควรเป็นนักวิจารณ์คนเดียว ! และนั่นก็บอกว่าฉันไม่ว่าในกรณีใด ๆ ก็ควรระวังให้มีผู้ตรวจสอบเพียงคนเดียวส่วนใหญ่
ไม่แยแส
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.