कोड के बारे में बात करने में असमर्थता

"कोड के बारे में बात करना" का अर्थ उस आदेश को समझना है जिसमें निर्देशों को निष्पादित किया जाता है ("सिर में कार्यक्रम निष्पादित करें"), यह जानना कि कोड का उद्देश्य क्या है।

लक्षण

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

इलाज

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

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

प्रोग्रामिंग भाषा मॉडल की खराब समझ

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

लक्षण

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

इलाज

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

चरण 1: "ओओपी केवल विधियों के साथ संरचनाएं हैं।"
चरण 2: "ओओपी में विधियां केवल ऐसे कार्य हैं जो वैश्विक चर के अपने स्वयं के सेट के साथ एक मिनी-प्रोग्राम निष्पादित करते हैं।"
चरण 3: "वैश्विक चर को फ़ील्ड कहा जाता है, उनमें से कुछ मिनी-प्रोग्राम के बाहर निजी और अदृश्य हैं।"
चरण 4: "निजी और सार्वजनिक तत्वों के होने का बहुत ही विचार कार्यान्वयन विवरणों को छिपाना और एक स्वच्छ इंटरफ़ेस को उजागर करना है, और यह इनकैप्सुलेशन है।"
चरण 5: "एनकैप्सुलेशन का अर्थ है कि मेरे व्यावसायिक तर्क को कार्यान्वयन विवरण के साथ भरा नहीं जाना चाहिए।"

अंतिम चरण सभी भाषाओं के लिए समान है, क्योंकि सभी भाषाएँ प्रोग्रामर के कार्यान्वयन के विवरण में इस अर्थ को दफन किए बिना प्रोग्राम के अर्थ को व्यक्त करने की संभावना का नेतृत्व करने की कोशिश करती हैं। कार्यात्मक प्रोग्रामिंग लें:

चरण 1: "कार्यात्मक प्रोग्रामिंग वह है जब सब कुछ निर्धारक कार्यों की श्रृंखलाओं के माध्यम से किया जाता है।"
चरण 2: “जब कार्य नियतात्मक होते हैं, तो उन्हें आउटपुट में आवश्यक होने तक गणना करने की आवश्यकता नहीं होती है, और केवल उस भाग की गणना करने की आवश्यकता होती है। इसे आलसी और आंशिक कंप्यूटिंग कहा जाता है। "
चरण 3: “आलसी और आंशिक गणनाओं का समर्थन करने के लिए, कंपाइलर को मुझे एक पैरामीटर के परिवर्तन के संदर्भ में फ़ंक्शन लिखने की आवश्यकता होती है, कभी-कभी ऐसे परिवर्तनों का एक और फ़ंक्शन परिणाम बनाता है। इसे क्यूरिंग कहा जाता है। ”
चरण 4: "जब सभी कार्यों पर अंकुश लगाया जाता है, तो यह कंपाइलर बाधा सॉल्वर का उपयोग करके सबसे अच्छा निष्पादन योजना चुनने की अनुमति देता है।"
चरण 5: "बाधा को हल करने वाले को सभी महत्वहीन विवरणों को स्वयं हल करने दें, मैं यह वर्णन कर सकता हूं कि मुझे क्या चाहिए और कैसे प्राप्त करना है।"

प्लेटफ़ॉर्म क्षमताओं की रिसर्च डेफ़िसिट / क्रोनिक रूप से खराब ज्ञान

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

लक्षण

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

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

* - यादृच्छिक दोहराव भी होता है, आमतौर पर रूपरेखा के आकार के लिए आनुपातिक होता है, इसलिए मूल्यांकन से मात्रा के लिए आगे बढ़ें।

इलाज

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

संकेत समझने में असमर्थता

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

लक्षण

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

इलाज

मेरे दोस्त जो मेरे जैसे ही होटल में रहते थे, लेकिन मुझे नहीं पता था कि कौन सा कमरा है। हालांकि, मुझे पता था कि उसका दोस्त फ्रैंक कहां रहता है। इसलिए मैं वहाँ गया, दरवाजा खटखटाया और फ्रैंक से पूछा: "जो कहाँ रुका?" फ्रैंक नहीं जानता था, लेकिन वह जानता था कि थिओडोर किस कमरे में, जो के एक सहयोगी, रहता है। इसलिए मैं थियोडोर के कमरे में गया और पूछा कि जोए कहां रह रहा है, और थियोडोर ने मुझे बताया कि जो 414 कमरे में था। मैंने उसे वहां पाया!

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

पुनरावृत्ति कठिनाइयों

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

लक्षण

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

इलाज

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

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

एक साधारण प्रोग्रामर के संकेत

संग्रह में सोचने की अक्षमता

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

लक्षण

ये लक्षण केवल तभी मायने रखते हैं, जब वे खुद को घोषित या कार्यात्मक क्षमताओं के साथ एक मंच पर प्रकट करते हैं, जो प्रोग्रामर को पता होना चाहिए।

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

इलाज

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

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

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

आलोचनात्मक सोच का अभाव

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

लक्षण

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

इलाज

पॉल और एल्डर्स क्रिटिकल थिंकिंग किताब के साथ शुरू करें, अपने अहंकार को प्रबंधित करने पर काम करें और आलोचना के लिए अपने विचारों को मित्रों और सहकर्मियों पर भरोसा करने के लिए खुद का बचाव करने का आग्रह करें।

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

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

पिनबॉल प्रोग्रामिंग

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

लक्षण

• एक कोशिश पकड़ने वाला ब्लॉक, जिसमें मेन का पूरा शरीर शामिल है (), प्रोग्राम को पुनरारंभ करना।
• उन मानों के लिए स्ट्रिंग्स या पूर्णांक का उपयोग करना, जो एक जोरदार टाइप की गई भाषा में अधिक उपयुक्त प्रकार हो सकते हैं।
• जटिल डेटा को अलग-अलग लाइनों में पैक करना और प्रत्येक फ़ंक्शन में उन्हें पार्स करना जहां यह डेटा उपयोग किया जाता है।
• , .
• sleep() thread .
• Switch «».
• automethod' reflection' , .
• .
• , , , .
• .
• rollback.

इलाज

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

आपको अपने मंच के तंत्र से खुद को परिचित करने की आवश्यकता है, जो आपको अपने कार्यक्रम को विश्वसनीय और लचीला बनाने की अनुमति देता है। ऐसे तंत्र के तीन मुख्य प्रकार:

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

एक चौथा तंत्र भी है - इकाई परीक्षण, जिसका उपयोग आप डिजाइन और विकास के दौरान करते हैं।

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

सुरक्षा सिद्धांतों की अनदेखी

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

लक्षण

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

इलाज

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

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

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

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

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

और अंत में: आपको Kirkhoffs सिद्धांत से शुरू करके एन्क्रिप्शन की मूल बातें सीखने की जरूरत है। इसे "सुरक्षा कुंजी में होना चाहिए" के रूप में तैयार किया जा सकता है। इस सिद्धांत पर आधारित कुछ दिलचस्प निष्कर्ष भी हैं।

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

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

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

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

संकेत है कि आप एक प्रोग्रामर नहीं होना चाहिए

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

कार्यक्रम निष्पादन आदेश निर्धारित करने में असमर्थता

लक्षण

a = 5
b = 10
a = b

print a

आप इस कोड को देखते हैं और निश्चित नहीं हैं कि कौन सी संख्या मुद्रित होगी।

वैकल्पिक पेशे

• विद्युत्कार
• मरम्मत करनेवाला
• वास्तुकार
• सिविल इंजीनियर

अमूर्त सोचने में असमर्थता

लक्षण

• वस्तुओं और वर्गों के बीच अंतर को समझने में कठिनाई।
• .
• .
• .
• LISP .
• -.

• -, .
• -, .
• «» .
• .
• .

-

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

वैकल्पिक पेशे

• स्लॉट मशीन कैसीनो नियमित

परिणाम के प्रति उदासीनता

प्रोग्रामिंग अभी भी आपका शौक हो सकता है, लेकिन आपकी भागीदारी के सॉफ़्टवेयर उद्योग से छुटकारा पाना सार्वजनिक हित में है।

लक्षण

• , «» .
• , .*
• , .
• , , , , .*
• , (, ), , , « » .
• , - .
• .
• (, « » «», , - ).
• , , .

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

वैकल्पिक पेशे

• कर्ज लेने वाला
• टेलीमार्केटिंग