विकास को धीमा करने के लिए

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

मुख्य बिंदु:

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

यदि आप अनियंत्रित रूप से विकास में संलग्न हैं, तो कार्यों का सबसे तेज़ संभव निष्पादन आपका दुश्मन बन सकता है। लोगों को धीमा करने के लिए तीन महत्वपूर्ण क्षेत्र हैं: प्रक्रिया, और उत्पाद। विवरण में गोता लगाने से पहले, मैं आपको एक कहानी बताता हूं।

जहां तक ​​मुझे याद है, यह 2011 था। मैं उस टीम में शामिल हो गया जिसने ऑनलाइन मार्केटिंग के लिए प्लेटफॉर्म बनाया। मेरा मुख्य कार्य नई सुविधाओं को जितनी जल्दी हो सके जोड़ना था। मैं एक वरिष्ठ डेवलपर था। हम डेवलपर्स को "वरिष्ठ" कहते हैं जब वे दूसरों की तुलना में तेजी से विकसित होते हैं, है ना? हालांकि, जब मैंने काम करना शुरू किया, तो हमने देखा कि सिस्टम के डिजाइन में तकनीकी ऋण और खामियों के कारण जल्दी से काम करना लगभग असंभव था। हमने यह भी देखा कि तेजी लाने के प्रत्येक प्रयास के साथ, हम जटिलता बढ़ाते हैं और गुणवत्ता को नष्ट करते हैं। मैं इस नतीजे पर पहुंचा कि तेजी लाने का एकमात्र तरीका यह है कि सिस्टम को खरोंच से फिर से लिखना।

मुझे याद है कि उत्पाद प्रबंधक के साथ टेलीफोन पर बातचीत के दौरान मैंने कहा कि हमें पूरी प्रणाली को फिर से लिखने की जरूरत है। 30 सेकंड की चुप्पी के बाद, प्रबंधक ने पूछा: "आप कहते हैं कि आपकी टीम ने ऐसी खराब गुणवत्ता का उत्पाद विकसित किया है कि अब उसी टीम को फिर से उसी उत्पाद को फिर से लिखना चाहिए, लेकिन इस बार ऐसा करना बेहतर है। है न? क्षमा करें, लेकिन यह अस्वीकार्य है। आपको इसे तुरंत बेहतर लिखना चाहिए था। ”

ज़ोंबी सॉफ्टवेयर को फिर से लिखने की जरूरत है

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

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

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

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

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

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

रॉबर्ट सी। मार्टिन ने अपने ट्विटर पर विरासत प्रणालियों के बारे में महान बात की : "यदि आपका सॉफ़्टवेयर विकसित करने के लिए कठिन और कठिन है, तो आप कुछ गलत कर रहे हैं।" जल्दी में काम करते हुए, हम गुणवत्ता को कम कर रहे हैं कि प्रत्येक कदम के साथ, काम अधिक से अधिक धीमा हो जाता है। मुझे यकीन है कि तेजी से विकसित होने का एकमात्र तरीका प्रक्रिया को धीमा करना है जब तक हम स्थिरता प्राप्त नहीं करते।

सॉफ्टवेयर विकास में जल्दबाजी बुराई है

CleanCoders श्रृंखला में, रॉबर्ट सी। मार्टिन ने कहा : "सॉफ़्टवेयर का मुख्य मूल्य सिस्टम की क्षमता है जो भविष्य में होने वाले परिवर्तनों के अनुकूल है और उनके कार्यान्वयन को सरल बनाता है।" सॉफ्टवेयर विकास में जल्दबाजी बुराई है। जल्दी करने के किसी भी प्रयास से उत्पादकता, फ़ोकस, लोगों की प्रभावशीलता, परिवर्तनों के प्रति अनुकूलनशीलता और सॉफ़्टवेयर लचीलेपन में गंभीर गिरावट आएगी।

उदाहरण के लिए, हमारे पास हमेशा कीड़े को ठीक करने का समय होता है, लेकिन परीक्षण लिखने का समय नहीं होता है। हम रिफ्लेक्टर या परीक्षण नहीं लिखते हैं क्योंकि हमारे पास बहुत कम समय है। लेकिन हमारे पास हमेशा डिबग करने, बैसाखी में गाड़ी चलाने और बग को ठीक करने का समय होता है।

हम इस प्रक्रिया पर इतने केंद्रित हैं कि हम अक्सर सॉफ्टवेयर विकास के लिए सबसे मूल्यवान लोगों के बारे में भूल जाते हैं। प्रक्रियाएं लोगों को बेहतर उत्पाद बनाने, प्रेरणा बढ़ाने और एक स्वस्थ कार्य वातावरण बनाने में मदद करती हैं। अंततः, प्रक्रिया दक्षता महत्वपूर्ण है, लेकिन लोगों की तुलना में अधिक मूल्यवान कुछ भी नहीं है।

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

• लोग - बढ़ती व्यावसायिकता और कौशल,
• प्रक्रिया लचीलापन और दक्षता में सुधार कर रही है,
• उत्पाद - गुणवत्ता में सुधार और स्वचालन।

लोगों की बात आने पर इसे धीमा कहां करें

प्रक्रियाएं और उपकरण एक उत्पाद नहीं बनाते हैं। लोग करते हैं। यह पहचानने योग्य है कि "हायरिंग टैलेंट" कंपनी का सबसे महत्वपूर्ण कार्य है, जिसका कंपनी के भविष्य पर सीधा प्रभाव पड़ता है और विशेष रूप से उत्पाद का निर्माण किया जाता है।

अपने संगठन में सबसे अधिक प्रतिभाशाली हैं। "सबसे" कहकर, मेरा मतलब सबसे चतुर और सबसे अनुभवी नहीं है। मैं कम से कम उत्साही, अनुशासित और प्रेरित हूं। यदि किसी व्यक्ति में ये तीन गुण हैं, तो वह आसानी से अपनी प्रतिभा का विकास करेगा।

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

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

अकेले काम करना बंद करें, साथ काम करें। टीम में विखंडन की अनुमति न दें। लोन्सर्स और हीरो डेवलपर्स एक बेकार संगठन का संकेत हैं। पास बैठो। पूरी टीम के साथ मानक तय करें। जोड़े या समूहों में काम करें; एक साथ समीक्षा करें। प्रक्रिया में सभी प्रतिभागियों को परिणाम के लिए जिम्मेदार होने की अनुमति दें।

एक साथ अभ्यास करना आपके कौशल को उन्नत करने का सबसे प्रभावी तरीका है। बातचीत करके, हम न केवल अन्य लोगों को प्रेरित करते हैं, बल्कि एक-दूसरे से सीखते हैं। अपनी पूरी टीम के साथ नियमित रूप से कोड रिट्रीट , कोडिंग डोज और रंडोरी चलाएं । हर दिन 30 मिनट सिर्फ अभ्यास में बिताएं।

लोगों में ज्ञान फैलाने दें। एक साथ जानें। मैंने 2010 के बाद से सभी टीमों के साथ ब्राउन बैग / लंच और लर्न सत्र आयोजित किए। दो बार मैंने अपने सहयोगियों से सुना: "बुधवार के सत्र में भाग लेने से मुझे पंप करने की अनुमति मिलती है, और यह मुझे बहुत प्रेरित करता है।" यह नियमित आंतरिक माइटैप्स रखने के लाभों को स्पष्ट रूप से दर्शाता है।

प्रतिक्रिया दें और दूसरों को दें। सामूहिक प्रतिक्रिया एकत्र करने के लिए, एक महान पूर्वव्यापी व्यवस्था करें। मैं एक साल से अधिक समय से ऐसा कर रहा हूं। वैसे, 20 या अधिक लोगों के समूह के साथ समस्या को सुलझाने में खुद को विसर्जित करने का यह एक शानदार तरीका है।

दूसरों को सिखाना और ज्ञान बांटना महारत हासिल करने का सबसे अच्छा तरीका है। सार्वजनिक रूप से बोलें और समुदाय में योगदान दें।

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

तुम बच्चे नहीं हो। संगठन आपके माता-पिता नहीं हैं। सभी को स्वतंत्र रूप से अपने करियर का प्रबंधन करना चाहिए और खुद में निवेश करना चाहिए। यदि आपके योगदान में समय या पैसा बर्बाद करना शामिल है, तो इसे अपने लिए करें।

प्रक्रिया को धीमा और सुधार कैसे करें

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

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

छोटे और दीर्घकालिक लक्ष्यों को परिभाषित करें। अल्पकालिक लक्ष्य टीम के लिए ध्यान केंद्रित करते हैं, दीर्घकालिक लक्ष्य इसकी हानि को रोकते हैं।

यदि आप यह समझना चाहते हैं कि कुछ गलत क्यों हो रहा है, तो तकनीकी और संगठनात्मक दृष्टिकोण से, कार्य प्रवाह की कल्पना करें। पहले हाथ से सीखने को अधिकतम करने के लिए गलतियों और विफलताओं की कल्पना करें।

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

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

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

आप सिस्टम विकास चक्र के किसी भी बिंदु पर कचरे की खोज कर सकते हैं। तत्परता के लिए स्पष्ट रूप से परिभाषित मानदंड का पालन करें (काम की परिभाषा) और "90% समाप्त, 90% शेष" की भावना में कार्यों को समाप्त करें।

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

उत्पाद की गुणवत्ता कैसे सुधर सकती है

एक बात सुनिश्चित है - उच्च-गुणवत्ता कोड आधार के बिना, आप लचीले नहीं हो सकते, क्षमा करें। पहली बात यह है कि तकनीकी ऋण को खत्म करना और त्रुटियों को ठीक करना। यदि आवश्यक हो, तो नई सुविधाओं के विकास को रोकें और बग को ठीक करने पर ध्यान केंद्रित करें।

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

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

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

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

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

मैं सालों से टीडीडी का उपयोग कर रहा हूं। अक्सर लोग मुझसे शिकायत करते हैं कि टीडीडी विकास गति को नकारात्मक रूप से प्रभावित करता है। जो रेन्सबर्गर ने ट्विटर पर TDD पर अपने विचार साझा किए : “ क्या आप चिंतित हैं कि TDD आपके प्रोग्रामर को धीमा कर देगा? कोई जरूरत नहीं उन्हें शायद धीमा करने की जरूरत है। ”

टीडीडी परीक्षण की तुलना में अधिक refactoring है; कोडिंग से अधिक सोचा गया; लालित्य की तुलना में अधिक सरलता। यही कारण है कि टीडीडी उच्च गुणवत्ता की ओर जाता है। टीडीडी का उपयोग करते समय, आपके पास केवल न्यूनतम पर्याप्त संख्या में परीक्षण और एक सरल डिजाइन होगा।

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

यदि 30 मिनट या उससे कम समय लगता है, तो तुरंत त्रुटियों को ठीक करें। इसके अतिरिक्त, तकनीकी ऋण को खत्म करने के लिए 20% समय का उपयोग करें।

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

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

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

जीवन के लिए एक दृष्टिकोण के रूप में तेजी लाने के लिए धीमा

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

इसे प्राप्त करने के लिए, हमें तीन क्षेत्रों पर ध्यान केंद्रित करना चाहिए: लोग, प्रक्रिया और उत्पाद। लोगों के काम को धीमा करते हुए, हम व्यावसायिकता और कौशल बढ़ाने का प्रयास करते हैं। प्रक्रिया को धीमा करके, हम लचीलापन और दक्षता बढ़ाने का प्रयास करते हैं। और उत्पाद पर काम धीमा करके, हम स्वचालन के स्तर और गुणवत्ता के स्तर को बढ़ाने का प्रयास करते हैं। जब हम इन तीन क्षेत्रों पर ध्यान केंद्रित करते हैं, तो हम एक ऐसी संस्कृति की खेती शुरू करते हैं जो तेजी से विकास को संभव बनाता है।

हमें निम्नलिखित याद रखना चाहिए:

• एक कार्य प्रणाली जरूरी अच्छी तरह से नहीं लिखी गई है
• केवल सच्चे पेशेवर ही अच्छी तरह से डिज़ाइन की गई प्रणाली बना सकते हैं
• केवल एक अच्छी तरह से डिज़ाइन की गई प्रणाली आपको जल्दी से जल्दी नई कार्यक्षमता जारी करने की अनुमति देगी

लेखक के बारे में

Lemi Orhan Ergin एक सॉफ़्टवेयर डेवलपमेंट विज़ार्ड है, जो अपने उद्योग में उत्कृष्टता के स्तर को बढ़ाने और समुदाय के साथ अपने अनुभव को साझा करने का प्रयास करता है। Craftbase सह-संस्थापक और तुर्की सॉफ्टवेयर शिल्प कौशल समुदाय के संस्थापक। 2001 से सॉफ्टवेयर विकास में शामिल है। वह सक्रम, चरम प्रोग्रामिंग, विकास के तरीके और वेब-प्रौद्योगिकियों जैसे क्षेत्रों में सक्रिय रूप से अभ्यास और सलाह देता है।