"सिंगल थ्रेडेड प्रोग्रामर"

वास्तविक घटनाओं के आधार पर निम्नलिखित सभी काल्पनिक कथाएं।

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

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

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

इसलिए, "ग्यारहवें" समय के लिए और "ग्यारहवें" समय के लिए एक ही समस्या पर ठोकर खाई, इसके समान समाधान का अवलोकन करते हुए, मेरा मानना ​​है कि इस "दृष्टिकोण" को लिखित रूप में लिखने से मुझे इसे "कौशल" के रूप में समेकित करने में मदद मिलेगी।

इस संबंध में, इस नोट को यहां प्रकाशित करने से, मुझे उम्मीद है कि दूसरी "शॉट खरगोश" ऐसी स्थितियों से छुटकारा पाने में किसी और की मदद कर सकती है।

UPD3 धन्यवाद dimka_ben : "सिंगल-थ्रेडेड" एक विशेष व्यक्ति की सोच की ख़ासियत को संदर्भित करता है, जब एक पल में वह केवल एक चीज के बारे में सोच सकता है।



तो दो प्रोग्रामर हैं। सामान्य लोग, वे बहुत कुछ जानते हैं, गरिमा के साथ काम करते हैं।

UPD1 : बाचिन की टिप्पणी से सलाह पर जाएं:
# डेफिन निकिता "नंबर एक प्रोग्रामर"
# डेफिन डेनिस "प्रोग्रामर नंबर दो"

दोनों यूआई करते हैं, दोनों ब्राउज़र के लिए जावास्क्रिप्ट कोड लिखते हैं। दोनों एक-दूसरे के कोड को समझते हैं, और दोनों इसे गंभीर समस्याओं के बिना सही करते हैं।

लेकिन एक ही समय में, निम्न स्थिति खुद को बार-बार दोहराती है: यदि डेनिस ने निकिता के कोड को सही किया, तो वह पहली बार कभी भी सफल नहीं होता है। निकिता हमेशा डेनिस के कोड को बिना किसी देरी या समस्याओं के तुरंत ठीक कर देती है।

यहाँ कोई सोचता है कि डेनिस बस "बदतर" है। लेकिन वास्तव में, यह पूरी तरह से सच नहीं है, वे सिर्फ "अलग" हैं, और विभिन्न चीजों में आए हैं। और अब वे "वही काम" कर रहे हैं।

और फिर वह पल आया जब निकिता छुट्टी पर चली गई। स्वाभाविक रूप से, स्थिति जल्द ही खराब हो गई, और डेनिस को कोड को संपादित करना पड़ा, यद्यपि परिचित, लेकिन फिर भी "विदेशी"।

उन्होंने इसे तीन बार रीमेक किया। कोड की तीस लाइनों पर लगभग पूरे कार्य दिवस। इस तथ्य के बावजूद कि यह कोड उनसे परिचित था और कई महीनों तक महत्वपूर्ण रूप से नहीं बदला।

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

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

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

आखिरी बार डेनिस ने खुद को तीन बटन की स्थिति में दफन किया:

1. "सहेजें" और "सहेजें और अधिक बनाएं" रिकॉर्ड के "बनाएँ" स्क्रीन पर,
2. संपादन स्क्रीन पर सहेजें।

सभी तीन बटन पर निकिता को एक ही हैंडलर के लिए सेट किया गया था, अर्थात्। सभी तीन बटन "एक विधि में परिवर्तित"। इसने तीन अलग-अलग संयोजनों को बदल दिया, जो समान प्रदर्शन करते हैं, लेकिन फिर भी थोड़ा अलग एल्गोरिथम अनुक्रम हैं। विधि में IF स्थितियों के माध्यम से उपलब्ध कुछ अन्य दृश्यों को भी शामिल किया गया है। तब डेनिस को और भी अधिक समय लगा, क्योंकि एक विधि में उपयोग केस की कुल संख्या 7 थी।

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

अपने आधे जीवन के लिए, निकिता ने दृढ़ता से टाइप की गई प्रोग्रामिंग भाषाओं के साथ काम किया, जो एप्लिकेशन को चलाने से पहले संकलन की आवश्यकता थी।

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

निकिता ने OOP को इनपुट चर के एक अलग सेट के माध्यम से तरीकों के पुनर्वितरण के स्तर पर समझा। डेनिस ने बिना किसी समस्या के प्रोटोटाइप के आधार पर विरासत को लागू किया।

निकिता ने बहु-थ्रेडेड अनुप्रयोगों के साथ काम किया। डेनिस Node.JS के हिस्से के रूप में मल्टीथ्रेडिंग के कार्यान्वयन से निपटने के लिए शुरू करने वाले थे।

यह एक दिलचस्प तस्वीर निकला:

• डिबगिंग के दौरान निकिता सोच सकती है कि यह कोड अलग-अलग यूज केस में काम करेगा।
• डेनिस याद करते हैं कि बग का एक बंडल प्राप्त करने के बाद ही कई उपयोग मामले हैं।

यही है, डेनिस "तुरंत" एक ऐसी स्थिति का अनुभव नहीं करता है जब कई अलग-अलग उपयोगकर्ता व्यवहार एक ही एल्गोरिदम में परिवर्तित हो जाते हैं।

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

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

फिर मैंने उनसे पूछा: "आप ऐसा क्यों कर रहे हैं?"

जवाब ने मुझे झकझोर दिया: “इसलिए मैं कभी नहीं भूलूंगा कि यहाँ कुछ और काम करता है, क्योंकि यहाँ कुछ और नहीं वर्णित है। ”

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

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

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

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

यह पता चला कि इसी तरह की स्थितियों में, डेनिस निकिता की तुलना में निकिता के दृष्टिकोण को सही करने में बहुत अधिक समय खर्च करता है, लेकिन डेनिस को अपने कोड के साथ ऐसी कोई समस्या नहीं है।

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

डेनिस, उनकी इस विशेषता को जानते हुए, यह सुनिश्चित करने की कोशिश करता है कि डिबग करने के लिए कुछ भी नहीं है।
निकिता सिर्फ कोड लिखती है, क्योंकि लगता है उसके पास सोचने के लिए कुछ नहीं है।

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

विकी पर, वैसे, en.wikipedia.org/wiki/Separation_of_concerns के समान कुछ है, लेकिन मुझे यकीन नहीं है कि अगर यह ठीक है तो यह क्या है।

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

UPD2 : धन्यवाद zloddey , शायद यह एसआरपी है