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

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

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

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

यह कैसा दिखता है

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

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

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

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

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

क्यों खराब है

भाग में, मैंने इसके बारे में थोड़ा अधिक लिखा था, लेकिन अभी भी काफी बड़ी संख्या में कारक हैं जिन्हें कहा जाना चाहिए।

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

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

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

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

निष्कर्ष सरल है: "डंप" एक बुराई है जिसे लड़ा जाना चाहिए।

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

इससे कैसे निपटा जाए

इस कोड में आने पर समझने वाली पहली और सबसे महत्वपूर्ण बात यह है कि "यह सामान्य है" ।

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

यह संभावना है कि छात्र बेंच से सीधे आपकी टीम में ले जाने वाले नवागंतुक भी "डंप" का दुरुपयोग करते हैं।

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

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

यदि आपकी टीम में एक अनुभवी विशेषज्ञ है जो अच्छी वास्तुकला के "आत्मा और अक्षर" को समझता है, सही अपघटन, पारदर्शी कोड और अच्छे रूप के अन्य नियम हैं, तो पहले निरीक्षण उसे सौंपा जाना चाहिए।

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

यदि आपकी टीम में शुरुआती लोग हैं और ऐसा कोई विशेषज्ञ नहीं है, तो आपको उसे स्वयं शिक्षित करना होगा।

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

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

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

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

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

उसे समझाओ!