अजीब प्रोग्रामिंग सिद्धांत आप कभी नहीं सुना है

विज्ञापन

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

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

1. द ब्लोट प्रिंसिपल

इस एक की इतनी विविधताएँ हैं कि एक को मुख्य के रूप में चुनना कठिन है। शायद सबसे अधिक "आधिकारिक" संस्करण, सॉफ्टवेयर के विकास का नियम है, जिसे अधिक सामान्यतः कहा जाता है Zawinski का नियम, जेमी Zawinski के नाम पर और में उल्लेख किया UNIX प्रोग्रामिंग की कला:

“हर कार्यक्रम मेल पढ़ने तक का विस्तार करने का प्रयास करता है। वे कार्यक्रम जो इतने विस्तार नहीं कर सकते हैं उन्हें प्रतिस्थापित किया जा सकता है। ”

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

यह सॉफ्टवेयर प्रदर्शन पर भी लागू हो सकता है:

"सॉफ्टवेयर सभी उपलब्ध संसाधनों का उपभोग करने के लिए फैलता है।"

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

2. "इससे भी अच्छी बात है" मानसिकता

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

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

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

जब आप इसे अनदेखा करते हैं तो क्या होता है? आप के साथ समाप्त होता है सॉफ्टवेयर पीटर सिद्धांत:

"एक अत्यधिक जटिल परियोजना अंततः अपने स्वयं के डेवलपर्स द्वारा भी समझने के लिए बहुत जटिल हो जाएगी।"

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

3. ईगल्सन का नियम

"आपका अपना कोई भी कोड जिसे आपने छह या अधिक महीनों तक नहीं देखा है, वह किसी अन्य व्यक्ति द्वारा लिखा गया हो सकता है।"

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

दूसरा तरीका रखो: यदि आप किसी पुरानी परियोजना को देखते हैं और आप कुछ भी नहीं देख सकते हैं जो आप सुधार सकते हैं या अगली बार अलग-अलग तरीके से करेंगे, तो आपको प्रोग्रामर के रूप में स्थिर होने की संभावना है।

4. कम से कम विस्मय का सिद्धांत

"यदि एक आवश्यक विशेषता में एक उच्च विस्मय कारक है, तो यह सुविधा को फिर से डिज़ाइन करने के लिए आवश्यक हो सकता है।"

में पहली बार प्रकाशित हुआ आईबीएम सिस्टम जर्नल 1984 में वापस, यह सिद्धांत आज भी आश्चर्यजनक रूप से प्रासंगिक है - शायद पहले से कहीं अधिक।

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

5. साइबरनेटिक एंटोमोलॉजी का कानून

"हमेशा एक और बग होता है।"

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

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

6. कर्निघन का नियम

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

ब्रायन केर्निघन, वही जो सह-लेखक थे C प्रोग्रामिंग भाषा बाईबल क्यों सी प्रोग्रामिंग अभी भी सीखने लायक हैC एक मृत भाषा नहीं है। वास्तव में, IEEE स्पेक्ट्रम पत्रिका ने इसे 2017 में नंबर 2 शीर्ष भाषा के रूप में स्थान दिया। यहाँ पाँच कारण हैं। अधिक पढ़ें , इस व्यावहारिक कानून के लिए प्रसिद्ध है। इसका क्रूक्स यह है: लिखना अच्छा कोड, लिखें पठनीय कोड, लिखें सरल कोड, जब तक यह कुछ भी नहीं है चालाक कोड.

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

और रॉबर्ट सी के रूप में। मार्टिन बताते हैं, यह केवल डिबगिंग के बारे में नहीं है:

“वास्तव में, लेखन बनाम पढ़ने में लगने वाले समय का अनुपात 10 से 1 से अधिक है। हम नए कोड लिखने के प्रयास के तहत पुराने कोड को लगातार पढ़ रहे हैं।.. [इसलिए,] इसे पढ़ना आसान बनाता है और लिखना आसान होता है। "

7. रबर डक डिबगिंग

यह एक सिद्धांत नहीं है क्योंकि यह एक तकनीक है, लेकिन यह इतना उपयोगी और अजीब है कि हम इसे छोड़ने के लिए रिमिस नहीं करेंगे।

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

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

8. निन्यानबे नियम

“कोड का पहला 90 प्रतिशत विकास के समय का पहला 90 प्रतिशत होता है। शेष 10 प्रतिशत कोड में अन्य 90 प्रतिशत विकास समय होता है। ”

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

यह हॉफस्टैटर के नियम के साथ हाथ से जाता है:

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

9. पार्किंसंस कानून

"कार्य पूरा होने के लिए उपलब्ध समय को भरने के लिए विस्तार करता है।"

यह एक सिद्धांत, जो सिरिल नॉर्थकोट पार्किंसन द्वारा गढ़ा गया है, एक व्यापक सिद्धांत है जो बिल्कुल प्रोग्रामिंग पर लागू होता है और चला जाता है ऊपर दिए गए निन्यानवे नियम के साथ हाथ में हाथ: एक परियोजना को समाप्त करने के लिए आपके पास कितना समय है, ठीक उसी तरह जब तक यह होने जा रहा है लेना। सॉफ्टवेयर विकास में, "जल्दी खत्म करना" बहुत अधिक मिथक है।

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

10. ब्रूक का नियम

"एक देर से सॉफ्टवेयर परियोजना के लिए जनशक्ति जोड़ना बाद में बनाता है।"

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

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

एक प्रोग्रामर के रूप में आगे जा रहे हैं

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

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

इनमें से कौन सा सिद्धांत आपको सबसे अधिक प्रभावित करता है? किसी अन्य अजीब प्रोग्रामिंग सिद्धांतों के बारे में जानिए जो हम चूक गए? हमें नीचे टिप्पणियों में बताएं!