सर्वोत्तम प्रथाओं को हमेशा कोडित करना चाहिए [बंद]

Question

सॉफ्टवेयर कोडिंग करते समय, क्या एप्लिकेशन के निर्माण के संबंध में आर्किटेक्चर हमेशा सबसे अच्छा व्यवहार या व्यावहारिक अभ्यास होना चाहिए?

अगर मैं एक दो पेज का वेब एप्लिकेशन बना रहा हूं, जो 5 साल रह सकता है और उस 5 साल में 2 एन्हांसमेंट हो सकते हैं, तो क्या मुझे निर्भरता इंजेक्शन, डिजाइन पैटर्न, व्यू-मॉडल के साथ मॉडल-व्यू-कंट्रोलर आदि में कोड करना चाहिए।

Comments

ओवर-इंजीनियरिंग एक सर्वोत्तम अभ्यास नहीं है।

— 5gon12eder

कोई भी 'सर्वोत्तम प्रथा' नहीं है जो सभी स्थितियों में सभी सॉफ्टवेयर्स के लिए लागू होती है। आपको यह मूल्यांकन करना होगा कि आपकी विशिष्ट स्थिति पर लागू होने वाली लागत के लिए आपको सबसे अच्छा भुगतान क्या मिलता है।

— whatsisname

एक व्यावहारिक प्रोग्रामर बनें। इससे आपको कम से कम प्रतिरोध का रास्ता अपनाना चाहिए।

— जॉन रेनोर

क्या आप सर्वोत्तम अभ्यास के लिए एक परिभाषा प्रदान कर सकते हैं? कई जवाबों से ऐसा लगता है कि वे किसी तरह की शाब्दिक व्याख्या से भ्रमित हैं।

— जेफो

हमेशा सर्वोत्तम अभ्यासों का उपयोग करना सबसे अच्छा अभ्यास है।

— हंस

Answer 1

सबसे अच्छा अभ्यास कोडिंग हमेशा किया जाना चाहिए

हमेशा? नहीं, वह मूर्खतापूर्ण है।

सर्वोत्तम अभ्यास दिशानिर्देश हैं। ज्यादातर लोगों के लिए, ज्यादातर स्थितियों के लिए, अगर कुछ चालाकी के साथ लागू किया जाता है, तो वे सर्वोत्तम परिणाम प्राप्त करेंगे। वे वे हैं जहां आप समाधानों पर विचार करते समय शुरू करते हैं। लेकिन ऐसे स्थान होंगे जहां सर्वोत्तम प्रथाओं को नजरअंदाज किया जा सकता है, क्योंकि बेहतर समाधान हैं।

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

Comments

... लेकिन, "सर्वोत्तम अभ्यास" को परिभाषित करें।

— svidgen

मुझे लगता है कि शुरुआती लोगों के लिए चीजों को "सही" करना चाहते हैं और वास्तव में यह समझने के बिना कि वे क्यों मौजूद हैं या उनका उपयोग कैसे करें, कुछ सर्वोत्तम प्रथाओं (जैसे सॉफ़्टवेयर पैटर्न) का आँख बंद करके उपयोग करना चाहते हैं। शायद यह आत्मज्ञान का दूसरा चरण है, पहला चरण "मुझे नहीं पता कि मैं क्या कर रहा हूं।"

— रॉबर्ट हार्वे

@ रोबर्टहवे - पहले आप सीखें कि क्या करना है, फिर आप सीखते हैं कि आप ऐसा क्यों करते हैं, फिर आप सीखते हैं कि आप क्यों नहीं

— HorusKol

@ हॉर्सकॉल जो मैंने कभी भी पढ़ी है, उनमें से एक है।

— जारेड स्मिथ

+1 के लिए "मनुष्य भविष्य में नहीं देख सकते हैं"

— टुलेंस कोर्डोवा

Answer 2

हाँ। वह स्वयं स्पष्ट है। आप वह क्यों नहीं करेंगे जो सबसे अच्छा है?

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

हालांकि अंगूठे का एक अच्छा नियम: यह सबसे अच्छा अभ्यास नहीं है, कभी भी, डिजाइन पैटर्न के एक गुच्छा का नाम लेने के लिए और बिना सोचे-समझे उन्हें एक साथ जोड़ दें।

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

Comments

आपके तीसरे पैराग्राफ की वजह से ही आपका जवाब मुझसे कम हुआ ।

— रॉबर्ट हार्वे

मैं तीसरे के लिए एक upvote फेंक दूंगा, लेकिन केवल इसलिए कि ऐसा करना एक सर्वोत्तम अभ्यास है। <ग्रिन एंड डक>

— ब्लरफुल

मेरा उत्थान सभी चार अनुच्छेदों पर समान रूप से लागू होता है।

— क्क्सप्लसोन

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

— स्टीव जेसोप

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

— सारा

Answer 3

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

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

दूसरे शब्दों में, यह कूल्हे बिल्कुल नहीं है।

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

सबसे अच्छा, यह 30 दिनों में किया जाएगा, एक उपलब्धि जो कि एक वर्ष में एक एंटरप्राइज़ आर्किटेक्चर में जावा डेवलपर्स की एक सेना ले जाएगी। कोड ईएस 6 / टाइपस्क्रिप्ट है; यह मैंने कभी देखा है सबसे साफ कोड में से कुछ है।

Comments

मुझे लगता है कि आपका जवाब उस बिंदु को दिखाता है जो मैं अपने में बनाने की कोशिश कर रहा था ... कम से कम मुझे ऐसा लगता है। +1 ... भले ही मैं विस्तार की कमी के लिए अभी भी इस प्रश्न को वीटीसी कर रहा हूँ!

— svidgen

मेरी तरह की परियोजना लगता है! विकास में बहुत थकावट हो रही है।

— मैट लेसी

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

— दान पेंट्री

@ डानपेंट्री: मैं इसे ध्यान में रखूंगा।

— रॉबर्ट हार्वे

Answer 4

नहीं । सर्वोत्तम अभ्यास ऐसी चीजें हैं जिन्हें आमतौर पर 99% समय के लिए सबसे अच्छी चीज माना जाता है, लेकिन इसका मतलब यह नहीं है कि वे हमेशा हर स्थिति पर लागू होते हैं।

एक डेवलपर के रूप में आपका काम उन सर्वोत्तम प्रथाओं को जानना और उनका उपयोग करना है, लेकिन यह भी पता है कि उन्हें एक तरफ लाना कब सुरक्षित है।

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

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

तो यह दुर्लभ है, लेकिन ऐसे समय होते हैं जब सर्वोत्तम प्रथाएं एक परिदृश्य के लिए प्रासंगिक नहीं होती हैं, इसलिए यदि वे फिट नहीं होते हैं, तो उन्हें मजबूर न करें।

Answer 5

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

मुझे यह बताने की आवश्यकता है कि "सर्वोत्तम प्रथाओं" का एक एकल, सार्वभौमिक रूप से स्वीकृत सेट नहीं है? एक विशेषज्ञ द्वारा पदोन्नत किसी भी नियम के लिए, आप लगभग हमेशा एक विशेषज्ञ को समान क्रेडेंशियल्स के साथ पा सकते हैं जो कुछ अलग कहता है।

लेकिन इस बिंदु पर: संक्षिप्त उत्तर: आमतौर पर, लेकिन हमेशा नहीं।

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

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

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

लेकिन यदि आप किसी पुस्तक की 100% समय से नियमों की एक सूची का पालन करते हैं, तो आप अक्सर अपने आप को एक चौकोर छेद में एक चौकोर खूंटी पर टिकाते हुए पाएंगे। जिन लोगों ने नियम पुस्तिका लिखी है, वे आपके जैसे मामले में नहीं आए होंगे। और यहां तक ​​कि अगर उनके पास है, अगर यह काफी दुर्लभ है, तो वे इसे अनदेखा कर सकते हैं। एक नियम जो 80% समय का काम करता है, वह एक उत्कृष्ट नियम है - जब तक आप समझते हैं कि यह समय का 80% काम करता है न कि 100% समय।

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

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

Answer 6

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

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

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

Comments

meta.stackexchange.com/a/142354

— रॉबर्ट हार्वे

Answer 7

कुछ चीजें महत्वपूर्ण हैं, कुछ नहीं हैं।

आपको हाथ में समस्या के लिए अपनी पसंद की भाषा और शैली को दर्जी बनाना चाहिए।

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

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

सारांश में, लचीला हो, लेकिन अपठनीय कबाड़ को कोड न करें क्योंकि आपको लगता है कि यह फेंक-दूर कोड है।

Answer 8

मैं एक अलग दृष्टिकोण से देखने की कोशिश करूँगा।

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

2 पेज वेब ऐप के लिए स्प्रिंग बूट जैसे कुछ का उपयोग करना कठिन नहीं है, फिर अपने स्वयं के सर्वलेट्स, जेडडीबी प्रश्नों और अन्य चीजों को रोल करना।

Answer 9

मेरे अनुभव में केवल एक सबसे अच्छा अभ्यास है जिसे मैं अनिवार्य मानता हूं:

यह सरल रखें, बेवकूफ (चुंबन)

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

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

Answer 10

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

Answer 11

सॉफ्टवेयर कोडिंग करते समय, क्या एप्लिकेशन के निर्माण के संबंध में आर्किटेक्चर हमेशा सबसे अच्छा व्यवहार या व्यावहारिक अभ्यास होना चाहिए?

थ्योरी में, हाँ।

रियल वर्ल्ड में, [अभी भी] हाँ, जब तक आप ऐसा कर सकते हैं।

जो, ज़ाहिर है, का अर्थ है, "नहीं"।

समय और धन का दबाव हमेशा आपको "त्वरित और गंदे" समाधान की राह पर धकेलने का प्रयास करेगा , क्योंकि यह ग्राहक को "बेहतर" मूल्य प्रदान करता है। यह कैसे लागू किया जाता है यह ग्राहक या उनके एकाउंटेंट के लिए कोई दिलचस्पी नहीं है। यदि आप दो दिनों में या पूरी तरह से तीन महीनों में एक नौकरी [बुरी तरह से] कर सकते हैं, तो क्या आपको लगता है कि वे आपके लिए पूछने जा रहे हैं?

दो के बीच का अंतर - सबसे अच्छा अभ्यास और आपको "दूर जाना" है - जिसे "तकनीकी ऋण" कहा जाता है; यह पूरी तरह से स्वीकार्य है, जब तक आपके पास इसे "चुकाने" की योजना है, यानी बाद में वापस जाने और चीजों को सुधारने के लिए। फिर से, कुछ ऐसा नहीं जो आप हमेशा (कभी?) के लिए बजट प्राप्त करें।

एक रणनीति को "क्विक" फिक्स के साथ एक प्रारंभिक, बीटा, संस्करण जारी करना है, लेकिन यह सुनिश्चित करें कि "पूर्ण" रिलीज से पहले आवश्यक वास्तु सुधार को प्राथमिकता दी जाए। फिर, कुछ ऐसा नहीं जो आप हमेशा (कभी?) करें।