आपके द्वारा लिखे गए बदसूरत कोड से आप कैसे निपटेंगे? [बन्द है]

Question

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

आप क्या करते हैं? OCD उन्मत्त होना बंद करें और बस यह स्वीकार करें कि आपका कोड गड़बड़ कर रहा है, चाहे आप कुछ भी करें, और इस राक्षसीपन की सुविधाओं से बस निपटते रहें? संस्करण 2 के लिए सफाई सहेजें?

Comments

यह बहुत अच्छा सवाल है।

— वाल्टर

मुझे लगता है कि 80/20 नियम को लागू करने के लिए यह एक अच्छी जगह है ।

— मार्क सी

umm.. पहली जगह में बदसूरत कोड नहीं लिखेंगे ?!

— रूपेश शेनॉय

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

— एमपीएन

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

— एमपीएन

Answer 1

दूसरी नौकरी हासिल करें और दूसरे लोगों को इससे निपटने दें। Muahahahhahahaa।

.....

सिर्फ मजाक करना। :)

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

एक और (संबंधित) टिप: हमेशा अनुमान लग रहा है कि छोटे, एक सभ्य आकार ब्लॉक करने के लिए कोई brainer कार्य। उदाहरण के लिए, कहो - एक आइटम जो आपको लगभग निश्चित है बस एक सरल एक पंक्ति 30 सेकंड का बदलाव होगा - इसे 1 घंटा दें (या हो सकता है कि आपके टाइमशीट या सीआर सिस्टम पर सबसे कम समय ब्लॉक हो, जैसे 15 मिनट / 0.25 घंटे) । और थोड़ा बड़ा लेकिन फिर भी अपेक्षाकृत तुच्छ वस्तुओं के लिए आधे दिन या 1 दिन के ब्लॉक दें।

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

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

Comments

+1 बुराई होने के लिए। ;)for(printf("MUHU"); 1; printf("HA"));

— मतीन उलहाक

@ मंटू: मुझे एहसास हुआ कि क्या किया एक दूसरा लिया ... नहीं देखा for। प्यारा;)

— एमपीएन

मुझे यकीन है कि यह प्रबंधक पर निर्भर करता है, लेकिन आपको झूठ बोलने की आवश्यकता नहीं है। सीटीओ और मुझे एक समझ है; वह जानता है कि मैं एक उचित अनुमान दे सकता हूं लेकिन केवल 50% विश्वास के साथ; यदि मैं एक ठग कारक में डालता हूं तो मैं 90% विश्वास स्तर के साथ एक ही अनुमान दे सकता हूं। और यह पता चला है कि, समय की एक लंबी अवधि में, ज्यादातर लोग भोलेपन से आशावादी लोगों के लिए विश्वसनीय अनुमान पसंद करते हैं, भले ही वे इसे स्वीकार नहीं करते हैं या महसूस नहीं करते हैं, इसलिए वह अपने मालिक को निराशावादी अनुमान देता है जब तक कि यह आपातकालीन न हो।

— हार्वेस्ट 3

लगभग आधे घंटे से कम समय के लिए कुछ भी नहीं लेने वाला बिंदु बहुत अच्छी तरह से बनाया गया है। यहां तक ​​कि अगर कोड में एक भी परिवर्तन 5 मिनट लगते हैं, तो ओवरहेड का एक बेड़ा होता है जो साथ जाता है।

— मर्फ़

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

— जॉन हॉपकिंस

Answer 2

जानबूझकर अपनी अगली सुविधाओं के लिए आवश्यक समय को नजरअंदाज करें। साफ करने के लिए उस अतिरिक्त समय का उपयोग करें।

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

Comments

इसके लिए +1। अनुमान पैडिंग FTW। और वास्तव में, एक ही सलाह उचित औचित्य के लिए जाती है कि बग फिक्सिंग और रखरखाव में कितना समय लगता है (आंतरिक रूप से: पीएचबी के लिए, ग्राहकों को नहीं, जैसा कि आप कहते हैं कि ग्राहकों को परवाह नहीं है)।

— बॉबी टेबल्स

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

— टिन मैन

ओह, आगे: बिल्कुल, आदर्श खुला है, ईमानदार संचार। मैं केवल एक नकल तंत्र का सुझाव देता हूं जब यह पूरी तरह से प्राप्त नहीं होता है। यह छल के रूप में दीर्घकालिक दवा है।

— फ्रैंक शियरर

क्या यह अनुमान पैडिंग है? यह मेरे लिए कोड की गुणवत्ता को बनाए रखते हुए एक नई सुविधा को लागू करने का समय लगता है।

— डेविड थॉर्नले

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

— बजे ब्रैंडन ड्यूरेट

Answer 3

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

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

उचित रीडिज़ाइन / रिफैक्टरिंग आपके ग्राहकों के निवेश की रक्षा कर सकता है और चीजों को स्थायी रख सकता है। आपको इसे बनाने की आवश्यकता है। परिवर्तन के लिए ऑप्टिमाइज़ करें, प्रकाश यात्रा करें।

Answer 4

अति-आकलन के बारे में सभी टिप्पणियों के साथ मुझे लगता है कि एक मामूली मात्रा में बिंदु (अच्छी तरह से अवसर) याद किया जा रहा है।

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

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

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

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

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

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

Answer 5

1) उचित परिवर्तन नियंत्रण आपका मित्र है

यदि ग्राहक उस विनिर्देश को बदल देता है जो ठीक है, तो यह उसका अधिकार है, हालांकि यह एक बदलाव है और इसे प्रोजेक्ट संरचना (संबंध / संबंध के लिए उपयुक्त होने पर) के लिए शुल्क लिया जाना चाहिए।

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

2) रिफ़ेक्टिंग ऐसी होनी चाहिए जो क्लाइंट को वास्तविक दीर्घकालिक लाभ प्रदान करे

रिफैक्टिंग पर विचार करते समय आपको हमेशा इस पर विचार करने की आवश्यकता होती है कि वास्तव में क्या आवश्यक है और क्या महत्वपूर्ण है और यह सुनिश्चित करें कि रिफैक्टिंग कार्य पैसे के लिए वास्तविक दीर्घकालिक मूल्य प्रदान करता है।

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

Answer 6

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

Comments

+1; यह काम कर सकता है, हालांकि यह बहुत अधिक अनम्य होने से आपके ग्राहक को अलग करने के खतरे को भी चलाता है। कुछ हद तक आप यह कर सकते हैं या नहीं यह परियोजना के प्रकार (आकार) और ग्राहक की अपेक्षाओं पर निर्भर करता है।

— केन हेंडरसन

Answer 7

मेरे पास एक कोड आधार में निम्नलिखित टिप्पणी है जो मैं वर्तमान में काम कर रहा हूं:

/*
 * Every time I see this function, I want to take a shower.
 */

मुझे पता है, बहुत अच्छी तरह से आप जिस स्थिति का वर्णन कर रहे हैं। मैं जो भी करता हूं वह (मेरा सबसे अच्छा) इंतजार करने की कोशिश करता है जब तक कि चीजें शांत नहीं हो जाती हैं और किसी भी तरह के 'रेंगने' में 'क्रेप' होता है, जो वह करने जा रहा है। उस समय तक, आपके पास संभवत: कुछ प्रयोग करने योग्य है, और आप चीजों को साफ करने और सामान को अलग तरीके से लागू करने के लिए कुछ समय ले सकते हैं।

आप बार-बार बहुत सारी छोटी-छोटी गंदगी को साफ करने के लिए नहीं दौड़ सकते। यह सिर्फ आपके काम, और हताशा को बढ़ाता है। इसके लिए एक बड़ा बनने की प्रतीक्षा करें, लेकिन शायद ही गड़बड़ चल रही हो और फिर आप इसके बारे में कुछ कर सकते हैं।

Answer 8

मेरी प्राथमिकता इस स्थिति से बचने की है।

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

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

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

Comments

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

— एमपीएन

Answer 9

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

Comments

मैं घंटे से चार्ज कर रहा हूं, लेकिन बात यह है कि जब मैं "अच्छा कोड" लिखने के लिए समय लेता हूं तो यह बहुत जल्दी अप्रचलित हो जाता है, मैं सोच रहा हूं कि क्या कोई बिंदु है। मुझे लगता है कि मैं परियोजना को स्थिर करने से पहले लगातार सफाई करके लागत जोड़ रहा हूं।

— एमपैन

Answer 10

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

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

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

Answer 11

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

जो लोग सोचते हैं कि वे डिजाइन कर सकते हैं और सामने की हर चीज के बारे में सोच सकते हैं, ज्यादातर खुद को बेवकूफ बना रहे हैं, आप (और आपके ग्राहक) हमेशा चीजों को सीखते हैं जैसे आप साथ चलते हैं। उन पाठों का उपयोग करें।

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

ग्राहकों को पता चल सकता है कि क्या वे जानते थे कि आप "समय बर्बाद कर रहे हैं" काम कर रहे हैं इसलिए यह पूछने / बताने में मदद नहीं करता है और वास्तव में इसके बारे में जल्दी है।

इस तरह से विकसित कोड आपको अंत में समय के भार को बचाएगा और नई सुविधाओं को जोड़ने के लिए तेजी से आसान बना देगा।

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

Answer 12

एक उच्च शक्ति पर भरोसा करते हैं

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

एक सामान्य परियोजना प्रवाह में, गंभीर विकास होने से पहले सामान्य विनिर्देश को जमे हुए होना चाहिए।

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

एक व्यक्ति को विनिर्देशन को पूर्णता और ठंड से मुक्त करने और बाद में इसे लागू करने के लिए समर्पित किया।

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

तथ्य यह है कि आप इस मुद्दे को कर रहे हैं आप कोड के साथ कैसे करना है। यह संकेत है कि आपका प्रोजेक्ट मैनेजर प्रोजेक्ट पर आधारित है (चाहे वह आपकी गलती हो, उसकी गलती हो, या दोनों हो)।

जैसे अन्य लोगों ने कई जवाबों में कहा है, किसी भी परियोजना पर आकस्मिकताओं के लिए एक समय बफर जोड़ना भी आवश्यक है, लेकिन यह निर्धारित करना कि विनिर्देश बंद होने से पहले बंद दरवाजों के पीछे तय किया जाना चाहिए और ग्राहक को पीएम द्वारा वितरित किया जाना चाहिए।

Answer 13

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

कुछ शब्दों में: लाल फेरारी पर बुर्ज फिट करने के बजाय, आवश्यकताओं पर फिर से विचार करें और एक टैंक का निर्माण करें।

Answer 14

अग्नि से उसे मार डालो।

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

Answer 15

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

Answer 16

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

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

प्रत्येक सुविधा का समय / लागत क्या है, यह निर्धारित करने के लिए अपने अनुभवों का उपयोग करें, और फिर उन्हें बताएं, यदि वे ऐसा चाहते हैं, तो यह समय और धन की x राशि लेगा।

फ़ीचर स्कोप रेंगने के बड़े अपराध के साथ आपका व्यवहार, और वे तब तक सुविधाओं को जोड़ते रहेंगे, जब तक कि कुछ भी नहीं हो जाता है या खराब हो जाता है।

एक बार आपके पास अंतिम सूची होने के बाद उन्हें बताएं, कि आप भविष्य में संशोधन करेंगे, जैसा कि वे पसंद करते हैं, लेकिन शीर्ष 15/20 पर ध्यान देने की आवश्यकता है जो उनके पास अभी होना चाहिए।

फिर पूरा होने के समय के आधार पर, उन्हें बताएं, कि इसके जारी होने के बाद, फिर आप अगले संस्करण पर चर्चा / विचार मंथन के लिए खुले रहेंगे।

वर्तमान संस्करण के लिए क्या किया जाना है, इस बारे में अंतिम निर्णय लेने के बाद, सभी चर्चाओं / विचारों / सुझावों को 100% रोका जाना चाहिए।

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

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

यह करना कठिन है, लेकिन फीचर गुंजाइश रेंगना समय, ऊर्जा, प्रेरणा और स्पष्ट सोच का विनाशकारी है।

Answer 17

एक परियोजना से पूरा परिप्रेक्ष्य:

अपनी टीम के साथ कोड से जानें, देखें कि अगली बार क्या फिर से तैयार और पुन: उपयोग किया जा सकता है, फिर एक बियर लें।

इन-डेवलपमेंट परिप्रेक्ष्य से:

धैर्यपूर्वक बताएं कि विकास क्यों रुका है, और यह बताएं कि यह तब तक क्यों नहीं जारी रह सकता जब तक कि सभी ऐनक टेबल पर न हों और समझ में न आएं। फिर, एक बियर ले आओ।

योजना के नजरिए से:

सभी चश्मे के सामने अनुरोध करें और विकास पथ की स्पष्ट समझ रखने के लिए सभी के साथ काम करें। एक ही पृष्ठ पर प्रत्येक व्यक्ति को सुनिश्चित करने के लिए क्लाइंट / हितधारकों को यथासंभव निकटता से शामिल करें। उस रात के बाद, हर कोई बियर प्राप्त करें। कल, परियोजना शुरू करें।