प्रारंभिक चरणों में प्रोटोटाइप बनाम क्लीन कोड

Question

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

• बस प्रोटोटाइप - बस काम कर रहे बुनियादी कोड लिखें जो मुझे आसान विस्तार के लिए अनुकूलन और रीफैक्टरिंग के टन खर्च कर सकते हैं।

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

अपडेट: YAGNI को sunpech और M.Sameer के उत्तरों के साथ संयोजित करने से मुझे सही समझ आती है :) मदद के लिए आप सभी का धन्यवाद।

Comments

यह भी देखें: कब रिफ्लेक्टर के लिए

— gnat

Answer 1

एक तीसरा विकल्प है ... YAGNI की आज की जरूरतों को पूरा करने के लिए परीक्षण संचालित विकास के माध्यम से स्वच्छ कोड लिखें।

कोड लिखने का प्रलोभन जो इस समय आवश्यक नहीं है, लेकिन भविष्य में हो सकता है कि कई नुकसानों से ग्रस्त हो ... से आप इसे स्वीकार नहीं करेंगे :

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

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

उस कोड को लिखें जिसे आपको अभी जानने की आवश्यकता है कि आप आज और कल की जरूरतों को पूरा करने में सक्षम हैं।

Comments

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

— वेन मोलिना

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

— जेरेमी

@ जेरेमी, आप मेरे उत्तर पर सही मान रहे हैं। लेकिन यह जवाब वही नहीं है। यह सख्त प्रोग्रामिंग तरीके पर आधारित है जहां अन्य एक अनुभव पर आधारित है, यकीन है कि वे कुछ मामलों में समान दिखते हैं, लेकिन यह समान नहीं है :) कम से कम बिंदु से मैं इसे देखता

— हूं

@JackLeo मुझे लगता है कि बिंदु यह है कि एक बार जब आप अनुभव के एक निश्चित स्तर तक पहुँच जाते हैं, तो "कोड मैंने कड़ी मेहनत की" और "कोड मैंने अभी लिखा है" के बीच अंतर होना बंद हो जाता है।

— एंट पी

@AntP तथ्य। 6 साल बाद इस सवाल पर विचार करना दिलचस्प है :)

— जैकलेओ

Answer 2

हमेशा की तरह...

निर्भर करता है

यदि आप किसी जोखिम को कम करने या किसी अज्ञात को उजागर करने के लिए प्रोटोटाइप कर रहे हैं, तो बस इसे कोड करें और जब आप पूरा कर लें तो इसे फेंकने की अपेक्षा करें

यदि आप पुनरावृत्ति शोधन के लिए प्रोटोटाइप कर रहे हैं, तो बस इसे कोड करें और इसे बार-बार संशोधित और पुन: सक्रिय करने की अपेक्षा करें

यदि आप वास्तविक उत्पाद लिखना शुरू कर रहे हैं, लेकिन इसे प्रोटोटाइप कह रहे हैं तो आप आलसी हो सकते हैं , तो आलसी मत बनो, और इसे पहली बार अच्छी तरह से लिखो

Comments

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

— maple_shaft

@maple_shaft: हाँ, "दूर फेंक" रूपक के रूप में है, "आवश्यक रूप से इसे फिर से भरने की कोशिश न करें, इसे फिर से लिखने की योजना बनाएं"

— स्टीवन ए। लोव

मैं कहता हूं कि आप आलसी हैं और इसे पहली बार अच्छी तरह से लिखें ताकि आपको वापस जाने और बाद में इसे फिर से लिखने की ज़रूरत न पड़े।

— ब्लफ़ल

तीसरा वाक्य मेरा दिन बना।

— क्रिस्टोफर फ्रांसिस्को

Answer 3

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

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

सॉफ्टवेयर डेवलपर्स के रूप में, हम चीजों को सही तरीके से करने और पहली बार साफ करने में इतने फंस जाते हैं कि हम महसूस नहीं कर पाते हैं कि यह वह कोड नहीं है जिसे हम वितरित कर रहे हैं, यह एक समस्या का समाधान है ।

मैं कोडिंग के बारे में सोचता हूं क्योंकि मैं एक पेपर लिखूंगा:

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

Comments

+1 बहुत अच्छा जवाब :) यह मेरे लिए शुरुआती दिनों में बहुत कुछ हुआ इसलिए बड़ी परियोजनाओं पर कूदने का कारण बन सकता है ... यही कारण है कि मुझे डर है।

— जैकलेओ

"सॉफ्टवेयर डेवलपर्स के रूप में, हम चीजों को सही तरीके से करने और पहली बार साफ करने में इतने फंस जाते हैं कि हम महसूस नहीं कर पाते हैं कि यह कोड नहीं है जिसे हम वितरित कर रहे हैं, यह एक समस्या का समाधान है।" मैं कहता हूँ कि इसके आसपास दूसरा तरीका है: "हमारे पास इसे सही करने के लिए कभी समय नहीं है लेकिन हमारे पास हमेशा इसे करने का समय है"।

— क्रिस्टोफर फ्रांसिस्को

Answer 4

दो प्रकार के प्रोटोटाइप हैं:

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

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

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

Comments

बहुत अच्छी बात है, विभिन्न प्रकार के प्रोटोटाइप दिखाने के लिए, मैंने इसके बारे में सोचा नहीं है :) मेरे लिए हालांकि यहाँ भोजन :)

— जैकलो

बात से सहमत!

— रिचर्ड टोपची

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

— Jan Hudec

Answer 5

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

Comments

बस एक बात का मैं ज़िक्र करना भूल गया। मैंने इसे फिर से देखा है और फिर से लोग "प्रोटोटाइप" उद्देश्यों के लिए त्वरित और गंदे लिख रहे थे और यह उत्पादन उद्देश्यों के लिए दर्दनाक और बदसूरत हो गया। एक बार जब यह हो गया और काम कर रहा है, तो लोग इसमें पट्टियाँ जोड़ते रहते हैं, गंदगी पर गंदगी जमा करते हैं।

— जीन बुशुइव

आपको अच्छी बात मिली - "अगर यह काम करता है तो फिर से क्यों लिखता है?" बहुत सारी युवा कंपनियों के लिए एक समस्या है, मैं इसे अपनी वर्तमान नौकरी की स्थिति में भी देखता हूं जब बड़ी कंपनियां 10 वर्षीय सीएमएस का उपयोग करती हैं जो कि आज के मानकों पर अपग्रेड करने के लिए दर्दनाक है ... यही कारण है कि मैं इस तरह के सवाल पूछ रहा हूं, मैं डॉन ' t यहाँ एक गलती करना चाहते हैं। हालांकि आपका जवाब मुख्य रूप से कह रहा है कि मैं मैला कोड लिखने का बहाना खोज रहा हूं। नहीं। सनपेच और एम। सेमर को मेरी बात सही लगी। प्रोटोटाइप यह देखने के लिए कुछ बनाने के लिए है कि दुनिया इस पर क्या प्रतिक्रिया देगी। अगर यह काम करता है - इसे अच्छा बनाएं।

— जैकलू

Answer 6

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

Answer 7

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

Comments

यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप इसे बेहतर आकार में संपादित करना चाहेंगे ?

— १६:१३ से

क्या आप सुझाव दे सकते हैं कि आपको क्या लगता है कि समस्या क्या है? शायद वाक्य बहुत लंबे हैं, जैसा कि मैंने देखा है कि उनमें से केवल दो हैं। और कुछ?

— टॉम डब्ल्यू

Answer 8

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

Answer 9

दोनों अच्छे हैं। दोनों मुझे पसंद हैं। वे एक-दूसरे का विरोध नहीं करते।

मुझे प्रोटोटाइप पसंद है। प्रोटोटाइपिंग मेरी रचनात्मकता कौशल विकसित कर रहा है। मैं कई संभावित समाधानों का परीक्षण कर रहा हूं। इसे जल्दी करने से मुझे समस्या को हल करने के कई संभावित तरीकों का परीक्षण करने की संभावना मिलती है।

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

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

Answer 10

मेरा कहना है कि चरम सीमा लगभग हमेशा खराब होती है।

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

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

मैंने एक लेख लिखा था जो शुरू होने के बारे में कुछ संकेत दे सकता है: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d