การตรวจสอบรหัสมาตรฐานประกอบด้วยอะไร


19

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


10
เห็นได้ชัดว่าที่นี่เราไม่มีเวลาสำหรับการตรวจสอบโค้ด แต่มีเวลามากมายในการจัดการกับสกรูที่เกิดขึ้น ฉันหวังว่าฉันล้อเล่น
MetalMikester

คำตอบ:


12

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

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


ฮ่า ๆ ต้องมีความเข้าใจที่ดีเกี่ยวกับการทดสอบหน่วย และข่าวดีก็คือการทดสอบเป็นเพียงแค่สามัญสำนึก - ใช้เวลาคิดน้อยกว่าพูดว่า ... เวลาที่ใช้ในการเลือกภาษาใหม่
งาน

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

6

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

แต่เมื่อมีบางสิ่งที่เกี่ยวข้องเกิดขึ้นมากขึ้นก็มักจะเป็นเช่นนี้:

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

4

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

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

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


2

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

สิ่งสำคัญคือการบังคับใช้มาตรฐานในการตรวจสอบโค้ด แต่ไม่ให้เน้นเฉพาะ

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


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

0

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

  • ไม่สามารถแก้ไขได้เนื่องจากข้อ จำกัด ด้านเวลา
  • พบว่าน่ารำคาญกว่าแนวทางที่ควรปฏิบัติ

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

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

แนวทางในใจของฉันอาจมีอยู่ของ:

  • ไวยากรณ์ทั่วไปและแนวทางการเข้ารหัส (เลือกอันที่มีอยู่แล้วและใช้เครื่องมือที่ตรวจสอบโดยอัตโนมัติ)
  • การจัดการข้อยกเว้นที่เหมาะสม
  • การบันทึกที่เหมาะสม
  • ใช้กระบวนทัศน์สำหรับภาษา (SOLID สำหรับภาษา OO)
  • ชัดเจนและคิดออกดีขึ้นต่อกันระหว่างส่วนประกอบ (ใช้เครื่องมือเช่น NDepend)
  • กำลังสร้างสคริปต์
  • แสดงเอกสาร (นักพัฒนาเริ่มต้น, คู่มือการติดตั้ง)
  • ห้องสมุดภายในที่จะใช้
  • นโยบาย บริษัท
  • เครื่องมือของบุคคลที่สามที่ไม่ได้รับอนุญาต
  • ทดสอบหน่วยปัจจุบันและไม่ล้มเหลว
  • รหัสความคุ้มครอง 90%
  • ...

เมื่อถึงตอนนั้นการตรวจสอบรหัสจะประกอบด้วยซอฟต์แวร์ที่ตรวจสอบกับแนวทางปฏิบัติและ:

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