निम्न-गुणवत्ता कोड से सहमत हैं?

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





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



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



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



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



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



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



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



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



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



लेख के लेखक, डेनिस मिलर, सॉफ्टवेयर विकास के क्षेत्र में चुस्त तरीकों पर एक ट्रेनर और स्वतंत्र सलाहकार हैं। रुचि का मुख्य क्षेत्र: विकास प्रक्रियाओं में सुधार और प्रोग्रामर के लिए कोड की गुणवत्ता में सुधार।