सॉफ्टवेयर परियोजनाओं में आकस्मिक जटिलता का प्रबंधन कैसे करें


74

जब मुर्रे गेल-मान से पूछा गया कि रिचर्ड फेनमैन ने कितनी कठिन समस्याओं को हल करने में कामयाबी हासिल की तो गेल-मान ने जवाब दिया कि फेनमैन का एक एल्गोरिथ्म था:

  1. समस्या लिखिए।
  2. असली मुश्किल सोचो।
  3. समाधान लिखिए।

गेल-मान यह समझाने की कोशिश कर रहे थे कि फेनमैन एक अलग तरह का समस्या समाधानकर्ता था और उसके तरीकों का अध्ययन करने से प्राप्त होने वाली अंतर्दृष्टि नहीं थी। मैं मध्यम / बड़े सॉफ्टवेयर परियोजनाओं में जटिलता के प्रबंधन के बारे में उसी तरह महसूस करता हूं। जो लोग अच्छे होते हैं वे स्वाभाविक रूप से अच्छे होते हैं और किसी भी तरह से किसी भी बाहरी क्रेफ़्ट को पेश किए बिना पूरी बात को मैनेज करने के लिए विभिन्न अमूर्तताओं को परत और ढेर कर देते हैं।

तो क्या फेनमैन एल्गोरिथ्म आकस्मिक दुर्घटना को प्रबंधित करने का एकमात्र तरीका है या क्या वास्तविक तरीके हैं जो सॉफ़्टवेयर इंजीनियर लगातार आकस्मिक जटिलता को वश में करने के लिए लागू कर सकते हैं?


32
मुझे आश्चर्य नहीं होगा अगर समस्या को लिखने का कार्य (और इसे बाहर निकाल दें ताकि आप इसे किसी और को पर्याप्त रूप से समझा सकें) ने आपको एक समाधान की पहचान करने में मदद की।
रोरी हंटर

@ रोरीहंटर - सहमत। और समस्या को लिखने और किसी के साथ साझा करने का एक हिस्सा आपको संकेत देता है कि आपके पास अभी तक कोई समाधान नहीं है।
जेएफओ

38
@ रोरीहंटर: यह। लगभग साप्ताहिक, मुझे एक समस्या आती है जिसे मैं हल नहीं कर सकता, उसे समझाने के लिए किसी को एक ईमेल लिखें। तब महसूस करें कि यह क्या है कि मैं विचार नहीं कर रहा हूं, समस्या को हल करें और ईमेल को हटा दें। मैंने इस साइट पर लगभग एक दर्जन प्रश्न भी लिखे हैं जो कभी नहीं भेजे गए।
pdr

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

2
@CortAmmon मतलब नहीं है लेकिन यह एक बहुत गूंगा अंतर्दृष्टि की तरह लगता है। डेवलपर्स को जो कुछ भी पता है उसका 99% आपके तथाकथित 'ऑन-द-फ्लाई विकास' के माध्यम से कुछ बिंदु पर सीखा गया था। एक अच्छा प्रोग्रामर बनाने के लिए एक अच्छी समस्या सॉल्वर की जरूरत होती है। समस्याओं का समाधान कुछ ऐसा है जो हम स्वाभाविक रूप से करने के लिए तैयार हैं। यदि आपके डेवलपर्स बढ़ नहीं रहे हैं, तो वे शायद बहुत उबाऊ दोहराव वाले काम कर रहे हैं। काम का प्रकार जो किसी भी प्रतिभाशाली प्रतिभाशाली डेवलपर्स को नाखुश और उदास बना देगा। और ... 'सर्पिल विकास' और कुछ नहीं, बल्कि झरने के मील के पत्थर के साथ पुनरावृत्ति विकास की मूल अवधारणा का एक हैशिंग है।
इवान प्लाइस

जवाबों:


104

जब आप एक अच्छी चाल देखते हैं, तो बेहतर की तलाश करें।
-एमानुएल लास्कर, 27 वर्षीय विश्व शतरंज चैंपियन

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

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

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

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


1
आह, लेकिन आप अपने पहले प्रयास में इस सवाल का एक साफ जवाब लिखने में सक्षम हैं। (और एक बहुत ही अजीब, उस पर।) हो सकता है कि आप सिर्फ भेष में फेनमैन हो।
किमी

1
tl; डॉ; रिफैक्टर, बेखौफ हो।
ओसोडो

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

46

"सॉफ्टवेयर आर्किटेक्चर कौशल सिखाया नहीं जा सकता है" एक व्यापक गिरावट है।

यह समझना आसान है कि कई लोग इसे क्यों मानते हैं (जो लोग इस पर अच्छे हैं वे विश्वास करना चाहते हैं कि वे रहस्यमय रूप से विशेष हैं, और जो लोग विश्वास नहीं करना चाहते हैं कि यह उनकी गलती नहीं है कि वे नहीं हैं।) फिर भी गलत है; कौशल अन्य सॉफ्टवेयर कौशल (जैसे छोरों को समझना, पॉइंटर्स से निपटना आदि) की तुलना में कुछ हद तक अधिक व्यावहारिक है।

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

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


11
मुझे वास्तव में आपका आखिरी वाक्य पसंद है। मैं सकारात्मक हूं कि मैंने अपनी पहली नौकरी में इतना कुछ सीखा क्योंकि मैं अपनी गलतियों को पकड़ने के लिए काफी लंबा था। यह एक मूल्यवान अनुभव है।
मेटाफ़ाइट

26
"अच्छा निर्णय अनुभव से आता है। अनुभव बुरे निर्णय से आता है।"
जोनास

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

4
मुद्दा यह है कि बहुत से लोग दावा करते हैं कि कई लोग बिल्कुल, किसी भी परिस्थिति में अच्छे आर्किटेक्ट बनना नहीं सीख सकते (चाहे व्याख्यान कक्ष में हों या उद्योग में), क्योंकि उन्हें "वह नहीं मिला है जो वह लेता है"। यही मैं सामान्य लेकिन गलत मानता हूं।
किलन फ़ॉथ

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

22

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

विशेषज्ञों को अपने कार्यों को बारीक स्तर तक समझाने के लिए अक्सर मुश्किल होता है; उनकी कई प्रतिक्रियाओं का इतनी अच्छी तरह से अभ्यास किया जाता है कि वे अचेतन कार्य बन जाते हैं। उनके विशाल अनुभव को मस्तिष्क के अशाब्दिक, अचेतन क्षेत्रों द्वारा खनन किया जाता है, जिससे हमें उनका अवलोकन करना और उनके लिए स्पष्ट करना कठिन हो जाता है।

जब विशेषज्ञ अपनी बात करते हैं, तो यह हम में से बाकी लोगों के लिए लगभग जादुई प्रतीत होता है - अजीब झुकाव, अंतर्दृष्टि जो कहीं से भी प्रकट नहीं होती है, और सही उत्तर जानने के लिए एक प्रतीत होता है कि जब हम बाकी सभी भी निश्चित नहीं होते हैं सवाल के बारे में। यह जादू नहीं है, निश्चित रूप से, लेकिन जिस तरह से विशेषज्ञ दुनिया को समझते हैं, वे कैसे हल करते हैं, वे जिस मानसिक मॉडल का उपयोग करते हैं, और इसी तरह, सभी स्पष्ट रूप से नोक्सपर्ट्स से अलग हैं।

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

वर्कप्लेस का यह प्रश्न प्रासंगिक है और आईएमएचओ इस संदर्भ में पढ़ना दिलचस्प होगा।


3
विशेषज्ञ कैसा सोचते हैं, इसका कितना अद्भुत वर्णन है। यह वास्तव में जादू नहीं है, सभी असतत और तार्किक कदमों को स्पष्ट करना मुश्किल है।
मेटाफ़ाइट


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

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

@ सुपर: मैं किसी भी पुस्तक / अध्ययन पर सवाल उठाऊंगा, जिसमें केवल 1-5% लोग विशेषज्ञ हैं, ऐसा हास्यास्पद दावा किया गया है। उनके # & # $ # से एक नंबर खींचने की बात करें। विशेषज्ञों पर क्या? मैं शर्त लगाता हूं कि सांस लेने, चलने, खाने के विशेषज्ञ लोग बहुत अधिक हैं। कौन तय करता है कि विशेषज्ञ स्तर क्या है? 1-5% की तरह एक दावा ऐसे लेखकों द्वारा किसी भी आगे के दावे और विश्लेषण को खारिज कर देता है।
डंक

4

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

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

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

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

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

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

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

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

किसी भी दृष्टिकोण में निहित यह जानना आवश्यक है कि "आकस्मिक" को "आवश्यक" से कैसे अलग किया जाए - यह कहना है कि आपके पास एक महान वास्तुकार (या आर्किटेक्ट्स की टीम) की आवश्यकता है जो वास्तव में सिस्टम और इसके उद्देश्य को समझता है।

उस सब के बाद, मेरे लिए मुख्य बात स्वचालित परीक्षण है । यदि आपके पास पर्याप्त है, तो आपकी प्रणाली नियंत्रण में है। अगर तुम नहीं। । ।


क्या आप बता सकते हैं कि स्वचालित परीक्षण आकस्मिक और आवश्यक जटिलता को कैसे अलग करता है?
1

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

3

" सब कुछ जितना संभव हो उतना सरल बनाया जाना चाहिए, लेकिन कोई सरल नहीं। "
- अल्बर्ट आइंस्टीन को जिम्मेदार ठहराया

मुझे आकस्मिक जटिलता से निपटने के लिए मेरे व्यक्तिगत एल्गोरिथ्म को स्केच करने दें।

  1. उपयोगकर्ता कहानी लिखें या केस का उपयोग करें। उत्पाद स्वामी के साथ समीक्षा करें।
  2. एक एकीकरण परीक्षण लिखें जो विफल रहता है क्योंकि सुविधा नहीं है। QA, या लीड इंजीनियर के साथ समीक्षा करें, यदि आपकी टीम में ऐसा कुछ है।
  3. कुछ वर्गों के लिए इकाई परीक्षण लिखें जो एकीकरण परीक्षण पास कर सकते हैं।
  4. उन परीक्षणों के लिए न्यूनतम कार्यान्वयन लिखें जो इकाई परीक्षण पास करते हैं।
  5. एक साथी डेवलपर के साथ यूनिट परीक्षणों और कार्यान्वयन की समीक्षा करें। चरण 3 पर जाएं।

पूरे डिजाइन का जादू चरण 3 पर होगा: आप उन कक्षाओं को कैसे सेट करते हैं? यह वही सवाल बन जाता है: आप कैसे सोचते हैं कि आपके पास अपनी समस्या का हल होने से पहले आपकी समस्या का हल है?

उल्लेखनीय है, सिर्फ कल्पना आप समाधान लोगों की मुख्य सिफारिशों जो समस्या को सुलझाने पर लिखने में से एक है (जिसे "इच्छाधारी सोच" Abelson और Sussman द्वारा में हो रहा है संरचना और कंप्यूटर प्रोग्राम की व्याख्या और "पिछड़े काम कर" Polya के दशक में कैसे करें इसे हल करें )

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

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


2

दुर्घटना की जटिलता

मूल प्रश्न (विरोधाभास) था:

सॉफ्टवेयर प्रोजेक्ट्स में आर्किटेक्ट कैसे आकस्मिक जटिलता का प्रबंधन करते हैं?

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

आकस्मिक जटिलता को नेतृत्व द्वारा तबाह किया जा सकता है जो अपनी मूल रणनीति से चिपके रहते हैं जब तक कि उस रणनीति से एक जानबूझकर प्रस्थान स्पष्ट रूप से आवश्यक नहीं हो जाता।

अनावश्यक जटिलता से बचना

सवाल के शरीर के आधार पर, मैं इसे इस तरह से फिर से लिखूंगा:

आर्किटेक्ट सॉफ्टवेयर परियोजनाओं में जटिलता का प्रबंधन कैसे करते हैं?

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

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

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

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

समाधान का निर्माण

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

विशिष्ट अंतिम प्रश्नों पर वापस जाएं:

आकस्मिक जटिलता को वश में करने के विशिष्ट तरीके निम्न प्रकार के स्रोतों में पाए जा सकते हैं।

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


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


0

यह कुछ साल पहले एक कठिन प्रश्न हो सकता है, लेकिन आजकल की आकस्मिक जटिलता को खत्म करना आईएमओ के लिए कठिन नहीं है।

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

दो चीजें हाइलाइट करने लायक हैं, आईएमओ: वह खुद को एक प्रोग्रामर मानता है , न कि आर्किटेक्ट, और उसका ध्यान आदतों पर है, ज्ञान पर नहीं।

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

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

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

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

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