सॉफ्टवेयर डिजाइन: इसे तेजी से बनाएं या अच्छी तरह से बनाएं?


38

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

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


10
"यह सही करने के लिए कभी समय नहीं है, लेकिन हमेशा इसे करने का समय है।"
स्कॉट व्हिटलॉक

1
आप जानते हैं कि वित्तीय सलाहकार कैसे कहते हैं कि कर्ज में मत जाओ? या तो तकनीकी ऋण में मत जाओ :)
निकोल

3
अनिवार्य xkcd संदर्भ: xkcd.com/844
user281377

@ammoQ ने मुझे इसके लिए हराया।

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

जवाबों:


48

इसे अच्छे से बनाएं

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

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

दूसरे शब्दों में (जब तक कि यह एक और किया जाने वाला अनुबंध नहीं है), इसे तेजी से बनाया गया है = इसे धीमा बनाएं, इसे अच्छी तरह से बनाएं = तेजी से निर्माण करें


इसके अलावा "यह अच्छी तरह से निर्माण" और एक वास्तुकला डिजाइन करने के बारे में महसूस करने के लिए कुछ महत्वपूर्ण है। तुम ने पूछा था...

... लेकिन इस जोखिम को चलाने से कि यह सब अतिरिक्त कोड का उपयोग नहीं किया जा सकता है क्योंकि आपका डिज़ाइन काफी तरल है और फीडबैक को अलग दिशा में जाने के कारण आपको इसे फेंकना पड़ सकता है?

यह वास्तव में "वास्तुकला समय बिताने" से एक सच्चा जोखिम नहीं है। आर्किटेक्चर का डिजाइन ऑर्गेनिक होना चाहिए । किसी भी हिस्से के लिए वास्तुकला को डिजाइन करने में समय व्यतीत न करें जब तक कि यह उचित न हो। आर्किटेक्चर को केवल आपके प्रोजेक्ट में देखे गए और पुष्टि किए गए पैटर्न से बाहर निकलना चाहिए।

जॉन गैल के नियम से तंत्र :

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


9
मैं पर्याप्त उत्थान नहीं कर सकता। एक और अच्छा उद्धरण अंकल बॉब से है "तेजी से जाने का एकमात्र तरीका अच्छी तरह से जाना है"
कैफीक

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

4
मेरे पिताजी के सम्मान में, "यदि आप इसे पहली बार आधा-गधा करते हैं, तो आपके पास इसे ठीक करने के लिए काम की मात्रा दोगुनी होगी।"
श्री चींटी

हे ... सूत्र मुझे लगता है: यह अच्छी तरह से निर्माण = तेजी से निर्माण = यह धीमी गति से निर्माण। मुझे लगता है कि अंतिम "बिल्ड इट फास्ट" का निर्माण तकनीकी ऋण के संदर्भ में कम होना चाहिए । चूंकि एक अच्छी तरह से बनाई गई प्रणाली पर निर्माण के लिए कम काम की आवश्यकता होती है।
16

@ साइकिक मैं सहमत हूं लेकिन यह भी, विचार "इसे अच्छी तरह से बनाना = बाद में तेजी से निर्माण करना " है। बहुत से प्रबंधक कुछ महीनों के लिए गति नहीं छोड़ना चाहते हैं जो वास्तव में बाद में गति बढ़ाएगा।
निकोल

17

तेजी से, फिर अच्छी तरह से

यह मेरे व्यक्तिगत अनुभव से है जिसमें विभिन्न तरीकों की बहुत कोशिश की गई है।

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

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

उपर, उपवास, फिर कुआँ!

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

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

इस तरह आप अपने अनुभव के रूप में संभव के रूप में एक ध्वनि वास्तुकला के साथ एक आवेदन के साथ समाप्त हो जाएगा, वैसे भी मेरे अनुभव में :)


2
+1 याह, मैं
जोड़ूंगा

मैं इस जवाब से सहमत हूं। और मैं शामोद से सहमत हूं।
किम जोंग वू

पुनरावृति की गति पुनरावृत्तियों की गुणवत्ता - खुद StackExchange के अनुसार - कुछ अच्छे उदाहरणों के साथ - codinghorror.com/blog/2010/09/go-that-way-really-fast.html
jasonk

10

इसे बनाओ

अगर बाजार में तेजी से गुणवत्ता की तुलना में अधिक महत्वपूर्ण है

ठीक है अगर गुणवत्ता बाजार के लिए समय से अधिक महत्वपूर्ण है


8

इसका तेजी से निर्माण करने से आपको अल्पकालिक लाभ और दीर्घकालिक नुकसान होगा।

इसे अच्छी तरह से बनाने से कम समय का नुकसान होगा लेकिन दीर्घकालिक लाभ होगा।

इसका अच्छी तरह से निर्माण करना धैर्य और ज्ञान की माँग करता है लेकिन आपको पुरस्कृत किया जाएगा।

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


5

जिन परियोजनाओं के लिए आप दूसरों को वितरित करने की योजना बना रहे हैं, उनका उपयोग करने के लिए मैं हमेशा सामने वाले के काम में त्रुटि करूंगा। यदि आवश्यक हो तो एक अच्छी तरह से सोचा वास्तुकला का विस्तार करना आसान है। केवल तकनीकी ऋण जमा करने के लिए लघु कटौती करना मॉडल है।

यह कई बार निराशाजनक रूप से धीमा हो सकता है। सही काम करने लायक चीजें हैं।


1
बस "अच्छी तरह से सोचा" कथन को योग्य बनाने के लिए: इसका मतलब यह नहीं है कि सब कुछ सामने वाले के बारे में सोच रहा है (यह नहीं किया जा सकता है), लेकिन बस यह सोचने के लिए कुछ समय ले रहा है कि किसी सुविधा को कहीं और टॉस करने के बजाय कैसे एकीकृत किया जाए और इसके साथ किया जाए। ।
Matthieu M.

5

अच्छी तरह से बनाना = तेजी से बनाना

शॉर्टकट आपको घुमाते हैं और आपको तेजी से काटते हैं। कभी-कभी लंच से पहले भी।

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


3

यदि आप पहले से ही जानते हैं कि आप क्या कर रहे हैं, अगर आप नहीं करते हैं तो उपवास करें

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

  1. इसे काम करने लायक बनाओ।
  2. इसको सही करो। एक बार सही करने के बाद यह फायदा होता है कि आप इसे काम करने का अनुभव प्राप्त करने के बाद एक बार "सही" परिभाषित कर सकते हैं।

2

इसे अच्छे से बनाएं .. हमेशा, लेकिन तेजी से आगे बढ़ने का भ्रम दें

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


+1, केवल वही बनाएं जो वास्तव में आवश्यक है।
निकोल

1

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


1

संतुलन

यह पूरी तरह से अपने कोड को इंजीनियर करने के लिए व्यावहारिक नहीं है या एक झटके में एक साथ कुछ कोड को मैश-अप करता है, क्या यह है? यह वास्तव में सही संतुलन हड़ताली के बारे में है। मेरी राय में क्या मायने रखता है जब आप करते हैं।

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


सही बात। जितना संभव हो उतना अच्छा निर्माण करें जो अनुमति दी गई है।
jwenting

1

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


0

जैसा कि मुझे उम्मीद है कि जैसे ही मुझे लोगों से प्रतिक्रिया मिलेगी रूप में मॉर्फ करेंगे

आपने इसे स्वयं सर्वश्रेष्ठ कहा:

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

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


0

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


0

इसे अच्छे से बनाएं । यदि आपके पास समय नहीं है, तो फीचर सेट को कम करें।

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


0

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

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

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

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

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

व्यावसायिक रूप से काम करते समय मैं संयोग से भी यही दृष्टिकोण अपनाता हूं। ;)


0

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


-1

आप आमतौर पर इन दो किनारों के बीच में रहना चाहते हैं:

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

इसे तेजी से बनाएँ = बेकार सॉफ्टवेयर जिसका कोई वास्तव में उपयोग नहीं करता है।


हा! एक बेकार सॉफ्टवेयर का निर्माण ...
दोपहर २१'११

नकारात्मक वोट पर कोई कारण?
vz0
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.