गलती से भार संभालने वाला

• Chesterton's fence किसी चीज़ को बदलने से पहले उसके उद्देश्य को समझने की एक अवधारणा है।
• यह अवधारणा जटिल कंप्यूटर सिस्टम में किए जाने वाले बदलावों पर लागू होती है।
• Microsoft के पास पुराने software versions के साथ compatibility सुनिश्चित करने के लिए सिस्टम मौजूद हैं।
• software systems में छोटा-सा बदलाव भी अनचाहे परिणाम ला सकता है।
• code और उसके उद्देश्य को समझने के लिए software development में documentation महत्वपूर्ण है।
• यह लेख code बदलते समय सावधानी और इरादतन दृष्टिकोण की आवश्यकता पर ज़ोर देता है।
• बदलाव के प्रभाव को समझने के लिए thorough testing और experiments महत्वपूर्ण हैं।
• software development में गैर-पारंपरिक तरीकों का उपयोग करने के लिए context और परिणामों को समझना चाहिए।
• problem solving और maintenance के लिए code decisions के "क्यों" को समझना महत्वपूर्ण है।
• code के कारणों की व्याख्या और जटिल परिस्थितियों को संभालने में comments और documentation महत्वपूर्ण भूमिका निभाते हैं।
• code पर काम करते समय साथियों और उनके decision-making process पर भरोसा करना महत्वपूर्ण है।
• Chesterton's fence का सिद्धांत software development पर लागू होता है, और बदलाव से पहले मौजूदा code को समझना महत्वपूर्ण है।
• industrial equipment में PLC code बदलने से पहले उपकरण और process को समझना चाहिए।
• industrial sector में electrical/mechanical engineers और software engineers के बीच सांस्कृतिक अंतर है।
• industrial sector में बेहतर software development methodologies की आवश्यकता है।
• PLC कार्य में documentation स्पष्टता देने और प्रश्नों के उत्तर देने के लिए महत्वपूर्ण है।
• software बदलावों के अनचाहे परिणामों को समझना और thorough testing करना महत्वपूर्ण है।
• code के maintenance और modification के लिए स्पष्ट documentation और कारण महत्वपूर्ण हैं।
• केवल testing, formal specifications और system की गहरी समझ का विकल्प नहीं हो सकती।
• testing और पर्याप्त funding के साथ की गई quality assurance भी organizational problems से software projects को हमेशा नहीं बचा सकती।
• deployment से पहले समस्याएँ पकड़ना और thorough testing software development में महत्वपूर्ण हैं।
• software में जो बदलाव गलती से भार संभालने लगते हैं, उन्हें ठीक करना उन्हें बनाने से अधिक कठिन हो सकता है।
• DiRT exercises undocumented implementation details पर निर्भरता को रोक सकते हैं।
• software projects को समझने के लिए automated approach व्यवहार्य हो सकती है।
• construction projects में जब एक व्यक्ति परवाह करता है और दूसरा नहीं, तो quality गिर सकती है।

[GN⁺]

Hacker News की राय

• control system support का काम करते समय अक्सर ऐसा code मिलता है जो अनजाने में समस्याएँ पैदा कर रहा होता है।
• बदलाव करने से पहले मौजूदा code के उद्देश्य को समझना महत्वपूर्ण है।
• testing की कमी software development में एक बड़ी समस्या है।
• अच्छी testing software archaeology और दूसरे workaround की ज़रूरत को खत्म कर सकती है।
• गैर-महत्वपूर्ण elements का load संभालना lazy design का संकेत हो सकता है।
• अत्यधिक जटिल systems ऐसे अनदेखे मुद्दे पैदा कर सकते हैं और बदलाव करने का डर बना सकते हैं।
• code के भीतर documentation इरादे को स्पष्ट कर सकती है।
• users अनजाने में software bugs का फायदा उठा सकते हैं, और जब उन्हें ठीक किया जाता है तो उन्हें परेशानी हो सकती है।