गंदा, साफ, आकांक्षी

गंदा

चलो एक साथ सोचते हैं - स्वच्छ कोड क्या है, और गंदा कोड क्या है? या, जैसा कि अमेरिकी कहते हैं, "बालों वाला कोड", अर्थात्। बालों?

एक साफ कोड एक गंदे से अलग कैसे होता है - या, जैसा कि वे हमारे इंटरनेट पर कहते हैं, "गोवनोकॉड" से? और क्या वास्तव में इसकी जरूरत है, क्या यह साफ कोड है?


आइए पहले परिभाषाएँ प्राप्त करें।

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

हां, हमने सामान्य पैटर्न को परिभाषित करना सीख लिया है, कहते हैं, उन चेहरों में जिन्हें सुंदर माना जाता है। लेकिन क्या हम सुंदरता की स्पष्ट परिभाषा देने के लिए तैयार हैं? मुझे नहीं लगता।

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

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

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

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

बेशक, आप कोड की "पठनीयता" या "समझ" के बारे में एक बहस शुरू कर सकते हैं। ये बिल्कुल औपचारिक रूप नहीं हैं।

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

और यह ओओपी को अच्छी तरह से खोदने और अलग-अलग वर्गों में तर्क को अतिक्रमण करने की कोशिश करने के लिए है ताकि आपको दर्जनों स्क्रीन पर विशाल कोड क्लच को पार्स करके या प्रक्रियाओं और कार्यों के कनेक्शनों को भ्रमित करके अपने मस्तिष्क को तनाव न देना पड़े, जो (वैग) वैश्विक चर का एक गुच्छा के साथ भी काम करता है।

बाकी के साथ स्थिति लगभग समान है: बेशक, यहां तक ​​कि सूचीबद्ध 4 बिंदुओं के बीच भी पारस्परिक रूप से अनन्य पैराग्राफ हैं (आसानी से पठनीय कोड हमेशा आसानी से परिवर्तनशील नहीं होगा, एक्स्टेंसिबिलिटी में आसानी परीक्षण स्वचालन के साथ संघर्ष कर सकती है, आदि) - लेकिन सामान्य तौर पर स्थिति स्पष्ट है।

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

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

स्वच्छ

अब आइए इसका पता लगाने की कोशिश करें - आखिर यह साफ कोड क्यों है? और क्या कोड वास्तव में गंदा और बालों वाला है?

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


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

उदाहरण के लिए

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

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

यही है, इस उपयोगिता को आदर्श रूप से एक या दो बार उपयोग किया जाता है, और फिर बाहर फेंक दिया जाता है। कोड की सफाई यहां पूरी तरह से अप्रासंगिक है।

एक और उदाहरण

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

ऐसा लगता है - सभी में एक पहला उदाहरण दोहराता है। हालांकि, यहां सवाल उठता है: चूंकि परीक्षण प्रक्रिया ऐसी स्थितियों के प्रजनन के लिए प्रदान नहीं करती है, क्या परीक्षण उपकरण के रूप में इस उपयोगिता के आगे विकास की आवश्यकता होगी? क्या यह एक स्वतंत्र अनुप्रयोग बन जाएगा जो नियमित रूप से उपयोग किया जाता है?

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

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

तीसरा उदाहरण

किसी कंपनी के मुख्य सॉफ्टवेयर उत्पाद के लिए एक सॉफ्टवेयर मॉड्यूल का विकास जो कई वर्षों से बाजार में सफलतापूर्वक विकसित हो रहा है।

ऐसा लगेगा कि मॉड्यूल अलग-थलग है, अन्य मॉड्यूल के साथ इंटरैक्शन इंटरफेस परिभाषित हैं। "मैं घुमा-घुमा कर बोलता हूँ, मैं गोवन्कोद लिखना चाहता हूँ।" लेकिन तब एक गंभीर “BUT” पैदा होता है।

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

लेकिन यह सवालों की पूरी सूची नहीं है। और दो से तीन वर्षों में इस मॉड्यूल के साथ कौन काम करेगा? जिसने इसे लिखा है, या किसी और ने?

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

यदि डेवलपर स्वयं इस कोड के साथ काम करेगा - तो और भी। हां, छह महीने में उसे याद नहीं रहेगा कि वह कहां, कहां और कैसे काम करता है! उसे इस कोड को समझना होगा जैसे कि कोड पूरी तरह से विदेशी है। क्या वह खुद के लिए दुश्मन नहीं है?

चौथा उदाहरण

थोड़े समय के लिए थोड़े समय में एक आदेश के लिए एक एप्लिकेशन (वेबसाइट, सरलतम इंटरफ़ेस के साथ डेटाबेस - कुछ भी) का विकास।

एक ओर - कोड और भूल जाओ, आप कुछ भी लिख सकते हैं और जो भी हो, अगर यह केवल काम करता है।

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

लेकिन क्या होगा यदि वह किसी अन्य डेवलपर (कंपनी) की ओर मुड़ता है, उसे परियोजना की गुणवत्ता के बारे में नकारात्मक प्रतिक्रिया मिलती है, और कभी भी "दुष्ट गोवनोकॉडरी" पर नहीं लौटता है, और यहां तक ​​कि अपने दोस्तों को भी सलाह देता है?

मैं ऐसी चीजों के बारे में बात नहीं कर रहा हूं जैसे कर्म की गुणवत्ता और पश्चात की स्मृति।

पाँचवाँ उदाहरण

टीम का विकास

Govnokodirovaniya की पूर्ण रोकथाम का सबसे गंभीर मामला।
टीम विकास के मामले में खराब कोड के प्रति सचेत विकल्प के पक्ष में किसी भी तर्क की कल्पना करना मेरे लिए कठिन है।

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

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

परीक्षण के बारे में क्या? एस्कॉर्ट? कार्यात्मक विस्तार ??

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

आकांक्षा

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

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

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

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

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

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

हमने युवा प्रोग्रामरों के बारे में बात की और सभी गुण पेशेवर विकास की संभावनाओं की गवाही देते हैं।
अंत में, यह महत्व के क्रम में कुछ सरल बिंदुओं पर आ गया:

1) एक अच्छी तरह से काम करने वाला सिर (इसलिए हमारे पास हमेशा तर्क पहेलियाँ होती हैं)
2) उच्च स्तर की आत्म-आलोचना (इसलिए, कोड लिखने और उसमें त्रुटियां खोजने के लिए हमेशा कार्य होते हैं)
3) प्रोग्रामिंग में रुचि (कुछ हद तक महत्वपूर्ण, कार्य सिद्धांत रूप में निर्धारित नहीं हैं)

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

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

और यह अच्छा है अगर वह अभी भी अपने काम में एक जीवंत, गहरी रुचि रखता है। यदि वह लेख और किताबें पढ़ना जारी रखता है "क्योंकि यह दिलचस्प है।" फिर उसके पास एक छोटा मौका नहीं है कि वह जम न सके, लेकिन विकास जारी रख सके।

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

वह कार्यों को "विनिर्देशों के अनुसार सख्ती से" करना शुरू करता है अधिक बार, अधिमानतः पहले से ही परिचित क्षेत्रों से परिचित कार्य। नई भाषाओं, प्लेटफार्मों, अवधारणाओं पर कम ध्यान।

और यह काफी अच्छा, फिट विशेषज्ञ बन जाता है। अक्सर बहुत संकीर्ण नहीं, लेकिन अपेक्षाकृत बहु-विषयक। अच्छी तरह से सम्मानित।

लेकिन यह अपनी मूल क्षमता के शीर्ष पर नहीं पहुंचता है।

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

आह, यह तस्वीर कितनी सुंदर है - एक दूर के एक आंसू को ब्रश करना चाहता है! वह कितना सुंदर है, यह असीम रूप से युवा, जो अपने आध्यात्मिक आवेग के साथ, बहुत आकाश को छूता है, जिसमें उसके सभी मर्मज्ञ टकटकी का उद्देश्य है!

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

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

और नीचे रहें, एक नटखट खुशी के साथ कि वे अपनी खोज में अंतरिक्ष और समय कैसे प्रवेश करते हैं।

और यह जानने के लिए कि कम से कम एक छोटा, कम से कम - उसने मदद की, समर्थन किया, और एक तरफ नहीं खड़ा हुआ, अपने महत्व से अपने उत्साह में जमे हुए, अवमानना ​​की झलक नहीं डाली - "फ़े ... युवा .."