क्या अन्य लोग बग को देखने के बाद उन्हें ठीक करते हैं, या जब तक कि क्रैश / डेटा लॉस नहीं होता है, तब तक प्रतीक्षा करते हैं / लोग इसे ठीक करने से पहले मर जाते हैं?
उदाहरण 1
Customer customer = null;
...
customer.Save();
कोड स्पष्ट रूप से गलत है, और इसके आसपास कोई रास्ता नहीं है - यह एक विधि को अशक्त संदर्भ पर कॉल कर रहा है। यह दुर्घटना नहीं 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);
भौतिकी जानने वाले लोग यह पहचानेंगे कि यह हर 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();
यह बताता है कि "पैरामीटर्सलेस" कंस्ट्रक्टर वास्तव में इनहेरिटेंस चेन में आगे पीछे से एक पैरामीटराइज्ड कंस्ट्रक्टर है:
public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)
इसे कॉल करना एक गलती है, क्योंकि यह सभी बाद के कंस्ट्रक्टरों को बायपास करता है।
मैं इस तरह के एक खतरनाक निर्माणकर्ता को उजागर नहीं करने के लिए ऑब्जेक्ट का वंश बदल सकता था, लेकिन अब मुझे कोड बदलना होगा:
Customer customer = new Customer(depends);
लेकिन मैं यह गारंटी नहीं दे सकता कि यह परिवर्तन कुछ भी नहीं तोड़ेगा। ऊपर मेरे उदाहरण 1 की तरह , शायद, कोई, कहीं, किसी भी तरह, कुछ गूढ़ शर्तों के तहत, निर्माण Customerपर अवैध और कबाड़ से भरा हुआ निर्भर करता है ।
शायद Customerवस्तु, अब जब यह ठीक से बनाया गया है तो कुछ कोड को चलाने की अनुमति देगा जो पहले कभी नहीं किया था, और अब मुझे एक दुर्घटना मिल सकती है।
मैं इस पर अपनी पत्नी के जीवन को दांव पर नहीं लगा सकता।
और मैं इसका परीक्षण मंगलवार से मंगलवार तक कर सकता हूं, मैं आपकी बेटी के जीवन की कसम नहीं खा सकता हूं कि मैंने प्रतिगमन का परिचय नहीं दिया।
क्या मैं:
- कोड को ठीक करें और इसे तोड़ने के लिए दोषी ठहराया जाए? या
- बग को छोड़ दें, और जब ग्राहक मिल जाए तो उसे दोषी ठहराया जाए?