ฉันจะจัดการความไม่เห็นด้วยในการตรวจสอบรหัสเกี่ยวกับกรณีขอบที่ไม่น่าได้อย่างไร

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

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

ฉันจะให้ตัวอย่าง:

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

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

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

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

กรณีที่คลุมเครือซึ่งไม่น่าจะเกิดขึ้นมาก - อันที่จริงฉันไม่แน่ใจว่ามันเป็นไปได้ที่จะเกิดขึ้น

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

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

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

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

ฉันสามารถยกตัวอย่างกรณีมุมที่ไม่อาจเกิดขึ้นที่ทำให้เกิดภัยพิบัติได้

เมื่อAriane 4ได้รับการพัฒนาค่าจากaccelerometersด้านข้างจะถูกปรับขนาดให้พอดีกับจำนวนเต็ม 16 บิตที่ถูกเซ็นชื่อและเนื่องจากการส่งออก accelerometers สูงสุดที่เป็นไปได้เมื่อปรับสัดส่วนจะไม่เกิน 32767 และขั้นต่ำไม่ต่ำกว่า - 32768 มี“ ไม่จำเป็นสำหรับค่าใช้จ่ายในการตรวจสอบช่วง” โดยทั่วไปอินพุตทั้งหมดควรจะมีการตรวจสอบช่วงก่อนการแปลงใด ๆ แต่ในกรณีนี้ที่จะพยายามจับมุมกรณีที่เป็นไปไม่ได้

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

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

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

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

การอธิบาย

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

สิ่งหนึ่งที่ฉันไม่คิดว่าฉันได้รับการพูดถึงในประเภทถึงแม้ว่ามันจะเป็นประเภทที่ @SteveBarnes ตอบ:

ผลสะท้อนของความล้มเหลวคืออะไร?

ในบางสาขาความล้มเหลวเป็นข้อผิดพลาดบนเว็บเพจ หน้าจอสีน้ำเงินของพีซีและเริ่มต้นใหม่

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

มีโลกที่แตกต่างในสุดขั้วเหล่านั้น

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

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

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

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

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

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

พระราชบัญญัติเช่นโคลัมโบ

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

ฉันคิดว่ามันเกี่ยวข้องกับวิธีการโสคราตีสด้วย

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

ในกรณีของคุณคุณมีสองแนวคิดที่นี่ แต่พวกเขามีเป้าหมายเดียวกันคือเพื่อทำให้โค้ดดีขึ้น

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

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

พวกเขาเห็นอะไรที่คุณไม่เห็น คุณเห็นอะไรที่พวกเขาไม่เห็น ในฐานะนักพัฒนารุ่นน้องคุณอยู่ในตำแหน่งที่ยอดเยี่ยมเพราะคุณควรถามคำถามโดยธรรมชาติ ในอีกคำตอบหนึ่งมีคนกล่าวถึงกรณีมุมที่น่าแปลกใจ ดังนั้นคุณสามารถเริ่มต้นด้วย "ช่วยฉันเข้าใจ - ฉันอยู่ภายใต้ความประทับใจที่ X, Y, และ Z - ฉันหายไปทำไมวิดเจ็ต framboozle ทำไมฉันอยู่ภายใต้การแสดงผลที่จะผสมภายใต้สถานการณ์ที่ยากลำบากจะ ก้านไม้ Swizzle ติดอยู่กับแปรงของ ANZA หรือไม่? "

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

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

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

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

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

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

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

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

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

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

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

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

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

ในที่สุดในฐานะความคิดเห็นทั่วไปเกี่ยวกับคุณค่าของการวิจารณ์โค้ด (และสรุปสาระสำคัญของสิ่งที่ฉันได้กล่าวไว้ข้างต้น) ฉันชอบข้อความนี้ในMaintainers Don't Scaleโดย Daniel Vetter :

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

รหัสอาจดีกว่าเสมอ

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

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

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

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

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

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

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

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

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

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

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

แสดงความคิดเห็นต่อรหัสของฉันอย่างต่อเนื่องที่แนะนำให้ฉันทำงานมากกว่าที่จำเป็น

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

เขาแนะนำว่าฉันจัดการกับกรณีที่คลุมเครือซึ่งไม่น่าจะเกิดขึ้นได้มากนัก

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

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

• ทำเครื่องหมายความคิดเห็นของคุณตามประเภท "Critical" / "Must-Do" / "ตัวเลือก" / "การปรับปรุงที่แนะนำ" / "ดีใจที่มี" / "I'm musing"

  หากดูเหมือนว่า CDO / anal / ซับซ้อนเกินไปใช้อย่างน้อย 2 ระดับ: "ต้องแก้ไขเพื่อผ่านการตรวจทานและได้รับอนุญาตให้รวมการเปลี่ยนแปลงของคุณ" / "อื่น ๆ ทั้งหมด"

คำแนะนำสำหรับการจัดการคำแนะนำการตรวจสอบโค้ดที่ดูมีความสำคัญน้อยกว่า:

• สร้างตั๋วแบบเปิดในระบบตั๋วที่คุณเลือก (ทีมของคุณใช้อย่างใดอย่างหนึ่งหวังว่า?) ติดตามข้อเสนอแนะ

• ใส่ตั๋ว # เป็นความคิดเห็นการตอบสนองต่อรายการตรวจสอบรหัสหากกระบวนการของคุณอนุญาตให้ตอบกลับความคิดเห็นเช่น Fisheye หรือรีวิวอีเมลทำ

• ติดต่อผู้ตรวจสอบและถามอย่างชัดเจนว่ารายการนั้นเป็นประเภท "ต้องแก้ไขหรือไม่ถูกผสาน / เปิดตัว"

  • หากคำตอบคือ "ใช่" แต่คุณไม่เห็นด้วยให้ผู้รับผิดชอบในการจัดการโครงการ (PM, ผู้จัดการของคุณ ฯลฯ ... ) ตัดสินใจ - แสดงความขัดแย้งอย่างเต็มที่และตรงไปตรงมา นี่ไม่ใช่เรื่องของคุณ "ถูกต้อง" แต่เกี่ยวกับสิ่งที่ดีกว่าสำหรับโครงการดังนั้นงาน PM / ผู้จัดการ

ตอนนี้ให้ถือว่าตั๋วนั้นเป็นคำขอพัฒนาอื่น ๆ

1. หากมีการตัดสินใจว่าจะเป็นเรื่องเร่งด่วนหลังจากการเลื่อนระดับให้ปฏิบัติตามคำขอการพัฒนาแบบเร่งด่วนใด ๆ Deprioretize งานอื่นและทำงานในเรื่องนี้

2. มิฉะนั้นทำงานตามลำดับความสำคัญที่ได้รับมอบหมายและ ROI ของมัน (ซึ่งอาจแตกต่างกันไปตามสายธุรกิจของคุณตามที่อธิบายไว้ในคำตอบอื่น ๆ )

คุณไม่ควรส่งต่อสิ่งนี้ไปยังฝ่ายบริหาร

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

ในหลายกรณีคุณภาพของรหัสขึ้นอยู่กับกฎที่ไม่ได้เขียนไว้ในทีมพัฒนาและความพยายามพิเศษที่โปรแกรมเมอร์เขียนไว้

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

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

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

หากคุณคิดว่ามีบางอย่างผิดปกติและคุณค่อนข้างมีความเชี่ยวชาญในสาขาของคุณโอกาสที่คุณจะสูง

นี่คือข้อความบางส่วนที่อาจเป็นประโยชน์กับคุณ:

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

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

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

โดยทั่วไปพยายามหลีกเลี่ยงทั้งสองอย่างต่อไปนี้:

• คุณไม่ได้ทำสิ่งที่ร้องขอ
• คุณทำให้ผู้ตรวจสอบของคุณรู้สึกเป็นใบ้

หากเขาตรวจสอบรหัสของคุณจริง ๆ ก็เป็นเพราะฝ่ายบริหารเชื่อใจเขามากกว่าคุณ

เมื่อมีความขัดแย้งระหว่างการตรวจสอบโค้ดเกี่ยวกับขอบเขต:

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

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

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

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

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

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

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

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

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

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

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