आप इसे या एक कहानी से नफरत करते हैं कि अच्छे कोड को कैसे देखना चाहिए

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

कोड काम करना चाहिए

हम कोड से क्या उम्मीद करते हैं, इसके बारे में बात करते हैं। खैर, शुरुआत के लिए, यह काम करना चाहिए।

यह स्पष्ट है, निश्चित रूप से, लेकिन हम में से प्रत्येक ने एक बार कोड की कोशिश की या सफलतापूर्वक लॉन्च किया, जो यहां तक ​​कि नहीं जा रहा था, इसलिए हंसते नहीं थे। दूसरा बिंदु - कोड गलत स्थितियों के साथ सही ढंग से काम करना चाहिए। वह है त्रुटियों को पकड़ना। लेकिन चलो पहले बिंदु पर वापस जाएं और इसके बारे में थोड़ा बात करें।

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

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

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

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

अब बात करते हैं Shit Happens की। तो, हमारे पास कोड है, यह भी काम करता है। बल्कि, यह "काम करता है।" आइए एक साधारण उदाहरण देखें:

public string Do(int x) { using (WebClient xx = new WebClient()) { return xx.DownloadString("https://some.super.url"); } } 

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

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

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

कुल:

• पहले कोड का काम करें,
• फिर उसे अच्छा बनाओ
• किनारे के मामलों और त्रुटि से निपटने के बारे में मत भूलना।

अब कोड सपोर्ट की बात करते हैं

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

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

सामान्य तौर पर, पढ़ने में आसानी नामकरण और संरचना के बारे में होती है। संस्थाओं के नाम - वर्ग, विधियाँ, चर, सरल, पठनीय और अर्थपूर्ण होने चाहिए। हमारे पिछले उदाहरण को लें।

 public string Do(int x) { using (WebClient xx = new WebClient()) { return xx.DownloadString("https://some.super.url"); } } 

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

फिर से, एक उदाहरण के लिए, अपना कोड लें जिसे आपने एक महीने पहले लिखा था और इसे धाराप्रवाह पढ़ने की कोशिश करें। क्या आप समझते हैं कि वहाँ क्या चल रहा है? यदि हां, तो मैं आपको बधाई देता हूं। यदि नहीं, तो आपको कोड की पठनीयता में समस्या है।

सामान्य तौर पर, इस तरह के एक दिलचस्प उद्धरण है:

"कंप्यूटर विज्ञान में केवल दो कठिन चीजें हैं: कैश अमान्यकरण और नामकरण की चीजें।" © फिल कार्लटन

कंप्यूटर विज्ञान में केवल दो जटिल चीजें हैं: कैश अमान्यकरण और नामकरण।

उसे याद रखें जब आप अपनी संस्थाओं को नाम देते हैं।

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

अपने सहयोगियों और खुद पर दया करें। एक हफ्ते के बाद, आपको इस कोड को ठीक करने या इसमें कुछ जोड़ने के लिए शाब्दिक रूप से उतारा जाएगा। इससे बचना इतना मुश्किल नहीं है:

• छोटे कार्य लिखें,
• बहुत सारे ब्रांचिंग या नेस्टिंग से बचें
• कोड के तार्किक ब्लॉकों को अलग-अलग कार्यों में अलग करें, भले ही आप उन्हें पुन: उपयोग न करने जा रहे हों,
• इसके बजाय बहुरूपता का प्रयोग करें

अब एक और जटिल बात करते हैं - वह अच्छा कोड बदलना आसान है। कीचड़ की बड़ी गेंद को कौन जानता है? यदि कोई परिचित नहीं है - चित्र को देखें।

प्रत्येक मॉड्यूल प्रत्येक मॉड्यूल पर निर्भर करता है और एक जगह अनुबंध में बदलाव से ध्रुवीय लोमड़ी के आगमन या कम से कम, बहुत लंबे डिबग के लिए नेतृत्व करने की संभावना है। सैद्धांतिक रूप से, इससे निपटना काफी सरल है - अपने कोड पर अपने कोड की निर्भरता को कम करें। किसी भी कार्यान्वयन विवरण के बारे में आपका कोड जितना कम जानता है, उतना ही इसके लिए बेहतर होगा। लेकिन व्यवहार में, यह बहुत अधिक जटिल है, और कोड की पुन: जटिलता की ओर जाता है।

सुझावों के रूप में, मैं इसे इस प्रकार रखूंगा:

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

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

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

कुल:

• उचित नामकरण
• अच्छी संरचना
• एकरूपता।

कोड काफी उत्पादक होना चाहिए

चलो थोड़ा ठंडा है। अगली आवश्यकता जो हम विचार करेंगे कि कोड काफी उत्पादक होना चाहिए।

मुझे "पर्याप्त" शब्द से क्या मतलब है? शायद सभी ने सुना है कि समय से पहले अनुकूलन बुराई है, वे पठनीयता और जटिल कोड को मारते हैं। यह सच है। लेकिन यह भी सच है कि आपको अपने उपकरण को जानना चाहिए और उस पर नहीं लिखना चाहिए ताकि वेब मेल क्लाइंट कोर I7 को 60% तक लोड कर दे। आपको उन विशिष्ट समस्याओं को जानना चाहिए जो प्रदर्शन की समस्याओं को जन्म देती हैं और कोड लिखने के चरण में भी उनसे बचती हैं।

आइए अपने उदाहरण पर वापस आते हैं:

 public string GetUserName(int userId) { using (WebClient http = new WebClient()) { return http.DownloadString("https://some.super.url"); } } 

इस कोड में एक समस्या है - नेटवर्क पर तुल्यकालिक डाउनलोड। यह एक I / O ऑपरेशन है जो हमारे प्रवाह को तब तक मुक्त करता है जब तक कि इसे निष्पादित नहीं किया जाता है। डेस्कटॉप अनुप्रयोगों में, यह एक झूलने वाला इंटरफ़ेस और सर्वर अनुप्रयोगों में, सर्वर को अनुरोधों की संख्या की बेकार स्मृति आरक्षण और थकावट के लिए ले जाएगा। ऐसी समस्याओं को जानने के बाद, आप पहले से ही अधिक अनुकूलित कोड लिख सकते हैं। और ज्यादातर मामलों में यह पर्याप्त होगा।

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

अब बात करते हैं परीक्षणों की।

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

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

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

ज्यादा जरूरत के बिना कवर न करें

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

खैर, यह मूल रूप से है।

संक्षेप में देना। अच्छा कोड है

• कार्य कोड
• पढ़ने में आसान
• बदलने में आसान
• काफी तेज है
• और सही मात्रा में परीक्षणों में शामिल किया गया।

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