วิธีปฏิบัติที่คล่องตัว: การตรวจสอบโค้ด - การตรวจสอบล้มเหลวหรือแจ้งปัญหา

ในตอนท้ายของการวิ่ง 2 สัปดาห์และงานหนึ่งมีการตรวจสอบโค้ดในการตรวจสอบเราค้นพบฟังก์ชั่นที่ใช้งานได้ แต่อ่านได้ค่อนข้างนานและมีโค้ดไม่กี่กลิ่น งาน refactor ง่าย

มิฉะนั้นงานที่เหมาะกับความหมายของการทำ

เรามีสองทางเลือก

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

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

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

มีปัญหาหรือข้อพิจารณาใด ๆ เกี่ยวกับการเพิ่มตั๋วจากด้านหลังของการตรวจทานแทนที่จะล้มเหลวหรือไม่?

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

ในการตรวจสอบเราค้นพบฟังก์ชั่น

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

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

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

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

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

refactor เป็นงานชิ้นเล็ก ๆ และจะทำในการวิ่งครั้งต่อไป (หรือแม้กระทั่งก่อนที่มันจะเริ่ม) เป็นเรื่องเล็กจุดครึ่ง

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

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

ผ่าน / ล้มเหลวเป็นสถานะไบนารีโดยเนื้อแท้ซึ่งโดยเนื้อแท้ทั้งหมดหรือไม่มีอะไร

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

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

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

มิฉะนั้นงานที่เหมาะกับความหมายของการทำ

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

ในตอนท้ายของการวิ่ง 2 สัปดาห์และงานมีการตรวจสอบรหัส [... ] งาน refactor ง่าย

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

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

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

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

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

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

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

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

นี่น่าจะเป็นปัญหา
ในทางทฤษฎีคุณรู้ว่าคุณควรทำอะไร แต่ใกล้ถึงกำหนดดังนั้นคุณไม่ต้องการทำสิ่งที่คุณรู้ว่าควรทำ

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

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

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

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

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

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

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

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

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

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

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

คำตอบที่ได้รับคะแนนสูงกว่าที่นี่ดีมาก อันนี้ระบุถึงมุมการเปลี่ยนโครงสร้าง

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

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

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

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

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

refactor เป็นงานชิ้นเล็ก ๆ และจะทำในการวิ่งครั้งต่อไป (หรือแม้กระทั่งก่อนที่มันจะเริ่ม) เป็นเรื่องเล็กจุดครึ่ง

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

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

2. คุณกำลังพัฒนาโค้ดที่จะทำงานได้มากขึ้นเพื่อทำความเข้าใจในครั้งต่อไปที่มีคนต้องการทำงานกับมันทำให้เรื่องใช้เวลานานขึ้น

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

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

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

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

คำถามของคุณเรียกร้องอย่างชัดเจนว่า "การปฏิบัติที่คล่องตัว" ดังนั้นเรามาทบทวนการประกาศความคล่องตัว (เน้นที่เหมือง):

เรากำลังเปิดเผยวิธีที่ดีกว่าในการพัฒนาซอฟต์แวร์ด้วยการทำและช่วยเหลือผู้อื่นให้ทำ ผ่านงานนี้เราได้เห็นคุณค่า:

• บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ
• ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุม
• การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา
• ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

นั่นคือในขณะที่มีค่าในรายการทางด้านขวาเราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น

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

เริ่มการทำงานร่วมกัน หยุดการตรวจสอบโค้ดที่ล้มเหลว

ในการตรวจสอบเราค้นพบฟังก์ชั่นที่ใช้งานได้อ่านได้ แต่มันค่อนข้างนานและมีกลิ่นรหัสไม่กี่ ...

มีปัญหาหรือข้อพิจารณาใด ๆ เกี่ยวกับการเพิ่มตั๋วจากด้านหลังของการตรวจทานแทนที่จะล้มเหลวหรือไม่?

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

หนึ่งในคำพูดที่เรามีคือ "เลือกการปรับปรุงที่ก้าวหน้ากว่าความสมบูรณ์แบบที่เลื่อนออกไป"

เรามีกระบวนการที่คล่องแคล่วและสร้างคุณลักษณะ 'พิสูจน์แนวคิด' ในจำนวนที่ค่อนข้างดี (1 หรือ 2 ต่อการวิ่ง) ที่ทำให้มันผ่านการพัฒนาและทดสอบ ?) อัลฟ่าหรือเบต้า ... บางคนมีชีวิตรอดบางคนไม่

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

ในความคิดของฉันมีสองวิธีในการดูปัญหานี้:

1. วิธีการศึกษา
2. วิธีโลกแห่งความจริง

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

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

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

มันควรจะเป็นการเรียกที่ง่ายและความจริงที่ว่ามันไม่ได้เป็นการแนะนำว่าคุณไม่มีกฎระเบียบที่ชัดเจนในการเขียนโค้ด

1. "ฟังก์ชั่นค่อนข้างยาว" เขียนลง: ฟังก์ชั่นจะต้องมีความยาวน้อยกว่าเส้น X (ฉันไม่แนะนำว่ากฎเกี่ยวกับความยาวของฟังก์ชั่นเป็นสิ่งที่ดี)

2. "มีกลิ่นรหัสบางอย่าง" เขียนลง: ฟังก์ชั่นสาธารณะจะต้องมีการทดสอบหน่วยสำหรับฟังก์ชั่นและประสิทธิภาพทั้งการใช้งาน CPU และหน่วยความจำจะต้องอยู่ภายใต้ขีด จำกัด x และ y

หากคุณไม่สามารถหาปริมาณกฎสำหรับการผ่านการตรวจสอบโค้ดคุณจะได้รับกรณีของรหัสที่คุณไม่ชอบ

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

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

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

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

Re: มันเป็นไปไม่ได้ที่จะเขียนกฎกติกา !!

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

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