นักพัฒนาควรใส่บั๊กในระบบติดตามบั๊กหรือไม่

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

ฉันมักจะใส่ลงในระบบติดตามข้อผิดพลาดและปล่อยให้กระบวนการเล่นเอง (เช่น triaging, การกำหนด ฯลฯ ) อย่างไรก็ตามฉันแทบจะไม่เคยเห็นนักพัฒนารายอื่นป้อนบั๊ก (ทำไมถึงเป็นอย่างนั้น?)

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

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

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

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

สำหรับสาเหตุที่นักพัฒนาซอฟต์แวร์รายอื่นไม่ป้อนบั๊กคุณจะต้องถามพวกเขา พวกเขาอาจจะควร

คุณต้องป้อนข้อบกพร่องในระบบติดตามบั๊กในทั้งสองกรณี:

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

• เมื่อข้อผิดพลาดเกี่ยวข้องกับรหัสที่คุณไม่ได้ทำงานในตอนนี้หรือส่วนที่นักพัฒนารายอื่นทำงานได้

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

สิ่งนี้ยังอธิบายได้ว่าทำไม freelancer ต้องใช้ทั้งการควบคุมเวอร์ชันและระบบติดตามบั๊ก: เครื่องมือทั้งสองนี้ไม่เพียง แต่สำหรับทีมเท่านั้น

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

เหตุผลที่ไม่เข้าร่วมคือ:

• กระบวนการวัดและลงโทษตามการรายงานข้อบกพร่อง - อย่ารายงานไม่ได้รับการลงโทษ ในกรณีนี้ออกจากองค์กร
• กระบวนการนี้เป็นภาระ - ใช้ความพยายามและเวลามากเกินไปในการเข้าสู่ข้อบกพร่องและไปถึงจุดที่จะแก้ไข ควรเปลี่ยนกระบวนการเพื่อให้นักพัฒนาซอฟต์แวร์สามารถติดตามบั๊กที่มีน้ำหนักเบาได้อย่างรวดเร็วผ่านกระบวนการ triage / accept / fixed
• นักพัฒนาซอฟต์แวร์บางคนขี้เกียจ / เลอะเทอะ / แฮ็กเกอร์ที่ไม่สนใจว่าผลกระทบของสิ่งที่พวกเขาทำกับคนอื่นอาจเป็นอย่างไร รับสมัครนักพัฒนามืออาชีพ
• ฉันเป็นวงดนตรีชายคนหนึ่งไม่เห็นจุด ไปทำงานให้กับวงดนตรี 2 คนแล้วคุณจะ ....

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

การตัดสินใจไม่ชัดเจนและเกี่ยวข้องกับการแลกเปลี่ยน

(บางส่วน) ข้อดี

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

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

การบันทึกข้อบกพร่องในขณะที่คุณพบว่าเป็นนิสัยที่ดีที่จะพูด

(บางคน)

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

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

บางครั้งการติดตามบั๊กไม่ใช่การใช้เวลาอย่างมีประสิทธิภาพที่สุด

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

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

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

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

เมื่อเวลาผ่านไปฉันพบว่าการปรับแต่งทุกประเภทมีประโยชน์ ตัวอย่างเช่น:

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

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

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

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

ฉันจะเพิ่มว่าแม้ว่าข้อผิดพลาดได้รับการแก้ไขแล้ว (ซึ่งไม่ควรเกิดขึ้นก่อนที่จะบันทึกในตัวติดตามปัญหา) มันเป็นความคิดที่ดีที่จะติดตามมัน

ด้วยวิธีนี้หากปัญหาควรเกิดขึ้นอีกในอนาคต (การถดถอยเกิดขึ้น!) มันค่อนข้างง่ายที่จะรับรู้ว่าปัญหาเป็น "จัดการแล้ว" และอ่านวิธีการแก้ไขในครั้งแรก

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

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

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

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

การเขียนโปรแกรมเป็นงานที่ซับซ้อนเป็นพื้นฐาน ข้อบกพร่องมีความซับซ้อน ดังนั้นฉันจึงประเมินข้อผิดพลาดสองปัจจัย:

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

ฉันจะจำแนกข้อผิดพลาดเป็นหนึ่งในประเภทต่อไปนี้:

1. มีแนวโน้มที่จะปรากฏขึ้นอีกครั้งในอนาคตและเข้าใจง่าย
2. มีแนวโน้มที่จะปรากฏอีกครั้งในอนาคต แต่ยากที่จะเข้าใจ
3. ปรากฏขึ้นอีกครั้งในอนาคตและไม่ค่อยเข้าใจ
4. จะปรากฏขึ้นอีกครั้งในอนาคต แต่ไม่ค่อยเข้าใจ

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

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

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

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

แน่นอนคุณควรใส่มัน หรืออย่างน้อยก็รายงานให้คน QA ของคุณทราบว่าเป็นกระบวนการปกติของคุณ

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

แน่นอนคุณควรบันทึกพวกมันไว้ในระบบและในกรณีที่มันไม่ได้ฝึกฝนมันก็เป็นการเริ่มต้นที่ดี

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

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

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

สมมติว่ามีการทดสอบโค้ด (และโดยเฉพาะอย่างยิ่งถ้ามีการเผยแพร่) อย่างแน่นอน

มีสาเหตุหลายประการ:

หน่วยความจำ - ระบบไม่น่าที่จะลืมข้อผิดพลาดจริงๆนักพัฒนาที่ได้รับอาจ

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

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

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

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

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

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

จากประสบการณ์มีเหตุผลสองประการที่นักพัฒนาหลีกเลี่ยงการใช้เครื่องมือ:

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

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

รายการที่ 2 ควรเป็นสัญญาณเตือนภัยที่เป็นประโยชน์ต่อผู้นำการพัฒนาเกี่ยวกับการจัดสรรงานปัจจุบัน

ฉันเห็นด้วยกับ FrustratedWormsDesign เป็นส่วนใหญ่ แต่ฉันคิดว่ามันชัดเจนยิ่งขึ้นถ้าปัญหาทั้งหมดแบ่งออกเป็นสองส่วน:

• รายงานข้อผิดพลาด
• แก้ไขข้อผิดพลาด

สิ่งเหล่านี้มักจะได้รับการปฏิบัติเหมือนกันและแยกพวกเขาเกือบจะช่วยได้มากแน่นอน

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

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

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

หากคุณเห็นบางสิ่งบางอย่างแล้วพูดอะไรบางอย่าง!

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

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

ฉันคิดว่านี่เป็นคำถามทางการเมืองมากกว่าคำถามเกี่ยวกับการปฏิบัติที่ดีที่สุด

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

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

สำหรับกรณีที่ไม่สำคัญคุณไม่ควรแก้ไขปัญหาโดยไม่ปรึกษากับบุคคลอื่นเพื่อให้แน่ใจว่า

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