👏🏼 🚕 👨🏽‍⚕️ प्रोग्रामिंग के कानून 🌎 ✒️ 🧛🏻

डेवलपर्स के लिए उपयोगी कानून, सिद्धांत, सिद्धांत और पैटर्न

परिचय

रिपॉजिटरी अनुवाद github.com/dwmkerr/hacker-laws

सॉफ्टवेयर विकास से संबंधित चर्चाओं में, लोग अक्सर विभिन्न कानूनों के बारे में बात करते हैं। यह भंडार उनमें से कुछ सबसे प्रसिद्ध के लिंक और विवरणों को संग्रहीत करता है।

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

कानून

आमदाल का नियम

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

हम एक उदाहरण देते हैं। यदि प्रोग्राम में दो भाग होते हैं - भाग ए, जिसे एक प्रोसेसर पर निष्पादित किया जाना चाहिए, और भाग बी, जिसे समानांतर किया जा सकता है, तो यह स्पष्ट है कि प्रोग्राम को निष्पादित करने वाले सिस्टम में कई प्रोसेसर जोड़ने के फायदे सीमित हैं। संभावित रूप से, यह भाग B को बहुत तेज कर सकता है - लेकिन भाग A की गति नहीं बदलेगी।

निम्नलिखित आरेख संभावित गति लाभ के उदाहरण दिखाता है:

जैसा कि आप देख सकते हैं, भले ही कार्यक्रम के 50% को समानांतर किया जा सकता है, 10 से अधिक अलग-अलग प्रोसेसर जोड़ने के लाभ नगण्य होंगे। यदि प्रोग्राम को 95% तक समानांतर किया जा सकता है, तो हजारों प्रोसेसर जोड़ने के बाद भी सुधार ध्यान देने योग्य होगा।

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

टूटी हुई विंडोज का सिद्धांत

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

यह सिद्धांत सॉफ्टवेयर विकास पर लागू किया गया है, यह सुझाव देता है कि खराब कोड गुणवत्ता (या तथाकथित " तकनीकी ऋण ") यह महसूस कर सकती है कि गुणवत्ता में सुधार के सभी प्रयासों को अनदेखा या कम करके आंका जाएगा, जिससे नए बुरे कोड की उपस्थिति होगी। यह प्रभाव कैस्केड में विकसित होता है, यही वजह है कि गुणवत्ता समय के साथ बिगड़ती जाती है।

ब्रूक्स कानून

एक देर से परियोजना में अतिरिक्त मानव संसाधन जोड़ने से इसके उत्पादन में और भी देरी हुई।

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

आम कहावत "नौ महिलाएं एक महीने में एक बच्चे को जन्म नहीं दे सकती हैं", विशेष रूप से ब्रूक्स कानून को संदर्भित करता है, क्योंकि कुछ प्रकार के कार्यों को विभाजित या समानांतर नहीं किया जा सकता है।

यह पुस्तक पौराणिक मानव-माह का मुख्य विषय है।

कॉनवे कानून

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

कनिंघम कानून

इंटरनेट पर सही उत्तर खोजने का सबसे अच्छा तरीका एक प्रश्न पूछना नहीं है, बल्कि एक जानबूझकर गलत उत्तर पोस्ट करना है।

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

डनबर नंबर

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

ऐसे रिश्तों की सही संख्या अज्ञात है। डनबर ने खुद सुझाव दिया कि एक व्यक्ति आराम से 150 से अधिक ऐसे कनेक्शनों का समर्थन कर सकता है। उन्होंने इसे और अधिक सामाजिक संदर्भ में वर्णित किया: "यदि आप गलती से बार में उनके साथ भाग लेते हैं तो आप जितने लोगों को एक साथ पीने के निमंत्रण के बिना शामिल होने में संकोच नहीं करते हैं।" आमतौर पर, इस संख्या का अनुमान 100 से 250 तक भिन्न होता है।

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

गोल कानून

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

गोल का नियम बताता है कि एक बहुत ही जटिल प्रणाली को विकसित करने का प्रयास सबसे अधिक असफल होगा। उच्च जटिलता के सिस्टम शायद ही कभी एक बैठे में बनाए जाते हैं - वे सरल लोगों से विकसित होते हैं।

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

गुडहार्ट कानून

किसी भी मनाया सांख्यिकीय पैटर्न को नियंत्रित करने के लिए जैसे ही उस पर दबाव डाला जाता है, वैसे ही ढह जाता है।

इसे अक्सर इस रूप में भी तैयार किया जाता है:

जब एक उपाय एक लक्ष्य बन जाता है, तो यह एक अच्छा उपाय होना बंद हो जाता है।
मर्लिन स्ट्रेन

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

उदाहरण:

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

हनलॉन रेज़र

मूर्खता को कभी भी पूरी तरह से नहीं समझा जाता है।

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

हॉफस्टार का कानून

हमेशा किसी कार्य को पूरा करने में आपकी अपेक्षा से अधिक समय लगता है, भले ही आपने हॉफ़स्टैडर के कानून को ध्यान में रखा हो।

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

" गॉडल, एस्चर, बाख: दिस एंडलेस गारलैंड " पुस्तक से उद्धरण ।

हुटर कानून

सुधार विनाश के बराबर है।

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

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

प्रचार और अमर के कानून का चक्र

हम छोटी अवधि में प्रौद्योगिकी के प्रभाव को कम करने और लंबी अवधि में इसे कम आंकने का प्रयास करते हैं।

प्रचार चक्र समय के साथ प्रौद्योगिकी के उत्साह और विकास का एक दृश्य है, जो मूल रूप से गार्टनर द्वारा निर्मित है। यह ग्राफ द्वारा सबसे अच्छी तरह से चित्रित किया गया है:

प्रौद्योगिकी के आगमन के बाद, इसकी लोकप्रियता फूला हुआ उम्मीदों के चरम पर पहुंच जाती है, फिर अवसाद में गोता लगाती है, आत्मज्ञान के ढलान के साथ बढ़ती है और उत्पादकता के पठार तक पहुंचती है

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

हीराम का नियम

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

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

कर्निगन कानून

डिबगिंग कोड इसे लिखने से दो गुना कठिन है। इसलिए, यदि आप अपनी मानसिक क्षमताओं की सीमा के लिए कोड लिखते हैं, तो परिभाषा के अनुसार, आपके पास इसे डीबग करने के लिए पर्याप्त बुद्धिमत्ता नहीं होगी।

कर्निगन का नियम ब्रायन केर्निगन के नाम पर रखा गया है और उनके द्वारा लिखी गई पुस्तक और प्लॉगर: "एक प्रोग्रामिंग शैली के तत्व" से लिया गया है।

हर कोई जानता है कि डिबगिंग कोड इसे लिखने से दो गुना कठिन है। इसलिए, यदि आप कोड लिखते समय अपने सभी मानसिक प्रयासों को कर रहे हैं, तो आप इसे कैसे डीबग करने जा रहे हैं?

हालांकि कानून एक हाइपरबोले है, लेकिन यह दावा करता है कि कॉम्प्लेक्स की तुलना में सरल कोड का उपयोग करना बेहतर है, क्योंकि कॉम्प्लेक्स कोड में उत्पन्न होने वाली किसी भी समस्या को डीबग करना बहुत महंगा या असंभव भी हो सकता है।

मेटकाफ का नियम

नेटवर्क सिद्धांत में, नेटवर्क की उपयोगिता लगभग इसके उपयोगकर्ताओं की संख्या के वर्ग के रूप में बढ़ती है।

कानून प्रणाली के भीतर संभावित जोड़ीदार कनेक्शनों की संख्या पर आधारित है, और रीड के कानून के साथ निकटता से संबंधित है। Odlyzhko और अन्य लोगों ने तर्क दिया कि रीड और मेटकाफ के कानूनों ने सिस्टम के मूल्य को अतिरंजित किया, नेटवर्क की मानव समझ की सीमाओं को ध्यान में नहीं रखते; डनबर नंबर देखें।

मूर की विधि

एक एकीकृत सर्किट चिप पर रखे गए ट्रांजिस्टर की संख्या लगभग हर 24 महीने में दोगुनी हो जाती है।

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

मर्फी के नियम

जो गलत हो सकता है वह सब गलत हो जाएगा।

एडवर्ड ए। मर्फी द्वारा लिखित मर्फी का नियम बताता है कि जो कुछ भी गलत हो सकता है वह जरूरी गलत होगा।

यह कहावत अक्सर डेवलपर्स द्वारा उपयोग की जाती है। कभी-कभी अप्रत्याशित चीजें विकास, परीक्षण या उत्पादन में भी होती हैं। यह क्षुद्रता के कानून से जुड़ा हो सकता है, जिसका उपयोग अक्सर ब्रिटेन में किया जाता है [वास्तव में, यह रूस / लगभग में भी जाना जाता है। transl]।:

अगर कुछ गलत हो सकता है, तो यह होगा, और सबसे खराब क्षण में।

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

व्यापम का उस्तरा

आपको अनावश्यक रूप से चीजों को गुणा नहीं करना चाहिए।

ओकाम के रेजर का दावा है कि कुछ संभावित समाधानों में, समाधान जिसमें अवधारणाओं और मान्यताओं की कम से कम मात्रा शामिल है, सबसे अधिक संभावना होगी। यह समाधान सबसे सरल होगा और केवल यादृच्छिक कठिनाइयों और संभावित नकारात्मक परिणामों को पेश किए बिना दी गई समस्या को हल करेगा।

पार्किन्सन का नियम

काम उसे आवंटित समय को भरता है।

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

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

समयपूर्व अनुकूलन का प्रभाव

सभी बुराईयो की जड़ समयपूर्व इष्टतमीकरण है।

डोनाल्ड नुथ के काम में "GoTo के साथ संरचित प्रोग्रामिंग", उन्होंने लिखा: "प्रोग्रामर गैर-महत्वपूर्ण कार्यक्रमों के निष्पादन की गति के बारे में सोचने और चिंता करने में बहुत समय बिताते हैं, और यदि आप डिबगिंग और उनका समर्थन करने के बारे में सोचते हैं तो उन्हें अधिक प्रभावी बनाने का एक मजबूत नकारात्मक प्रभाव पड़ता है। हमें समय के 97% की महत्वहीन दक्षता के बारे में भूलने की ज़रूरत है: समय से पहले अनुकूलन सभी बुराइयों की जड़ है। हालांकि, गंभीर 3% मामलों में, हमें अपना अवसर नहीं छोड़ना चाहिए। ”

हालांकि, समय से पहले अनुकूलन को कुछ अनुकूलन करने के प्रयास के रूप में भी वर्णित किया जा सकता है, इससे पहले कि हम समझते हैं कि हमें क्या करने की आवश्यकता है।

पैट कानून

तकनीकी क्षेत्र में दो प्रकार के लोगों का वर्चस्व है: जो लोग समझते हैं कि वे नियंत्रण नहीं करते हैं, और जो नियंत्रित करते हैं वे समझ में नहीं आते हैं।

के लिए कानून पत्ता अक्सर पत्ता निष्कर्ष निकालना चाहिए:

किसी भी तकनीकी पदानुक्रम में, समय के साथ योग्यता का एक व्युत्क्रम विकसित होता है।

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

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

रीड का नियम

बड़े नेटवर्क की उपयोगिता, विशेष रूप से सामाजिक नेटवर्क, नेटवर्क आकार के विकास के साथ तेजी से बढ़ता है।

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

जटिलता के संरक्षण का नियम (टेसलर कानून)

कानून कहता है कि प्रणाली की एक निश्चित जटिलता है, जिसे कम नहीं किया जा सकता है।

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

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

बहते हुए तत्वों का नियम

सभी गैर-तुच्छ सार एक निश्चित सीमा तक प्रवाह के अधीन हैं।

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

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

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

कानून का वर्णन करने वाले लेख में, यह माना जाता है कि अंतर्निहित प्रक्रियाओं की खराब समझ के साथ युग्मित गर्भपात की अत्यधिक लत, कुछ मामलों में समस्या को हल करने की प्रक्रिया को भी जटिल करती है।

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

तुच्छता का नियम

कानून कहता है कि समूह गंभीर और व्यापक लोगों की तुलना में कॉस्मेटिक या तुच्छ मुद्दों पर चर्चा करने में अधिक समय और ध्यान देते हैं।

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

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

यूनिक्स दर्शन

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

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

मॉडल को व्यवस्थित करें

टीम संरचना और संगठन का दृष्टिकोण जो Spotify को बढ़ावा देता है । इस मॉडल में, टीमों को कार्यक्रम के कार्यों के आसपास आयोजित किया जाता है, न कि प्रौद्योगिकी के आसपास।

मॉडल संगठनात्मक संरचना के अन्य घटकों - जनजातियों, गिल्ड, शाखाओं की अवधारणाओं को भी बढ़ावा देता है।

वाडलर का नियम

किसी भी भाषा को डिजाइन करने में, इस सूची से किसी विशेषता पर चर्चा करने में बिताया गया कुल समय सूची में इस सुविधा की स्थिति की शक्ति के समानुपाती होता है।
0. शब्दार्थ।
1. वाक्य रचना।
2. लेक्सिकल सिंटैक्स।
3. टिप्पणियों का शाब्दिक वाक्य-विन्यास।

अर्थात्, शब्दार्थ पर खर्च किए गए प्रत्येक घंटे के लिए, टिप्पणियों के वाक्य-विन्यास पर 8 घंटे खर्च होते हैं।

तुच्छता के नियम की तरह, वाडलर का नियम कहता है कि जब कोई भाषा डिज़ाइन करता है, तो इन संरचनाओं के महत्व की तुलना में भाषा संरचनाओं पर खर्च होने वाला समय बहुत अधिक होता है।

व्हीटन का नियम

बकरी मत बनो।

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

सिद्धांतों

सिद्धांत अक्सर डिजाइनिंग कार्यक्रमों पर सलाह के साथ जुड़े होते हैं।

दिलबर्ट सिद्धांत

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

पीटर के सिद्धांत से प्रेरित स्कॉट एडम्स (दिलबर्ट कॉमिक्स के निर्माता) द्वारा विकसित प्रबंधन अवधारणा। दिलबर्ट सिद्धांत के अनुसार , जिन कर्मचारियों को सक्षम नहीं माना जा सकता था, उन्हें कंपनी के संभावित नुकसान को सीमित करने के लिए प्रबंधकों को पदोन्नत किया जाता है। एडम्स ने पहली बार 1995 में वॉल स्ट्रीट जर्नल के लिए एक लेख में इस सिद्धांत को समझाया और फिर 1996 की अपनी पुस्तक, द दिलीप प्रिंसिपल में इसका विस्तार से वर्णन किया।

पेरेटो सिद्धांत (80/20 नियम)

अधिकांश भाग के लिए, जीवन में सब कुछ असमान रूप से वितरित किया जाता है।

पेरेटो सिद्धांत कहता है कि कुछ मामलों में निवेश का एक छोटा हिस्सा अधिकांश परिणामों के लिए जिम्मेदार होता है:

कार्यक्रम का 80% समय के 20% में लिखा जा सकता है (और सबसे कठिन 20% समय के शेष 80% लेते हैं)।
प्रयास का 20% परिणाम का 80% देता है।
20% कार्य लाभ का 80% बनाता है।
त्रुटियों का 20% कार्यक्रम दुर्घटनाओं के 80% तक ले जाता है।
20% कार्यों का उपयोग 80% समय के लिए किया जाता है।

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

इसके अलावा, इस सिद्धांत को नियम 80/20 के रूप में जाना जाता है, सबसे महत्वपूर्ण छोटे कानून, कारकों की कमी का सिद्धांत।

उदाहरण: 2002 में, Microsoft ने बताया कि 20% सबसे आम त्रुटियों को ठीक करने के बाद, विंडोज और कार्यालय की संबंधित समस्याओं और दुर्घटनाओं का 80% तय हो जाएगा।

पीटर सिद्धांत

पदानुक्रमित प्रणाली में, प्रत्येक व्यक्ति में अपनी अक्षमता के स्तर तक बढ़ने की प्रवृत्ति होती है।

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

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

विश्वसनीयता का सिद्धांत (पोस्टेल का नियम)

अपनी गतिविधियों के बारे में रूढ़िवादी बनें, और दूसरों के योगदान के बारे में उदार रहें।

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

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

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

ठोस

निम्नलिखित 5 सिद्धांतों के लिए संक्षिप्त नाम:

S: द सिंगल रिस्पॉन्सिबिलिटी प्रिंसिपल
O: द ओपन / क्लोज्ड प्रिंसिपल
L: लिस्कोव सब्सट्रैक्शन प्रिंसिपल
I: इंटरफेस सेग्रिगेशन प्रिंसिपल [] इंटरफ़ेस पृथक्करण सिद्धांत]
D: निर्भरता उलटा सिद्धांत

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

एकमात्र जिम्मेदारी का सिद्धांत

प्रत्येक वस्तु की एक जिम्मेदारी होनी चाहिए, और यह जिम्मेदारी पूरी तरह से कक्षा में होनी चाहिए।

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

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

खुलेपन / निकटता का सिद्धांत

विस्तार के लिए एंटिटीज खुली होनी चाहिए, लेकिन बदलाव के लिए बंद।

एसओएलआईडी के सिद्धांतों का दूसरा। सिद्धांत बताता है कि संस्थाओं (वर्गों, मॉड्यूल, फ़ंक्शन, आदि) को अपने व्यवहार को विस्तारित करने की अनुमति देनी चाहिए, लेकिन उनके वर्तमान व्यवहार को नहीं बदलना चाहिए।

एक काल्पनिक उदाहरण: एक मॉड्यूल की कल्पना करें जो मार्केड मार्कअप डॉक्यूमेंट को HTML मार्कअप डॉक्यूमेंट में बदल सकता है। यदि मॉड्यूल का विस्तार किया जा सकता है ताकि यह अपने आंतरिक कार्यों को बदलने के बिना मार्कडाउन प्रारूप की नई विशेषताओं को संभालना सीखता है, तो मॉड्यूल विस्तार के लिए खुला है। यदि मॉड्यूल वर्तमान मार्कडाउन कार्यों के प्रसंस्करण को नहीं बदल सकता है, तो मॉड्यूल संशोधन के लिए बंद है।

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

बारबरा लिस्कोव प्रतिस्थापन सिद्धांत

सिस्टम को तोड़ने के बिना एक उपप्रकार के साथ प्रकार को बदलना संभव होना चाहिए।

एसओएलआईडी के सिद्धांतों का तीसरा। सिद्धांत कहता है कि यदि एक घटक एक प्रकार पर निर्भर करता है, तो इस प्रकार के उपप्रकारों का उपयोग करना संभव होना चाहिए ताकि सिस्टम काम करने से इनकार न करे या इस उपप्रकार के विवरण की आवश्यकता न हो।

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

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

इंटरफ़ेस जुदाई सिद्धांत

सॉफ्टवेयर संस्थाओं को उन तरीकों पर निर्भर नहीं होना चाहिए जिनका वे उपयोग नहीं करते हैं।

सोलिड के सिद्धांतों का चौथा। सिद्धांत कहता है कि एक घटक के उपभोक्ताओं को उस घटक के कार्यों पर निर्भर नहीं होना चाहिए जो इसका उपयोग नहीं करता है।

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

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

निर्भरता उलटा सिद्धांत

ऊपरी स्तर के मॉड्यूल को निचले स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए।

SOLID के सिद्धांतों का पाँचवाँ भाग। सिद्धांत बताता है कि उच्च स्तर के घटकों को नियंत्रित करने वाले को अपनी निर्भरता के कार्यान्वयन के विवरण को नहीं जानना चाहिए।

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

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

अपने आप को दोहरा मत सिद्धांत

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

अपने आप को दोहराएं या DRY न करें , डेवलपर्स को कोड दोहराने की क्षमता को कम करने और एक स्थान पर जानकारी रखने में मदद करता है। इसका उल्लेख 1999 में एंडी हंट और डेव थॉमस ने अपनी पुस्तक प्रोगामेटिक प्रोग्रामर में किया।

DRY सिद्धांत के विपरीत शुष्क] WET का सिद्धांत होना चाहिए गीला] - "सब कुछ लिखें" या "हमें टाइप करना पसंद है" [हम टाइपिंग का आनंद लेते हैं]।

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

KISS सिद्धांत

इसे सरल, मूर्ख बनाए रखें [मूर्ख मत बनो, मूर्ख]

KISS सिद्धांत का कहना है कि अधिकांश सिस्टम बेहतर काम करता है, तो वे जटिल नहीं हैं; इसलिए, विकास में सरलता एक प्रमुख लक्ष्य होना चाहिए, और अनावश्यक जटिलता से बचा जाना चाहिए। इसकी शुरुआत 1960 में अमेरिकी नौसेना में हुई थी और इस वाक्यांश का श्रेय विमान डिजाइनर क्लैरेंस जॉनसन को दिया जाता है।

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

YAGNI

आपके लिए यह आवश्यक नहीं है [आपको इसकी आवश्यकता नहीं है]।

हमेशा फ़ंक्शंस लागू करें जब आपको वास्तव में उनकी आवश्यकता होती है, न कि तब जब आप सोचते हैं कि आपको भविष्य में उनकी आवश्यकता है।

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

इस सिद्धांत के बाद डेटाबेस में अप्रयुक्त कोड की मात्रा को कम करना चाहिए, साथ ही कार्यक्षमता पर समय और ऊर्जा की बर्बादी जो लाभ नहीं लाती है।

वितरित कम्प्यूटिंग की गलतफहमी

नेटवर्क कंप्यूटिंग की गिरावट के रूप में भी जाना जाता है। यह वितरित कंप्यूटिंग के बारे में मान्यताओं की एक सूची है जो सॉफ़्टवेयर विफलताओं को जन्म दे सकती है। ये निम्नलिखित धारणाएँ हैं:

नेटवर्क विश्वसनीय है।
देरी शून्य है।
बैंडविड्थ अंतहीन है।
नेटवर्क सुरक्षित है।
टोपोलॉजी नहीं बदलती है।
केवल एक व्यवस्थापक है।
शिपिंग लागत शून्य है।
नेटवर्क सजातीय है।

1991 में पहले चार बिल जॉय और टॉम लियोन द्वारा सूचीबद्ध किए गए थे, और जेम्स गोसलिंग ने पहली बार उन्हें "नेटवर्क कम्प्यूटिंग गलतफहमी" के रूप में वर्गीकृत किया। पीटर डिक्शन ने 5 वां, 6 वां और 7 वां भ्रम जोड़ा। 90 के दशक के अंत में, गोसलिंग ने 8 वीं जोड़ी।

इंजीनियरों का एक समूह सन माइक्रोसिस्टम्स में उस समय होने वाली प्रक्रियाओं से प्रेरित था।

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

प्रोग्रामिंग के कानून