वास्तव में कोड कितना एक्स्टेंसिबल होना चाहिए?

Question

मैंने अभी एक नया काम शुरू कर दिया है और मेरे नए मालिक ने मुझसे बात की थी कि कोड दीर्घायु थी।

मैंने हमेशा अपना कोड असीम रूप से एक्स्टेंसिबल और अनुकूलनीय बनाने के लिए कोड किया है। मैंने सोचा कि अगर कोई भविष्य में अपना कोड बदलने जा रहा है तो इसे करना आसान होना चाहिए।

लेकिन मुझे वास्तव में भविष्य में कितना दूर होना चाहिए पर स्पष्ट विचार नहीं था।

तो मेरी नई मालिक मुझे भविष्य में अधिक है कि 3 साल में कुछ भी के लिए कोडिंग परेशान करने के लिए नहीं कहा था और उसके तर्क है कि प्रौद्योगिकी परिवर्तन, कार्यक्रमों की समय सीमा समाप्त आदि

पहले तो मैं थोड़े दंग रह गया था और सोचा था कि वह था एक बेकार नौकरी लेकिन जितना अधिक मैं इसके बारे में सोचता हूं उतना ही मैं अवधारणा को गर्म कर रहा हूं।

क्या किसी और के पास इस बात पर कोई राय है कि भविष्य में आपको कितना दूर कोड करना चाहिए?

Answer 1

आपको विनिर्देशों को कोड करना चाहिए, और कुछ भी नहीं, कुछ भी कम नहीं। यदि विनिर्देश 30 वर्षों के लिए प्रावधान करते हैं, तो आप 30 साल के लिए कोड करते हैं। यदि विनिर्देश 3 महीने के प्रावधान देता है, तो यह भी लागू होता है।

बस याद रखें, आपको अपनी खुद की स्वच्छता के लिए भी कोड करना चाहिए। सभी कोड आपके द्वारा बनाए गए 3 चीजें हासिल करना चाहिए:

• कोड बदली होने के लिए - यह मेरी राय में सिर्फ अच्छी आदत है। आपके कोडिंग में जितना अधिक प्रतिस्थापन योग्य होगा, उतना बेहतर कोड जो आप उत्पन्न करेंगे। यह एक विपरीत स्थिति प्रदान करता है - जितना अधिक प्रतिस्थापन योग्य आप अपना कोड बनाते हैं, उतना ही मूल्यवान आप स्वयं बनाते हैं।

• कोड उत्पादक होने का पुन: उपयोग करें, पुन: उपयोग करें, पुन: उपयोग करें।

• कोड अच्छी तरह लिखा जाना चाहिए - यह मुझे चीज को समझाए जाने की आवश्यकता नहीं है।

Answer 2

कोड अच्छी तरह से, और केवल अगले वितरित करने के लिए देखो। अच्छी तरह से लिखित कोड असीम रूप से अपवर्तनीय/एक्स्टेंसिबल है चाहे इसे दिमाग में लिखा गया हो या नहीं। खराब लिखित कोड जो कि एक्स्टेंसिबल होने का मतलब है, शायद ही कभी अभ्यास में है।

Answer 3

आप वास्तव में एक लंबे समय तक चलने कार्यक्रम चाहते हैं, यह सुनिश्चित करें कि अपनी तिथियाँ संभाल कर सकते हैं बनाने के लिए गोली मार अतीत 2038 (है कि अगले "Y2K" है)।

अलग-अलग तिथियां, अब से दस साल के विपरीत अब एक साल के लिए एक कोड कैसे कोड करता है? आप या तो रखरखाव कोड लिखते हैं या आप नहीं करते; आप वास्तव में निर्दिष्ट नहीं कर सकते कि आपका परिवर्तन "समाप्त हो जाता है"।

मैं बहस कर सकते हैं कि उनकी भाषा की अगली मानक विधि Foo का बहिष्कार करेंगे लगता है, लेकिन अगर एक विधि का बहिष्कार किया जा रहा है, जो वास्तव में अधिक कोड गुणवत्ता और रख-रखाव की बात की तुलना में यह भविष्य दिनांकों के लिए कोडिंग कर रहा है ।

Answer 4

यदि आप पत्र में Agile पद्धतियों का पालन कर रहे हैं तो आपको वर्तमान समस्या के लिए कोडिंग करना चाहिए। इसे यागनी (आपको इसकी आवश्यकता नहीं है) सिद्धांत के रूप में भी जाना जाता है।

विचार यह है कि आप नहीं जानते कि कोने के आसपास क्या आ रहा है, इसलिए इसके लिए कोड करने का प्रयास करने में कोई बात नहीं है।

हालांकि, मुझे नहीं लगता कि यह विशेष रूप से समझदार दृष्टिकोण है।

भले ही आप एक एग्इल पर्यावरण में हों, आपको पता है कि आप कोड के नीचे कई पुनरावृत्तियों को करने में सक्षम होना चाहते हैं और इसलिए उसे कोड करना चाहिए।

जबकि कार्यक्रम समाप्त हो जाते हैं और तकनीकों में परिवर्तन होता है यदि आप "हत्यारा" ऐप लिख रहे हैं तो यह 3 साल से अधिक समय तक होगा।

Answer 5

अपने कोड को डिज़ाइन करते समय, आपको संभावित तरीकों को ध्यान में रखना चाहिए कि इसे बढ़ाया जा सकता है या नई कार्यक्षमता की मांग की जा सकती है, और आपको इसे पर्याप्त मॉड्यूलर बनाने का प्रयास करना चाहिए जो नई कार्यक्षमता जोड़ना संभव है। यदि कोई ऐसा बिंदु है जहां एक निर्णय इसे अधिक लचीला या एक्स्टेंसिबल बना देगा, जबकि एक और निर्णय इसे और अधिक कठोर बना देगा, अगर अधिक लचीला होने पर कोई कीमत नहीं है, तो इसके साथ जाने का अर्थ है। हालांकि, अगर अधिक flexibile मार्ग की लागत महत्वपूर्ण है, तो यह मत करो। जब तक आप निश्चित रूप से नहीं जानते कि आपको उस सुविधा की आवश्यकता होगी और लागत उचित है, तो आपको ऐसी कार्यक्षमता जोड़ने की कोशिश में पागल नहीं होना चाहिए; यदि आप करते हैं, तो आप शायद कुछ भी नहीं के लिए बहुत खर्च करेंगे।

Answer 6

जब भी मैं कुछ कोडिंग कर रहा हूँ, मैं अपने आप को पूछना ...

यह आवश्यक है? अगर आपको इसकी आवश्यकता नहीं है, तो आप इसे क्यों कोड कर रहे हैं?

मुझे लगता है कि यह मुझे अनावश्यक कोड जोड़ने में मदद करता है। अनावश्यक कोड एक नाली है। इसमें अन्य गतिविधियों से समय लगता है। यह कोड आकार और जटिलता में जोड़ता है। यह परियोजना में $$$ जोड़ता है - खासकर यदि कोड बेस को प्रमाणन प्रक्रिया के माध्यम से जाना है।

Answer 7

निर्णय लेने के लिए कठिन निर्णय में से एक यह है कि कितना एक्स्टेंसिबल होना चाहिए। बॉस के रूप में, मैं वास्तव में परेशान हूं जब मैं किसी को 2 घंटे का कार्य सौंपा जाता हूं और तीन दिन बाद भी वे इस पर काम कर रहे हैं, क्योंकि उन्होंने फैसला किया कि यह अधिक विस्तार योग्य होना चाहिए ताकि उन्होंने कॉन्फ़िगरेशन फ़ाइल और कॉलम में टेबल और टेबल पर प्रविष्टियां जोड़ दी हों इसे समायोजित करने के लिए 4 या 5 अन्य ऑब्जेक्ट्स को बदलने के लिए और अब इंस्टॉल डॉक पुराना है और तैनाती स्क्रिप्ट को बदलना है और परीक्षक को सभी संयोजनों और क्रमपरिवर्तनों का प्रयास करने में एक या दो दिन लगाना पड़ता है ताकि हम जान सकें कि कोड है यहां तक ​​कि काम कर रहा है। लेकिन मैं भी वास्तव में परेशान हूं जब किसी और ने दो घंटे के कार्य को दिया है, यह सब कुछ कड़ी मेहनत करके आधे घंटे के कार्य में बदल जाता है, यहां तक ​​कि वह ईमेल पता भी भेजता है, और यह समझ में नहीं आता कि बाकी टीम शिकायत करती है।

यदि कोई आसान कठिन और तेज़ नियम था, तो हर दिन एक वरिष्ठ प्रोग्रामर हो सकता है जिस दिन वे पहले कुछ कोड संकलित करते हैं। यह अनुभव और निर्णय लेता है और यह शायद आपके द्वारा हासिल किया जाने वाला सबसे महत्वपूर्ण निर्णय है। और आप जानते हैं कि आपको अच्छा निर्णय कैसे मिलता है? अनुभव। और आप जानते हैं कि आपको अनुभव कैसे मिलता है? बुरा निर्णय