กระบวนการตรวจสอบโค้ดทั่วไปคืออะไรและอะไรที่ถือว่าไม่ดี

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

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

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

ดังนั้นคำถามของฉันคือถ้านี้ยุติธรรม หรือเป็นเรื่องธรรมดา?

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

IMHO เป็นปัญหาจริงเนื่องจากไม่มีการจัดลำดับความสำคัญ เมื่อคุณได้รับ 100-300 ความคิดเห็นจะต้องมีบางคนที่มีลำดับความสำคัญ A (ข้อบกพร่องจริง) บางส่วนของพวกเขา Prio B (น่าจะนำไปสู่ข้อบกพร่องในภายหลัง) และบางส่วนของพวกเขา Prio C (ทุกอย่างอื่น) บอกเพื่อนร่วมงานของคุณว่าคุณเต็มใจที่จะเคารพความปรารถนาทั้งหมดของพวกเขา แต่เพื่อให้การเปลี่ยนแปลงมีประสิทธิภาพและเวลาของคุณมี จำกัด จากนั้นเริ่มต้นด้วยการแก้ไข comment ความคิดเห็นที่ลำดับความสำคัญก่อนและถ้าคุณจริงๆมีเวลานานหลังจากนั้นคุณสามารถเริ่มต้นด้วย B (ถ้าคุณโชคดีเจ้านายของคุณจะเข้าใจว่าการแก้ไขลำดับความสำคัญ B และ C ไม่ได้ดังนั้นสิ่งที่สำคัญและให้คุณ งานที่สำคัญมากกว่าแทนที่จะเสียเวลา)

การตรวจสอบโค้ดอาจเป็นกระบวนการที่แบ่งแยกได้

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

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

ถ้าเป็นอย่างหลังฉันขอแนะนำให้ทำการอ่านโค้ดและศึกษาเพื่อพยายามทำให้โค้ดของคุณมีคุณภาพระดับมืออาชีพ

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

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

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

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

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

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

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

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

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

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

² สมมติว่าถึงแม้ว่าความคิดเห็นจะมากเกินไป แต่ก็มีบางค่าที่อยู่ในนั้น

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

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

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

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

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

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

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

ความแตกต่างที่สำคัญบางอย่างกับกระบวนการตรวจสอบทีมของเรา:

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

สำหรับ 50 LOC 300 ความคิดเห็นดูเหมือนว่าจะมากเกินไปและ - wow - 3 ผู้ตรวจสอบสำหรับทุกคำขอดึง? บริษัท ของคุณต้องมีทรัพยากรจำนวนมาก

จากประสบการณ์ของฉันสำหรับกระบวนการตรวจสอบโค้ดที่มีประโยชน์จะต้องมีกฎและ / หรือหลักเกณฑ์:

• ลำดับความสำคัญของความคิดเห็น
• การจำแนกประเภทของความคิดเห็น (Bug, Code Code ฯลฯ )
• เห็นด้วยสถาปัตยกรรม / การออกแบบที่จะปฏิบัติตาม
• ตกลงรหัสสไตล์

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

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

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

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

คำแนะนำของฉันคือการประหยัดเวลา เร่งผลตอบรับ ฉันจะ:

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

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