असमर्थित सॉफ्टवेयर कैसे विकसित करें

वे मुझे किसी और के तकनीकी ऋण को चुकाने के लिए भुगतान करते हैं। मेरे काम में, मुझे बहुत मुश्किल कोड समर्थन दिखाई देता है, और मैं बार-बार कई समस्याओं को देखता हूं जिनसे बचा जा सकता था।

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

कोड लिखते समय, प्रोग्रामर अक्सर गलत सवाल पूछते हैं जब वे आगे कोड समर्थन के बारे में बात करते हैं - मैट ड्यूवेल का "मिथक ऑफ़ सपोर्ट" लेख देखें कि यह कैसे होता है। नीचे कुछ अभ्यास दिए गए हैं जिन्हें आपको अपनी परियोजनाओं में पालन करने की आवश्यकता है ताकि मुझे बिना काम के न छोड़ें:

संस्करण नियंत्रण प्रणाली का उपयोग न करें

मुझे हमेशा आश्चर्य होता है जब मैं पिछले कुछ वर्षों में बिना किसी संस्करण नियंत्रण प्रणाली के लिखे बड़ी परियोजनाओं पर आता हूं। जब आप संस्करण नियंत्रण का उपयोग नहीं कर रहे हैं, तो अगले प्रोग्रामर को यह पता लगाना होगा कि कौन सी फाइलें वर्तमान प्रणाली का हिस्सा हैं और जो पुरानी या बैकअप हैं। अगले प्रोग्रामर को कोड इतिहास प्राप्त करने के लिए एक भी प्रतिबद्ध संदेश या चैंज नहीं होगा। मैंने अपने लेख "डैमेज्ड-ओरिएंटेड प्रोग्रामिंग का परिचय" में संस्करण नियंत्रण प्रणालियों का उपयोग नहीं करने के बारे में बात की।

अपने विकास के माहौल को अनुकूलित करें। जितना मजबूत हो सके।

निम्नलिखित डेवलपर्स के लिए कोड के साथ आरंभ करना आसान न बनाएं। भाषाओं और उपयोगिताओं के विशिष्ट संस्करणों की आवश्यकता होती है, और सुनिश्चित करें कि वे उन संस्करणों के साथ संघर्ष करते हैं जो ऑपरेटिंग सिस्टम के साथ आते हैं। एक्लिप्स या विज़ुअल स्टूडियो को सेट करें, या पागलों की तरह देखें, फिर मैक्रोज़ और स्क्रिप्ट लिखें जो केवल इस वातावरण के साथ काम करते हैं। अपने विकास के वातावरण की प्रतिकृति के लिए एक डिस्क छवि या स्क्रिप्ट को संग्रहीत न करें, प्रलेखन लिखने के बारे में चिंता न करें - वैसे भी सब कुछ सहज होगा।

सबसे जटिल निर्माण और परिनियोजन प्रणाली बनाएँ

एक वेबसाइट के लिए, एक परीक्षण या युद्ध सर्वर पर तैनाती इनमें से एक होनी चाहिए:

svn up git pull hg pull 

प्रोग्रामर कोड की सादगी और लालित्य के बारे में बहस कर सकते हैं, और फिर तेजी से तैनात और सबसे जटिल और विचित्र निर्माण और तैनाती प्रणालियों का निर्माण कर सकते हैं। यह उन अनट्रेसेबल चीजों में से एक है जो प्रोग्रामर क्लाइंट या पीएम (या उन्हें समझे बिना) की निगरानी के बिना करते हैं, इसलिए यह आसानी से नियंत्रण से बाहर हो जाता है। जब आप विभिन्न स्क्रिप्टिंग भाषाओं के साथ आठ अलग-अलग उपकरणों की श्रृंखला बनाते हैं, तो दस्तावेज़ीकरण करने के बारे में भी न सोचें।

टेस्ट / इंटरमीडिएट सिस्टम को तैनात न करें

मुकाबला प्रणाली पर परिवर्तन रोमांचक है! एक परीक्षण / मध्यवर्ती सर्वर के बारे में मत सोचो। इसके बजाय, नई सुविधाओं का परीक्षण करने के लिए गुप्त लॉगिन और गुप्त URL का उपयोग करें। अपने डेटाबेस में वास्तविक डेटा के साथ परीक्षण डेटा मिलाएं। चूंकि आप कोड नियंत्रण का उपयोग नहीं कर रहे हैं, इसलिए पिछले संस्करणों की प्रतियाँ केवल मामले में रखें। कोड में लॉगिंग एम्बेड न करें। परीक्षण के दौरान निवर्तमान ई-मेल, क्रेडिट कार्ड प्राधिकरण आदि को अक्षम न करें।

सब कुछ खरोंच से लिखें

Django, रेल, या CakePHP जैसे प्रसिद्ध ढांचे के साथ गड़बड़ न करें। आप एक बेहतर टेम्पलेट इंजन, ORM, सॉर्ट या हैश एल्गोरिथम लिख सकते हैं। मैं हर बार अपने सिर के पीछे खरोंच करता हूं, मुझे "मूल विधि से तेज" या "PHP लाइब्रेरी फ़ंक्शन को प्रतिस्थापित करने" जैसी टिप्पणियां दिखाई देती हैं, क्योंकि मापदंडों का क्रम बेकार है।

पुस्तकालयों और संसाधनों के विशिष्ट संस्करणों पर निर्भरता जोड़ें ...

जितना हो सके थर्ड-पार्टी कोड जोड़ें। जितनी जरूरत हो उतने डायनामिक लाइब्रेरी से लिंक करें। मैंने कोड को बाहरी बाहरी पुस्तकालयों के आधार पर देखा, केवल एक फ़ंक्शन तक पहुंचने के लिए। तृतीय-पक्ष पुस्तकालयों के स्रोत कोड को संशोधित करें ताकि वे स्वचालित रूप से नवीनतम संस्करणों में अपडेट न हो सकें, लेकिन संस्करण नियंत्रण के तहत अपने संशोधित संस्करणों को ब्रांच करने या रखने की चिंता न करें। मैं मूल संस्करण के साथ आपके संस्करण की तुलना कर सकता हूं और इसका पता लगा सकता हूं।

... लेकिन इन निर्भरताओं की रक्षा या दस्तावेज़ न करें।

मुझे किसी भी कारण से अपडेट और अपग्रेड के कारण महत्वपूर्ण कॉल प्राप्त होते हैं। वर्डप्रेस का प्रतीत होता है सहज अद्यतन, लिनक्स अपडेट या नया jQuery रिलीज क्रैश की एक श्रृंखला प्रतिक्रिया का कारण बनता है। एक विशिष्ट संस्करण या अपने बाहरी संसाधनों या तीसरे पक्ष के पुस्तकालयों के एक संशोधित संस्करण के लिए अपने कोड में जाँच न करें। खुद को याद दिलाने के लिए एक टिप्पणी भी न करें।

विभिन्न प्रोग्रामिंग भाषाओं के एक समूह का उपयोग करें और अत्याधुनिक रहें

हर दिन, हैकरन्यूज और रेडिट नई शांत भाषाओं के बारे में चर्चा करते हैं। क्लाइंट की कीमत पर उन्हें आज़माएं। कोई भी सभ्य प्रोग्रामर कुछ ही समय में एक नई भाषा सीख सकता है, इसलिए यदि आपके कोड के साथ काम करने वाला अगला प्रोग्रामर नॉब बन जाता है, तो यह आपकी समस्या नहीं है। भाषाओं, असंगत एपीआई और डेटा प्रारूपों के बीच अंतर, विभिन्न सर्वर कॉन्फ़िगरेशन आवश्यकताओं मजेदार रोमांच और StackOverflow पर पोस्ट हैं। मैंने वास्तव में रूबी में आवेषण के साथ PHP वेबसाइटों को देखा, क्योंकि हर कोई जानता है कि रूबी शांत है और PHP बेकार है। अर्ध-प्रशिक्षित कैशिंग, रेल और नोड.जेएस परियोजनाएं और विशेष रूप से NoSQL समाधान ("वे बेहतर पैमाने!") मेरी रोटी और मक्खन है।

प्रोग्रामिंग युक्तियाँ कहाँ हैं?

यदि आपका कोड पूरी तरह से ऑब्जेक्ट ओरिएंटेड या शानदार और कार्यात्मक है, तो यह ध्यान देने योग्य नहीं है - क्योंकि प्रोग्रामर लगभग हमेशा स्पैगेटी कोड देखते हैं, जिनका उन्हें समर्थन करने की आवश्यकता होती है। मैं अंतर, grep और Ctags, कोड ट्रेसिंग, रीफैक्टरिंग और डीबगिंग का उपयोग करने में अच्छा हूं। मैं कोड समझता हूं। यदि कोई परीक्षण / मध्यवर्ती प्रणाली नहीं है, तो बहुत अधिक निर्भरता और सेटिंग्स होने पर, संस्करण नियंत्रण प्रणाली न होने पर, सबसे सुंदर, सुरुचिपूर्ण कोड के साथ काम करना अभी भी मुश्किल है। यह होर्डर्स हाउस में एक साफ और प्यारा सजा हुआ कमरा खोजने जैसा है।