แก้ไขข้อบกพร่องหรือรอให้ลูกค้าค้นหาพวกเขา


35

คนอื่น ๆ แก้ไขข้อผิดพลาดเมื่อพวกเขาเห็นพวกเขาหรือพวกเขารอจนกว่าจะมีข้อผิดพลาด / การสูญเสียข้อมูล / คนตายก่อนที่จะแก้ไขหรือไม่

ตัวอย่างที่ 1

 Customer customer = null;
 ...
 customer.Save();

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

แต่ก็ยังไม่ได้นึกไม่ถึงว่าการแก้ไขรหัส:

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

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

ตัวอย่างที่ 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

คนที่รู้เรื่องฟิสิกส์จะรับรู้ว่ามันควรจะเป็น R 2ในตัวส่วน

รหัสผิดมันผิดอย่างแน่นอน และการประเมินความเร็วที่มากเกินไปจะทำให้จรวดย้อนยุคยิงเร็วเกินไปและฆ่าผู้ที่อยู่ในยานอวกาศทุกคน

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

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

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

ตัวอย่างที่ 3

นี่คือตัวอย่างที่ฉันมีเมื่อเร็ว ๆ นี้ตรวจสอบว่าสตริงมีอักขระที่ไม่ถูกต้องหรือไม่:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

เกิดอะไรขึ้นถ้ามีข้อผิดพลาดในDo somethingสาขา? แก้ไขรหัสที่ไม่ถูกต้องชัดเจน:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

แก้ไขรหัส แต่แนะนำข้อบกพร่อง


วิธีที่ฉันเห็นมันมีความเป็นไปได้สองอย่าง:

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

คุณทำอะไรในทางการเมือง


ตัวอย่างที่ 4 - บั๊กโลกแห่งความจริงในวันนี้

ฉันกำลังสร้างวัตถุ แต่เรียกตัวสร้างผิด:

Customer customer = new Customer();

กลับกลายเป็นว่าคอนสตรัค "parameterless" เป็นคอนสตรัคเตอร์แบบแปรสภาพจากการย้อนกลับไปในห่วงโซ่การสืบทอด:

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

การเรียกมันเป็นความผิดพลาดเพราะมันข้ามตัวสร้างที่ตามมาทั้งหมด

ฉันสามารถเปลี่ยนสายเลือดของวัตถุเพื่อไม่ให้มีตัวสร้างที่เป็นอันตราย แต่ตอนนี้ฉันต้องเปลี่ยนรหัสเป็น:

Customer customer = new Customer(depends);

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

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

ฉันเดิมพันชีวิตภรรยาของคุณไม่ได้

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

ฉัน:

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

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

3
เป็นคำถามที่ได้รับการวิจัยอย่างดี
Muhammad Alkarouri

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

2
'ทำ [คุณ] รอจนกว่าผู้คนจะตายก่อนที่จะแก้ไข'! วัวศักดิ์สิทธิ์ฉันอย่างจริงจังหวังว่าจะมีเพียงหนึ่งคำตอบนี้ ...
คริสอัศวิน

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

คำตอบ:


34

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

ถ้าฉันจะให้แนวทางทั่วไปในการกำหนดสิ่งที่ฉันควรทำฉันคิดว่ามันจะเป็นแบบนี้:

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

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


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

6
+1 สำหรับบันทึกข้อบกพร่อง ข้อบกพร่องอื่น ๆ อาจมีลำดับความสำคัญ ...
6652 SHug

35

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

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


2
นั่นเป็นความจริงที่น่าเศร้า เราต้องส่งมอบโครงการที่เราทดสอบอย่างบ้าคลั่งและลูกค้าก็สามารถจัดการมันได้ภายใน 3 นาที
Oliver Weiler

4
@Helper วิธีการ: บางทีถ้าคุณได้ทดสอบมันเหมือนคนมีเหตุผลมันจะดีกว่านี้
Vinko Vrsalovic

@Helper วิธีการ: แม้ว่าจะจริงจังมากขึ้นถ้ามันเป็นสามนาทีจริงๆนี้ดูเหมือนว่าผู้ทดสอบไม่ทราบว่ากรณีการใช้งานจริงที่คาดหวังจากลูกค้าคืออะไร
Vinko Vrsalovic

8
วิธี @Helper: ทำให้ลูกค้ามีส่วนร่วมในการทดสอบ (สมมติว่าลูกค้า == ลูกค้า) นักพัฒนาที่เขียนและทดสอบรหัสเป็นปัญหาที่นักพัฒนาไม่ได้ใช้ซอฟต์แวร์ในลักษณะเดียวกัน นักพัฒนามีความอ่อนโยน มันเป็นงานของพวกเขา - งานศิลปะของพวกเขา: ลูกค้าตีมันเหมือนลิงใน panio เมื่อเป็นไปได้ให้แบ่งปันความพยายามในการทดสอบและแบ่งปันความรับผิดชอบ สิ่งนี้ไม่เหมาะกับสภาพแวดล้อมทุกประการ แต่การทำงานกับลูกค้าเป็นทีมไม่แนะนำให้นำซอฟต์แวร์ที่ดีกว่ามาใช้
brian chandley

เอ่อแย่ลงไหม (ฟิลเลอร์)
สวัสดี 71

24

แก้ไขข้อบกพร่อง

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

อย่าสับสนในเรื่องการปรับโครงสร้างใหม่หรือทำการปรับปรุงประสิทธิภาพที่ไม่เกี่ยวข้องกับข้อบกพร่องด้านประสิทธิภาพ

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


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

21

ลูกค้าจะพูดอะไร

นี่คือวิธีที่ฉันจินตนาการการเล่นนี้:

ลูกค้า:มันล้มเหลวเมื่อฉันทำ x

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

ลูกค้า: [เอื้อมไปหาวัตถุทื่อ]

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

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


8

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

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

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


7

เริ่มต้นการแกะออกไปที่หนี้ทางเทคนิคของคุณโดยเร็วที่สุดเท่าที่คุณสามารถ

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

ในตัวอย่างที่ 1 หากSave()ไม่ได้เข้าถึงข้อมูลอินสแตนซ์ใด ๆ ข้อมูลลูกค้าใดที่บันทึกอย่างถูกต้อง เริ่มแก้ไขและทดสอบว่า

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

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

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


5

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

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

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

วิธีแก้ปัญหานี้คือสองเท่า:

  1. ทำรหัสและโครงสร้างให้ได้มากที่สุด
  2. เมื่อรหัสถูกแยกพอที่คุณรู้ว่าไม่มีอะไรจะทำลายให้แก้ไข

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

ขั้นตอนที่สองคือคุณแก้ไขข้อผิดพลาด

บางประเด็นเกี่ยวข้องกัน:

  1. การควบคุมเวอร์ชันเป็นสิ่งจำเป็นอย่างยิ่งสำหรับกระบวนการนี้
  2. ขั้นตอนการปรับโครงสร้างใหม่และขั้นตอนการแก้ไขข้อผิดพลาดมีความมุ่งมั่นที่ดีกว่าในการควบคุมเวอร์ชันโดยแยกกันดังนั้นแต่ละคนมีหน้าที่การทำงานที่ผ่านมาที่กำหนดไว้อย่างดี
  3. อย่าจับจ้องที่ความเป็นไปได้ในการสร้างข้อผิดพลาดอื่นคุณจะไม่ทำอะไรเลย แต่ลองคิดว่าการทำให้โค้ดของคุณดีขึ้น กล่าวอีกนัยหนึ่งถ้าคุณไม่ทราบว่าคุณกำลังเพิ่มข้อบกพร่องมากกว่าที่จะลดพวกเขาแล้วคุณควรทำมัน
  4. เกี่ยวข้องกับประเด็นสุดท้าย: อย่าพยายามทำนายอนาคต มนุษย์มีอคติที่จะคิดว่าพวกเขาเก่งในการทำนาย ในความเป็นจริงพลังการทำนายของเรานั้นสั้น ดังนั้นไม่ต้องกังวลเกี่ยวกับข้อบกพร่องในอนาคตที่คลุมเครือไม่ได้กำหนด และนี่ก็เป็นหลักการที่อยู่เบื้องหลังYAGNI
  5. เครื่องมือที่สอดคล้องกับการควบคุมเวอร์ชันในโลกข้อผิดพลาดเป็นบั๊ก คุณจะต้องการเช่นกัน
  6. คุณจำเป็นต้องแก้ไขข้อบกพร่องด้วยเหตุผลสองประการ: เพื่อตอบสนองลูกค้า; และเพื่อให้สามารถพัฒนาในการพัฒนาของคุณ ในการใช้ตัวอย่าง 3 (ฟิสิกส์หนึ่ง): หากโปรแกรมตรงตามความต้องการของลูกค้าด้วยสมการที่แตกสลายนั้นมีส่วนอื่น ๆ ของซอฟต์แวร์ที่พัฒนาขึ้นอย่างไม่ถูกต้องเพื่อบรรเทาข้อผิดพลาดนี้ (ตัวอย่างเช่นการปรับใช้ถุงลมนิรภัย) หากจำเป็นต้องใช้เวอร์ชัน 2 (หรือ 1.1) สำหรับซอฟต์แวร์นี้คุณจะพบว่ามันยากมากที่จะพัฒนารหัสที่ถูกต้องตามข้อผิดพลาดนี้ จากนั้นคุณจะมุ่งหน้าไปที่การเขียนครั้งใหญ่หรือความล้มเหลวครั้งยิ่งใหญ่ ทั้งสองอย่างที่คุณควรหลีกเลี่ยง

นี่เป็นคะแนนมากกว่าสองสามคะแนนดังนั้นฉันเดาว่าฉันจะหยุดที่นี่


3

คุณต้องพิจารณาคำจำกัดความของบั๊กก่อน:

  1. รหัสที่อ่านไม่ตรงกับสิ่งที่คุณคิดว่าถูกต้อง
  2. ซอฟต์แวร์ทำงานอย่างไม่ถูกต้อง

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

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


2

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

มีสถานการณ์ที่เป็นไปได้มากกว่าข้อบกพร่องที่ถูกต้องในกรณีที่คุณกล่าวถึง:

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

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


1
หากคุณต้องการจ้างนักพัฒนาที่ไม่ได้ใช้วิจารณญาณของตัวเองมีหลายคนที่อยู่ตรงกลางสำหรับคุณ คุณจะมีปัญหาในการว่าจ้างคนดี ๆ ที่มีความมั่นใจในความสามารถของตนเอง
David Thornley

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

2

ฉัน:

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

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

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


1
หรือถ้าคุณใช้การเช็คอินแบบ gated ให้ตั้งค่านั้นดังนั้นคุณจึงไม่ต้องเช็คอินรหัสที่ใช้งานไม่ได้
อดัมเลียร์

3
ใช้เวลานานไม่มีข้อแก้ตัวที่จะส่งรหัสผิดพลาด
Toby

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

1

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

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

สังเกตว่าโครงการซอฟต์แวร์ที่ใหญ่กว่าทุกโครงการมีหัวข้อ 'ปัญหาที่ทราบ' ใน ReadMe ซึ่งมักแสดงรายการอย่างชัดเจนว่า: ข้อบกพร่องที่เป็นที่รู้จัก

การรู้จักบักและไม่สื่อสารมันเป็น IMHO ที่ยอมรับได้สำหรับบั๊กเล็กน้อย / สมมาตรจริงๆเท่านั้น


1

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

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


0

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

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


0

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

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

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

  • ใช้ : รหัสอะไรใช้รหัสผิดพลาด? แล้วยังไง? รหัสหมดอายุหรือไม่ มีรหัสอื่นที่ขึ้นอยู่กับพฤติกรรมที่ผิดพลาดหรือไม่?

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.