डार्क प्रोग्रामिंग

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

उलटा मूल्य स्केल

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

हम समुराई की तरह हैं। हमें मारने के लिए प्रशिक्षित किया जाता है। लेकिन बात मारने की नहीं है। या जितना संभव हो उतना कम मारना। सबसे अच्छी लड़ाई एक ऐसी लड़ाई है जो शुरू नहीं हुई है। सबसे अच्छा कोड अलिखित कोड है। कोई भी कोड बुराई है।

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

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

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

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

ग्राहक विचार व्यक्त करें

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

यह एक OOP विज्ञापन नहीं है। अधिक कड़े वर्णन के तरीके (कठोरता देखें) का स्वागत है।

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

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

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

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

(उपयोगी काम) / (खर्च किया गया काम)

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

अपने आप में मानवता को मारने के लिए

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

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

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

सटीक विज्ञान में, समस्या को सही ढंग से हल करने के कई तरीके हैं। लेकिन इसे गलत तरीके से हल करने के लिए अनंत तरीके हैं। सही निर्णय आमतौर पर यांत्रिक नियमों पर आधारित होते हैं।

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

लोगों को एक सटीक मानसिकता के साथ क्या अलग करता है वह यह है कि भाषा का उपयोग किसी प्रकार के विचारों को भाषा के लिए बाहरी व्यक्त करने के लिए किया जाता है।

बच्चों की पहेली:
पृथ्वी के बीच में क्या है?
उत्तर: पत्र "एम"।
यह एक उदाहरण है जब वे भाषा के एक भाग के साथ एक वस्तु को भ्रमित करते हैं - एक शब्द।

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

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

कठोरता

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

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

हत्या कार्यक्रम और कीड़े

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

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

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

मैं (एक सिथ के रूप में) आपको ऐसा सॉफ्टवेयर लिखने का आग्रह नहीं करता जो हर सांस के साथ पूरी तरह से दुर्घटनाग्रस्त हो जाए। यहां, हमें एक कम बुराई का चयन करना चाहिए और जिम्मेदारी लेनी चाहिए, जो सब कुछ गिर जाने पर सरल से अधिक खतरनाक है और त्रुटि को ठीक किया जा रहा है, या केवल एक ऑपरेशन गिरने पर काम जारी रखने के लिए। एक दूसरा समाधान अक्सर स्वीकार्य होता है।

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

निष्कर्ष

मुझे लगता है कि कम से कम ये बिंदु आज के लिए पर्याप्त हैं। यह एक घोषणापत्र या कोड का मूल्यांकन और विकास करने के तरीके का पूरा अवलोकन होने का दावा नहीं करता है। लेकिन सामान्य स्थिति - उल्टे पैमाने, कुछ फायदे देता है।
मुझे उम्मीद है कि दिन उबाऊ हो गया है।