मैंने पहले से चीजों की योजना बनाने की कोशिश की है, लेकिन जब तक मैं कुछ कोड को बाहर करना शुरू नहीं करता, तब तक मैं वास्तव में सब कुछ नहीं देख सकता।
यह सोचना आकर्षक है कि सही योजना आपको संपूर्ण सॉफ्टवेयर डिजाइन / आर्किटेक्चर प्रदान करेगी, हालांकि, यह स्पष्ट है कि यह स्पष्ट रूप से गलत है। इसके साथ दो बड़ी समस्याएं हैं। सबसे पहले, "कागज पर" और "कोड" शायद ही कभी मेल खाते हैं, और इसका कारण यह है कि यह कहना आसान है कि इसे वास्तव में करने के विपरीत कैसे किया जाना चाहिए । दूसरे, आवश्यकताओं में अप्रत्याशित परिवर्तन स्पष्ट रूप से विकास प्रक्रिया में देर से स्पष्ट हो जाते हैं जो शुरुआत से ही तर्कपूर्ण नहीं हो सकते थे।
क्या आपने फुर्तीले आंदोलन के बारे में सुना है? यह सोचने का एक तरीका है जहां हम "एक योजना का अनुसरण करने" (अन्य चीजों के अलावा) के विपरीत "परिवर्तन की प्रतिक्रिया" को महत्व देते हैं। यहाँ घोषणापत्र (यह एक त्वरित पढ़ने के लिए है)। आप बिग डिज़ाइन अप फ्रंट (BDUF) और क्या नुकसान हैं के बारे में भी पढ़ सकते हैं।
दुर्भाग्य से, "एजाइल" का कॉर्पोरेट संस्करण फर्जी (प्रमाणित स्क्रैम मास्टर्स का एक गुच्छा है, "एजाइल" के नाम पर भारी प्रक्रिया, घोटाले के लिए मजबूर करना, 100% कोड कवरेज, आदि के लिए मजबूर करना), और आमतौर पर असिन प्रक्रिया में परिवर्तन होता है क्योंकि प्रबंधक लगता है कि एजाइल एक प्रक्रिया है और एक चांदी की गोली (जिसमें से यह न तो है)। फुर्तीले घोषणापत्र को पढ़ें, उन लोगों को सुनें जिन्होंने इस आंदोलन की शुरुआत की जैसे अंकल बॉब और मार्टिन फाउलर, और "कॉरपोरेट एजाइल" के बकवास संस्करण में चूसे नहीं।
विशेष रूप से, आप आमतौर पर वैज्ञानिक कोड पर केवल TDD (टेस्ट ड्रिवेन डेवलपमेंट) करने से दूर हो सकते हैं , और एक अच्छा मौका है कि आपकी सॉफ्टवेयर परियोजना बहुत अच्छी तरह से पूरी हो जाएगी। इसका कारण यह है कि सफल वैज्ञानिक कोड में ज्यादातर अल्ट्रा-यूजेबल इंटरफेस होते हैं, जो एक माध्यमिक (और कभी-कभी प्रतिस्पर्धा) चिंता के रूप में प्रदर्शन के साथ होते हैं, और इसलिए आप अधिक "लालची" डिजाइन के साथ दूर हो सकते हैं। टीडीडी आपके सॉफ़्टवेयर को अति-उपयोग करने योग्य बनाता है , क्योंकि आप लिखते हैं कि आप वास्तव में उन्हें लागू करने से पहले चीजों को कैसे (आदर्श) कहा जाना चाहते हैं। यह छोटे इंटरफेस के साथ छोटे कार्यों को भी मजबूर करता है जिसे जल्दी से एक सरल, "इनपुट" / "आउटपुट" फैशन में कहा जा सकता है, और यह आपको रिफैक्टर के लिए एक अच्छी स्थिति में रखता है। मामले में आवश्यकताओं में परिवर्तन।
मुझे लगता है कि हम सभी सहमत हैं कि numpyसफल वैज्ञानिक कंप्यूटिंग सॉफ्टवेयर है। उनके इंटरफेस छोटे, सुपर प्रयोग करने योग्य हैं, और सब कुछ एक साथ अच्छी तरह से खेलते हैं। ध्यान दें कि numpyसंदर्भ गाइड स्पष्ट रूप से TDD: https://docs.scipy.org/doc/numpy-1.15.1/reference/testing.html की अनुशंसा करता है । मैंने SAR (सिंथेटिक एपर्चर रडार) इमेजिंग सॉफ्टवेयर के लिए अतीत में TDD का उपयोग किया है: और मैं यह भी दावा कर सकता हूं कि यह उस विशेष डोमेन के लिए बहुत अच्छा काम करता है।
कैविएट: टीडीडी का डिज़ाइन भाग उन प्रणालियों में कम अच्छी तरह से काम करता है, जहां एक वितरित प्रणाली की तरह, एक मौलिक रीफैक्टरिंग (जैसे यह तय करना कि आपको अपने सॉफ्टवेयर को अत्यधिक समवर्ती करने की आवश्यकता है) कठिन होगा। उदाहरण के लिए, यदि आपको फेसबुक जैसी कोई चीज़ डिज़ाइन करनी है, जहाँ आपके लाखों समवर्ती उपयोगकर्ता हैं, तो TDD (अपने डिज़ाइन को चलाने के लिए) करना एक ग़लती होगी (फिर भी आपके द्वारा प्रारंभिक डिज़ाइन के बाद उपयोग करना ठीक है , और बस "पहले विकास का परीक्षण करें" ")। कोड में कूदने से पहले संसाधनों और आपके आवेदन की संरचना के बारे में सोचना महत्वपूर्ण है । TDD आपको कभी भी अत्यधिक उपलब्ध, वितरित प्रणाली की ओर नहीं ले जाएगा।
मैं हमेशा इस तरह से महसूस करने से कैसे बच सकता हूं अगर मैं अपने कार्यक्रम को खरोंच से पूरी तरह से पुनर्निर्माण करता हूं तो मैं इसे बहुत बेहतर करूंगा?
उपरोक्त को देखते हुए, यह कुछ हद तक स्पष्ट होना चाहिए कि एक आदर्श डिजाइन वास्तव में प्राप्त करना असंभव है, इसलिए एक आदर्श डिजाइन का पीछा करना एक मूर्ख खेल है। आप वास्तव में केवल पास हो सकते हैं। यहां तक कि अगर आपको लगता है कि आप खरोंच से फिर से डिज़ाइन कर सकते हैं, तो शायद अभी भी छिपी हुई आवश्यकताएं हैं जो खुद को नहीं दिखाती हैं। इसके अलावा, पुनर्लेखन में कम से कम तब तक का समय लगता है जब तक कि इसे मूल कोड विकसित करने में लग गए। यह लगभग निश्चित रूप से छोटा नहीं होगा, क्योंकि यह संभावना है कि नए डिजाइन की अपनी स्वयं की अप्रत्याशित समस्याएं होंगी, साथ ही आपको पुरानी प्रणाली की सभी विशेषताओं को फिर से लागू करना होगा।
एक और बात पर विचार करना है कि आपका डिज़ाइन केवल तभी मायने रखता है जब आवश्यकताएं बदलती हैं ।इससे कोई फर्क नहीं पड़ता कि डिज़ाइन कितना खराब है अगर कुछ भी कभी नहीं बदलता (यह मानते हुए कि यह वर्तमान उपयोग के मामलों के लिए पूरी तरह कार्यात्मक है)। मैंने एक बेसलाइन पर काम किया जिसमें 22,000 लाइन स्विच स्टेटमेंट था (फ़ंक्शन अधिक लंबा था)। क्या यह भयानक डिजाइन था? येक हाँ, यह भयानक था। क्या हमने इसे ठीक किया? नहीं, यह ठीक उसी तरह काम करता था जैसा कि यह था, और सिस्टम का वह हिस्सा वास्तव में क्रैश या बग का कारण नहीं बना। यह केवल दो साल में एक बार छू गया था जब मैं परियोजना पर था, और किसी ने, आपने अनुमान लगाया, स्विच में एक और मामला डाला। लेकिन यह कुछ ऐसा तय करने के लिए समय नहीं है जो इतनी बार छुआ गया हो, ऐसा नहीं है। अपूर्ण डिजाइन को वैसे ही रहने दें, और अगर यह टूट गया (या लगातार टूट रहा है) तो इसे ठीक न करें। तो शायद आप बेहतर कर सकते हैं ... लेकिन क्या यह फिर से लिखने के लायक होगा? आपको क्या लाभ होगा?
HTH।