👨🏽‍🏭 🍓 🦆 भविष्य के डेवलपर्स के लिए काम करना 🌌 👿 🍐

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

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

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

1. समग्र परावर्तन

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

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

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

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

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

अपने README या प्रलेखन भंडार में समझौते जोड़ें। सबसे पहले, यह भविष्य के डेवलपर के लिए सिस्टम में नई कार्यक्षमता जोड़ने और उसके घटकों को कैसे बनाया जाता है, इसकी समझ देगा।

2. डेड कोड का उन्मूलन

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

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

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

लंबे समय तक छोड़ दिए गए कोड को हटा दें। अंत में, यह अभी भी संस्करण नियंत्रण में है, अगर आपको इसे बाद में वापस करने की आवश्यकता है। "बाद में उसके पास वापस आने" की आवश्यकता से मूर्ख मत बनो। यदि इस कोड का कोई अर्थ था, तो अब यह उपयोग में क्यों नहीं है?

3. जानकारी जमा करें

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

 jp@oeuf:~/workspace/blog(master*)$ git log --oneline app/controllers/application_controller.rb 8ec7f99 fuck i dunno lol ffa919a shut up, atom parser a33e9fa fixing again cecc9dc one more time 968a28f fixing 3e3aeb2 ws 1fc597e pagination edea155 adding dumb feature

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

 jp@oeuf:~/workspace/blog(master*)$ git log app/controllers/application_controller.rb commit 8ec7f998fb74a80886ece47f0a51bd03b0460c7a Author: John Pignata <john@pignata.com> Date: Sat Nov 3 14:11:12 2012 -0400 Add Google Analytics helper commit 968a28f366e959081307e65253118a65301466f2 Author: John Pignata <john@pignata.com> Date: Sat Nov 3 13:49:50 2012 -0400 Correct ATOM feed validation issues Using the W3C Validator (http://validator.w3.org/appc/), a few trivial errors were reported: * <author> should have a <name> node within it and not text * Timestamps should be in ISO8601 format This change fixes these issues and improves the spec coverage for the XML document. commit 3e3aeb27ea99ecd612c436814c5a2b0dab69c2c3 Author: John Pignata <john@pignata.com> Date: Sat Nov 3 13:46:24 2012 -0400 Fixing whitespace We're no longer indenting methods after `private` or `protected` directives as a matter of style. This commit fixes whitespace in all remaining classes. commit 1fc597e788442e8cc774c6d11e7ac5e77b6c6e14 Author: John Pignata <john@pignata.com> Date: Sat Nov 3 12:34:50 2012 -0400 Implement Kaminari pagination Move from will_paginate to kaminari in all controllers. The motivation is to be able to paginate simple Array collections without the monkey patching that will_paginate uses. * Consolidate helpers * Clean up whitespace commit edea15560595bab044143149a7d6e528e8ae65d2 Author: John Pignata <john@pignata.com> Date: Sat Nov 3 12:27:16 2012 -0400 Add ATOM feed for RSS readers * Include Nokogiri in Gemfile for its builder * Add AtomFieldBuilder model * Add link to feed from index page

4. अपने इंटरफेस पर चमक को इंगित करें

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

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

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

5. टिप्पणियों को छोड़ दें, तो बहुत अधिक नहीं, ज्यादातर RDoc

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

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

आरडीओसी-शैली के प्रलेखन को कई खुले स्रोत परियोजनाओं में पाया जा सकता है। जब आप यह समझने के लिए Google का उपयोग करते हैं कि क्या select_tag कॉलबैक करता है या नहीं, और क्या हस्ताक्षर select_tag है, तो आप आमतौर पर रूबी ऑन रेल्स के लिए RDoc पृष्ठ पर जाते हैं। अपने प्रोजेक्ट के लिए समान डॉक्यूमेंट लिखने से Future Developer को और अधिक समझने में मदद मिलेगी जब वह आपके सिस्टम के विशाल संदर्भ में ऑब्जेक्ट की भूमिका निर्धारित करने की कोशिश करेगा। कक्षा के शीर्ष पर एक छोटी और घोषणात्मक वाक्य होने और / या यह दर्शाने की विधि कि कोड के पाठक के लिए क्या महत्वपूर्ण हो सकता है। लेकिन इन टिप्पणियों की प्रासंगिकता का समर्थन करने के लिए एक अच्छी तरह से स्थापित संस्कृति के बिना, वे कोड पाठक का भटकाव करते हुए, एक नकारात्मक प्रभाव भी डाल सकते हैं। याद रखें, केवल एक चीज जो प्रलेखन की कमी से भी बदतर हो सकती है, वह है खराब प्रलेखन।

6. परीक्षण लिखें जो आपके इरादों को प्रकट करते हैं।

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

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

 it "works" do data = File.open("fixtures/projects.txt").read index = ProjectIndex.new(data) index.should have(40).projects last_project = projects.last last_project.title.should eq("ORCA") last_project.customer.should eq("Romney-Ryan 2012") last_project.deploy_date.should eq(Date.parse("2012-11-06")) end

खैर, यहां क्या काम करता है? एक शब्द में यह वर्णन निरर्थक है, और उदाहरण में कई चेक एक बार में किए जाते हैं, जो बिल्कुल भी समझ में नहीं आता है।

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

 jp@oeuf:~/workspace/project-manager(master)$ be rspec --format documentation spec ProjectIndex .new instantiates an index given the contents of a project CSV file #projects returns a collection of projects from the index Project #title returns the project title #customer returns the Customer record for the project #deploy_date calculates the deploy date from the latest project status

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

भविष्य के डेवलपर को खुशी हुई

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

डेव यूएई से धन्यवाद, जिनसे मैंने उधार लिया (पढ़ा: चुराया) शब्द "भविष्य के डेवलपर"।

कोई विचार, प्रश्न या टिप्पणी? कृपया उन्हें साझा करें! मुझे @jpignata उपनाम के तहत ट्विटर पर पाया जा सकता है, और मैं john@pignata.com पर ईमेल द्वारा भी उपलब्ध हूं। पढ़ने के लिए धन्यवाद!

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

भविष्य के डेवलपर्स के लिए काम करना