คุณจะทำอย่างไรเมื่อการตรวจสอบโค้ดยากเกินไป?

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

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

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

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

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

ดังนั้นวิธีจัดการกับสถานการณ์นี้ เริ่มต้นด้วยการไม่เข้าไปข้างใน:

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

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

• เขียนชุดการทดสอบอัตโนมัติ อย่างชัดเจน

• อย่าทำการเปลี่ยนแปลงในวงกว้าง สร้างชุดของการเปลี่ยนแปลงขนาดเล็กที่กำหนดเป้าหมายซึ่งแต่ละอย่างสามารถเห็นได้ว่าถูกต้อง

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

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

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

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

คำพูดที่จะสรุป:

"ถ้าคุณต้องการที่จะไปอย่างรวดเร็วไปคนเดียวถ้าคุณต้องการที่จะไปให้ไกลไปด้วยกัน"

ยินดีต้อนรับสู่โลกของการพัฒนาซอฟต์แวร์แบบดั้งเดิม

คุณมีบรรทัดของโค้ดจำนวน 100, พันล้านและ 10 ล้านเส้น

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

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

ในโลกที่สมบูรณ์แบบฐานรหัสขนาดใหญ่ของคุณได้รับการทดสอบโดยหน่วยทดสอบ คุณไม่ได้อยู่ในโลกที่สมบูรณ์แบบ

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

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

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

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

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

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

ในระยะสั้นนี้เป็นศิลปะของความเป็นไปได้ - การเปลี่ยนแปลงโดยไม่ทำลายสิ่งต่าง ๆ ที่เป็นกรณีธุรกิจ

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

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

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

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

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

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

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

แก้ไขปัญหาที่มีขนาดใหญ่กว่าซึ่งทำให้การตรวจสอบโค้ดยากเกินไป

คนที่ฉันเคยเห็น:

1. ไม่มีชุดทดสอบหน่วย
2. การรวมรหัสที่ซับซ้อนซึ่งสามารถหลีกเลี่ยงได้โดยโครงสร้างรหัสที่สมเหตุสมผลและการมอบหมายหน้าที่การเข้ารหัส
3. การขาดสถาปัตยกรรมพื้นฐานที่ชัดเจน

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

2. คุณยังสามารถตรวจสอบกลิ่นรหัสรูปแบบและรูปแบบการต่อต้านมาตรฐานการจัดรูปแบบรหัสหลักการ SOLID ฯลฯ โดยไม่จำเป็นต้องผ่านรายละเอียดของรหัสทุกครั้ง

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

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

ในสถานการณ์นี้จำนวนเวลาที่ใช้ในการตรวจสอบความปลอดภัยของการเปลี่ยนแปลงการขาดการถดถอย ฯลฯ นั้นมากเกินไป

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

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

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

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

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

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

บิตที่ยุ่งยากเกิดขึ้นเมื่อคุณพบข้อบกพร่อง รหัสรังหนูของคุณจะทำสิ่งผิดในบางกรณีเพราะสิ่งต่าง ๆ มีความเปราะและซับซ้อนมากสิ่งต่าง ๆ จะผิดไป เมื่อคุณแยกหน่วยรหัสที่เหลือจะชัดเจนขึ้น (ฉันมีกรณีที่หลังจาก refactoring บางฟังก์ชันเริ่มต้นด้วย "if (condition1 && เงื่อนไข 2 && เงื่อนไข 3)) ();" ซึ่งเป็นพฤติกรรมก่อนการ refactoring ชัดเจนเท่านั้นฉันลบบรรทัดนั้น :-) คุณจะเห็น พฤติกรรมแปลก ๆ และไม่ต้องการอย่างชัดเจนเพื่อให้คุณสามารถแก้ไขได้ ในทางตรงกันข้ามนั่นคือที่ที่คุณต้องเปลี่ยนพฤติกรรมของรหัสที่มีอยู่เพื่อที่จะต้องทำอย่างระมัดระวัง)

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

หากคุณไม่พอใจที่จะจัดส่งด้วยซอฟต์แวร์ buggy / non-functional และแก้ไขในภายหลังความพยายาม V&V ควรนานกว่าความพยายามในการพัฒนา!

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

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

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

เครื่องมือที่มีอยู่ให้ใช้พวกเขา! :)

ฉันไม่รู้ว่าทำไมมันถึงยังไม่ถูกกล่าวถึง แต่ 2 ชิ้นนี้เป็นส่วนที่สำคัญที่สุด:

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

* ตัวอย่าง: คุณแทนที่ไลบรารี่ A ด้วยไลบรารี่ B. หนึ่งรายการเปลี่ยนชื่อแนะนำไลบรารี B, ลิสต์ที่แตกต่างกันหลายรายการแทนที่การใช้งานของ A ด้วย B ทีละชิ้น (เช่นหนึ่งรายการต่อหนึ่งโมดูล) และรายการสุดท้ายลบไลบรารี A

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

อย่าประมาทค่าที่เป็นไปได้ของการแก้ไขรหัส พวกเขาสามารถตรวจจับข้อบกพร่องได้ดี:

• ค้นหาข้อบกพร่องที่จะตรวจจับได้ยากแม้ว่าจะทำการทดสอบ
• ค้นหาข้อบกพร่องที่ยากที่จะระบุ / แก้ไขในขณะที่ทำการทดสอบ

พวกมันยังมีประโยชน์สำหรับเหตุผลอื่น ๆ :

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

สิ่งที่ต้องทำในสถานการณ์เช่นนี้?

ในกรณีที่ดีที่สุด / เหมาะการตรวจสอบรหัสผ่านไม่เพียง แต่หมายถึง "ไม่มีข้อบกพร่องที่เห็นได้ชัด": มันหมายถึง "ไม่มีข้อบกพร่องที่เห็นได้ชัด" (แม้ว่าแน่นอนว่าคุณต้องการทดสอบด้วย)

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

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

สิ่งที่เกี่ยวกับการรวมระบบการทดสอบและการยอมรับ?

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

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

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

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

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

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

การพัฒนาซอฟต์แวร์ไม่มีแนวปฏิบัติที่เหมาะสมที่สุดที่ธุรกิจต้องการ

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

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

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

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

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

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

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

* เกือบ: L4 microkernel ได้รับการตรวจสอบรหัสในขณะที่กลับมาโดยระบบพิสูจน์อัตโนมัติซึ่งพิสูจน์รหัสของมันหากรวบรวมโดยคอมไพเลอร์มาตรฐาน C ++ จะทำสิ่งที่เอกสารระบุไว้

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

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

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

จะทำอย่างไรเมื่อบทวิจารณ์โค้ด "ยากเกินไป"

1. กลับไปที่สาขารหัสบรรทัดหลัก
2. เขียนการทดสอบสำหรับการใช้งานที่คุณได้ทำใหม่ (เช่นการทดสอบการใช้งาน)
3. รับการทดสอบเพื่อผ่าน
4. รวมการทดสอบเข้ากับรหัสที่ "ยากต่อการทดสอบ"
5. การทดสอบยังคงผ่านหรือไม่

ใช่

นักพัฒนาของคุณยอดเยี่ยมมาก! กลับมาอีกครั้งสำหรับทุกคน!

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

ไม่

ทำการปรับโครงสร้างใหม่และเพิ่มการครอบคลุมการทดสอบจนกว่าการทดสอบจะผ่าน

เช่นเดียวกับการคูณการทบทวนรหัสจะให้ผลลัพธ์เป็นศูนย์เมื่อใช้กับศูนย์ มันไม่ได้เพิ่มมูลค่าในกรณีเช่นนี้ในขณะที่ในกรณีอื่น ๆ ส่วนใหญ่มันจะ

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

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