अच्छा कोड अभ्यास

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

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

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

1. सादगी

यहाँ, सब कुछ हमारे लिए बाहर सोचा है - का एक बड़ा सिद्धांत है KISS , साथ ही अल्बर्ट आइंस्टीन के सूत्र "सब कुछ हो सके, आसान कहा जाना चाहिए, लेकिन नहीं सरल" है, जो हम सभी के पालन करना चाहिए।

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

इसके अलावा, एक आदर्श प्रणाली पर TRIZ की स्थिति को समझने के लिए, हम कह सकते हैं कि एक आदर्श कोड वह है जो मौजूद नहीं है, और जिस कार्य को हल करना चाहिए वह सफलतापूर्वक हल हो गया है। जाहिर है, यह आदर्श (किसी भी अन्य की तरह) व्यवहार में अप्राप्य है, लेकिन यह डेवलपर के दिमाग को सही दिशा में निर्देशित करने में सक्षम है।

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

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

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

2. वैचारिक

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

मुझे एक सरल सादृश्य के बारे में बताएं कि मेरा क्या मतलब है:
कल्पना करें कि आपके पास एक कार्य है - सभी संख्याओं को 2 से 9 तक गुणा करने के परिणामों को एक-दूसरे द्वारा याद करना। आप बस लाइन में लिख सकते हैं: 2x2 = 4, 2x3 = 6, ..., 3x7 = 21, ... आदि, और फिर इस पाठ को याद करना शुरू करें।
औपचारिक रूप से, इसका उपयोग किया जा सकता है, और इसे सीखा भी जा सकता है। लेकिन एक और अधिक व्यावहारिक विकल्प है - "टेबल" की अवधारणा का उपयोग करने के लिए - अर्थात एक डेटा संरचना जो एक्स और वाई मूल्यों की सूची को परिभाषित करती है, जल्दी से अपने चौराहे के बिंदुओं को निर्धारित करने की क्षमता और एक पूर्व निर्धारित सूत्र का उपयोग करके इन बिंदुओं के मूल्य (इस मामले में, जेड = एक्स * वाई)। नतीजतन, हमें बचपन से हर किसी के लिए एक गुणन तालिका प्राप्त होती है, जो पाठ में वर्णों की संख्या की प्रतिबंधात्मक अर्थव्यवस्था के अलावा कई अन्य फायदे हैं:

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

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

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

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

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

3. कार्यक्षमता की विशिष्टता (खुद को दोहराएं नहीं)

सिद्धांत "खुद को दोहराएं नहीं" (संक्षिप्त DRY) हमें बताता है कि सिस्टम की प्रत्येक कार्यात्मक इकाई, चाहे वह कोड का एक तार्किक ब्लॉक हो, एक फ़ंक्शन, या एक पूरी कक्षा, कोड में केवल एक बार प्रतिनिधित्व किया जाना चाहिए।

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

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

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

5-10 लाइनों से कोड के कई समान ब्लॉक हैं, केवल कुछ स्थितियों और चर में भिन्न होते हैं, लेकिन आप अभी तक निश्चित नहीं हैं कि उन्हें किसी फ़ंक्शन में लपेटना सबसे अच्छा कैसे है? छोरों का प्रयोग करें।

सुनिश्चित नहीं है कि नई विधि के कोड को डालने के लिए कौन सी कक्षा / वस्तु है? बस एक फ़ंक्शन बनाएं और इसे प्लगइन लाइब्रेरी में डालें जब तक कि आपके पास सिस्टम के विकसित होने के बारे में अधिक पूरी जानकारी न हो।

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

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

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

4. पठनीयता

• चर, कार्यों, वर्गों, और विधियों के नामों का उपयोग करें जो उनके नाम का सार सबसे अच्छा वर्णन करते हैं। एकल-वर्ण चर से बचें (सिवाय, शायद, टाइप I, n, k, और हमेशा नहीं के लूप काउंटर), और var1, function2, आदि जैसे नाम। अन्य चरम पर नहीं जाएं - CreateTextDocumentWithAttachedFiaViaHTTP जैसे नाम - भी पठनीयता में बहुत सुधार नहीं करते हैं। इष्टतम शीर्षक लंबाई: 1-3 शब्द।
• नामकरण कार्यों और विधियों, साथ ही साथ उनके तर्कों और वापसी मूल्यों की संरचना में सुसंगत होने का प्रयास करें। PHP डेवलपर्स की गलतियों को न दोहराएं (उदाहरण के लिए, सरणियों के साथ काम करने के लिए कार्यों के नाम हैं array_filter, preg_grep, array_unique, in_array, Sort, current etc.)
• जादू नंबर का उपयोग न करें। केवल एक अपवाद है - आप 150% सुनिश्चित हैं कि कोई भी आपके अलावा कभी भी इस कोड को नहीं देखेगा, और आप खुद भी कुछ वर्षों के बाद इसके समर्थन को स्वीकार नहीं करेंगे, दर्द से याद करते हुए कि "574" क्या है।
• भाषा संरचनाओं को एक-दूसरे से अलग करते समय रिक्त स्थान और लाइन ब्रेक पर न बचाएं। याद रखें कि साहित्यिक अंग्रेजी (रूसी में) के रूप में, यह एक स्थान के साथ अल्पविराम के बाद पाठ को अलग करने, और एक खाली लाइन के साथ अलग पैराग्राफ बनाने के लिए प्रथागत है। प्रोग्राम कोड पर समान नियम लागू होते हैं।
• उपलब्ध मानक भाषा निर्माण का सबसे संक्षिप्त उपयोग करें। उदाहरण के लिए, एक लाइन पर फिट होने वाले कोड के ब्लॉक के लिए if-else के बजाय एक टर्नरी ऑपरेटर। जब तक आपका कोड प्रतियोगिता के लिए तैयार नहीं किया जाता है, तब तक डेवलपर्स के थोक के लिए गैर-मानक तरीके से ऑपरेटरों का उपयोग न करें।
• कोड के अप्रकाशित वर्गों पर टिप्पणी करें। स्पष्ट पर टिप्पणी न करें। आंतरिक "साक्ष्य के निर्धारक" को प्रशिक्षित करने के लिए, यह महीने में एक बार सहकर्मियों को कोड दिखाने या कम से कम सिर्फ परिचित प्रोग्रामर को दिखाने में मदद करता है।

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

मैं निष्कर्ष में क्या कह सकता हूं

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

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

अगर मैं कुछ याद करता हूं या कहीं गलत था - टिप्पणियों में रचनात्मक आलोचना को दृढ़ता से प्रोत्साहित किया जाता है।