การตรวจสอบโค้ดจำเป็นสำหรับนักพัฒนารุ่นใหม่หรือไม่?

ฉันเคยทำงานที่สอง บริษัท ซึ่งแต่ละคนมีวิธีการต่างกันเมื่อพูดถึงบทวิจารณ์โค้ด:

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

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

ดังนั้นฉันจึงสับสน กระบวนการตรวจสอบรหัสจำเป็นหรือไม่ ถ้าเป็นเช่นนั้นทำไม และถ้าไม่เป็นเช่นนั้นทำไมไม่

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

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

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

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

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

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

น่าเสียดายที่มีน้อยคนที่ต้องการทำสิ่งนี้ แต่เห็นได้จากมุมมองทางธุรกิจที่ควรทำ

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

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

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

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

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

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

คนที่คล่องแคล่วจะพูดว่า: "คุณไม่จำเป็นต้องมีการตรวจสอบโค้ดเพียงแค่จับคู่การเขียนโปรแกรมและเขียนการทดสอบที่ดี" :)

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

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

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

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

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

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

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

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

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

แต่สิ่งที่เกี่ยวกับ บริษัท เหล่านั้นที่ไม่ได้ตรวจสอบรหัส? พวกเขาอาจเป็น บริษัท ที่มีปัญหาด้านเทคโนโลยีมากมายและอีกมากมายที่พวกเขาบอกผู้บริโภคว่า "ล่ม" ;-)

ดังนั้นฉันจะตอบคำถามของคุณทั้งหมด:

• ใช่จำเป็นต้องมีกระบวนการตรวจสอบ
• ทำไม? เนื่องจากเหตุผลที่ฉันระบุไว้ข้างต้น

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

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

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

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

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

อะไรคือความแตกต่างในการแทรกแซงความคิดของคุณก่อนที่จะตรวจสอบในรหัสของคุณ (ตรวจสอบ) หรือหลังจากนั้นเนื่องจากข้อผิดพลาดการรับที่ฉลาด / ยากเกินไปที่จะเข้าใจหรือไม่ปฏิบัติตามมาตรฐานมาตรฐานที่ยอมรับ? มันเป็นอัตตาของคุณหรือเปล่า

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

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

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

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

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

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

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

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

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

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

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

พวกเขาจำเป็นอย่างยิ่งเนื่องจากพวกเขามีประสบการณ์น้อย