बचाव के लिए कप्तान स्पष्ट!
मैं यहाँ पर कप्तान हूँ और कहता हूँ कि वहाँ कुछ मध्य मैदान पाया जाना है।
आप भविष्य के लिए निर्माण करना चाहते हैं और खुद को तकनीकी विकल्प या खराब डिजाइन में बंद करने से बचते हैं। लेकिन आप 3 महीने कुछ ऐसा खर्च नहीं करना चाहते हैं जो सरल होना चाहिए, या एक त्वरित और गंदे ऐप के लिए विस्तार बिंदु जोड़ना होगा जिसमें 2 साल का जीवनकाल होगा और अनुवर्ती परियोजनाओं की संभावना नहीं है।
यह भेद खोजना मुश्किल है, क्योंकि आप हमेशा अपने उत्पाद की सफलता का अनुमान नहीं लगा सकते हैं और यदि आपको बाद में इसे बढ़ाने की आवश्यकता होगी।
अभी के लिए बनाएँ अगर ...
- इस परियोजना को खत्म किया जा रहा है
- परियोजना का जीवनकाल छोटा है
- प्रोजेक्ट में एक्सटेंशन नहीं होना चाहिए
- परियोजना में जोखिम प्रभाव मूल्य नहीं है (ज्यादातर छवि के संदर्भ में)
सामान्य तौर पर, इन-हाउस प्रोजेक्ट्स या किसी ग्राहक के लिए निर्मित कुछ को अभी के लिए विकसित किया जाना चाहिए। सीधे आवश्यकताओं के लिए सुनिश्चित करें, और उन्हें पता है कि क्या जरूरत है और क्या नहीं है की जरूरत है। किसी भी चीज़ पर बहुत अधिक समय खर्च नहीं करना चाहते हैं जो "अच्छा है।" लेकिन सुअर की तरह कोड नहीं है।
सामान्य समस्या को बाद के लिए छोड़ दें, यदि यह कभी आवश्यक हो सकता है और प्रयास के लायक है:
भविष्य के लिए बनाएँ यदि ...
- परियोजना सार्वजनिक होगी
- परियोजना पुन: उपयोग किया जाने वाला एक घटक है
- परियोजना अन्य परियोजनाओं के लिए एक कदम है
- परियोजना में अनुवर्ती परियोजनाओं या संवर्द्धन के साथ सेवा रिलीज होगी
यदि आप कुछ सार्वजनिक करने के लिए निर्माण कर रहे हैं, या कि अन्य परियोजनाओं में पुन: उपयोग किया जा रहा है, तो आपको बहुत अधिक संभावना है कि एक बुरा डिजाइन आपको परेशान करने के लिए वापस आ जाएगा, इसलिए आपको उस पर अधिक ध्यान देना चाहिए। लेकिन यह हमेशा की गारंटी नहीं है।
दिशा-निर्देश
मैं कहता हूं कि निम्नलिखित सिद्धांतों का सबसे अच्छा पालन करें, और आपको खुद को कुशल, अनुकूलनीय उत्पादों को डिजाइन करने की स्थिति में रखना चाहिए:
- जानते हैं कि YAGNI ,
- KISS ,
- जब भी आपको एक खुजली खरोंच और एक अतिरिक्त के बारे में सोचें, तो इसे लिखें। अपनी परियोजना की आवश्यकताओं को देखें और अपने आप से पूछें कि परिवर्धन प्राथमिकताएं हैं या नहीं। पूछें कि वे प्राथमिक व्यावसायिक मूल्य जोड़ते हैं या नहीं।
मुझे पता है कि मैं व्यक्तिगत रूप से पल्ला झाड़ना और खत्म करना चाहता हूं। यह वास्तव में विचारों को लिखने में मदद करता है और बहुत बार फिर से सोचता है कि क्या मुझे अतिरिक्त सुविधाओं की आवश्यकता है। अक्सर, जवाब नहीं है, या, "यह बाद में अच्छा होगा।" वे अंतिम विचार खतरनाक हैं, क्योंकि वे मेरे सिर के पीछे रहते हैं, और मुझे खुद को उनके लिए योजना नहीं बनाने के लिए मजबूर करने की आवश्यकता है।
अतिरंजना के बिना और बाद में खुद को अवरुद्ध करने के बिना कोड करने का सबसे अच्छा तरीका एक अच्छा न्यूनतम डिजाइन पर ध्यान केंद्रित करना है। घटकों के रूप में अच्छी तरह से चीजों को तोड़ दें जिन्हें आप बाद में बढ़ा सकते हैं, लेकिन पहले से ही इस बारे में विचार किए बिना कि उन्हें बाद में कैसे बढ़ाया जा सकता है। आप भविष्य की भविष्यवाणी नहीं कर सकते।
बस सरल चीजों का निर्माण करें।
Dilemmata
Overengineering
क्या यह ट्रेंड प्रोग्रामर आमतौर पर इस तरह की परियोजना के बारे में जाने के दौरान अनुसरण करते हैं?
जी हाँ। यह एक ज्ञात दुविधा है, और यह केवल यह दर्शाता है कि आप उत्पाद की परवाह करते हैं। यदि आप नहीं करते हैं, तो यह अधिक चिंताजनक है। इस बात को लेकर असहमति है कि क्या कम हमेशा सही मायने में अधिक होता है और अगर बदतर हमेशा सही मायने में बेहतर होता है । आप एक एमआईटी या न्यू जर्सी तरह के आदमी हो सकते हैं । यहां कोई आसान जवाब नहीं है।
प्रोटोटाइपिंग / क्विक-एन-डर्टी / कम अधिक है
क्या यह जल्द से जल्द एक व्यावहारिक उदाहरण को मिटाने के लिए एक विशिष्ट प्रवृत्ति है?
यह एक प्रचलित प्रथा है, लेकिन यह नहीं है कि परियोजनाओं के विशाल बहुमत से कैसे संपर्क किया जाए। फिर भी, मेरी राय में प्रोटोटाइप एक अच्छा चलन है, लेकिन एक नकारात्मक पहलू है। यह वास्तविक उत्पादों के लिए त्वरित और गंदे प्रोटोटाइप को बढ़ावा देने, या प्रबंधन दबाव या समय की कमी के तहत वास्तविक उत्पादों के लिए आधार के रूप में उपयोग करने के लिए आकर्षक हो सकता है। जब प्रोटोटाइप आपको परेशान करने के लिए वापस आ सकता है।
प्रोटोटाइपिंग के स्पष्ट लाभ हैं , लेकिन दुरुपयोग और दुरुपयोग के लिए बहुत अधिक संभावनाएं (एक परिणाम के रूप में पहले सूचीबद्ध लाभों के कई सटीक उलटा)।
प्रोटोटाइप का उपयोग कब करें?
प्रोटोटाइप का उपयोग करने के लिए सबसे अच्छी प्रकार की परियोजनाओं के रूप में संकेत हैं :
[...] प्रोटोटाइप सिस्टम में सबसे अधिक फायदेमंद है जिसमें उपयोगकर्ताओं के साथ कई इंटरैक्शन होंगे।
[...] प्रोटोटाइप ऑन-लाइन सिस्टम के विश्लेषण और डिजाइन में बहुत प्रभावी है, विशेष रूप से लेनदेन प्रसंस्करण के लिए, जहां स्क्रीन संवाद का उपयोग साक्ष्य में बहुत अधिक है। कंप्यूटर और उपयोगकर्ता के बीच अधिक से अधिक संपर्क, अधिक से अधिक लाभ [...]
"तिथि करने के लिए तेजी से प्रोटोटाइप के सबसे उत्पादक उपयोगों में से एक पुनरावृत्त उपयोगकर्ता आवश्यकताओं इंजीनियरिंग और मानव-कंप्यूटर इंटरफ़ेस डिज़ाइन के लिए एक उपकरण के रूप में किया गया है।"
दूसरी ओर:
छोटे उपयोगकर्ता इंटरैक्शन वाले सिस्टम, जैसे बैच प्रोसेसिंग या सिस्टम जो ज्यादातर गणना करते हैं, प्रोटोटाइपिंग से बहुत कम लाभ उठाते हैं। कभी-कभी, सिस्टम फ़ंक्शंस को निष्पादित करने के लिए आवश्यक कोडिंग बहुत गहन हो सकती है और संभावित लाभ जो प्रोटोटाइप प्रदान कर सकते हैं, वे बहुत छोटे हैं।
और अगर आपके पास एक हरा राक्षस है, तो बस बजट के भीतर एक प्रोटोटाइप रखना सुनिश्चित करें ...
