🧗🏾 ✔️ 🚲 कोड की गुणवत्ता 🐺 ✝️ 🕺🏻

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

प्रत्येक डेवलपर अनुभव के आधार पर अपने तरीके से गुणवत्ता को समझता है। ज्यूस और लेड के विचार अलग हैं, और इससे असहमति होती है। व्यक्तिगत परियोजनाओं के लिए प्रत्येक टीम अपने तरीके से कोड का मूल्यांकन करती है। टीम को अद्यतन किया जा रहा है, डेवलपर्स निकल रहे हैं, टीम के नेता बदल रहे हैं - गुणवत्ता की परिभाषा बदल रही है। Tinkoff.ru के इवान बोटानोव ( स्ट्रेसोइड ), फ्रंट-डेवलपर, एंगुलर पर एक ऑनलाइन ट्यूटर, बैठकों और सम्मेलनों में एक वक्ता, यूट्यूब पर एक ट्यूटर और कभी-कभी कंपनियों में एक टीम के कोच, इस समस्या को हल करने में मदद करने की कोशिश करेंगे।

फ्रंटएंड कॉन्फ पर इवान की रिपोर्ट की व्याख्या करने में , हम रीडायबिलिटी, नामकरण, घोषणात्मकता, कोड शैली के बारे में बात करते हैं, और अप्रत्यक्ष रूप से जूनून और लीड्स के संबंधों पर स्पर्श करते हैं: गलतियों, रेक और टाइमलाइड्स का "जलना"।

डिस्क्लेमर: खुद को मानसिक रूप से तैयार करें, पाठ में बहुत सारे बुरे कोड होंगे, जो एक "विशेष" साइट से लिए जाएंगे।

थोड़ा सा इतिहास

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

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

शुरू करने से पहले, मैं सवाल पूछूँगा: "प्रोजेक्ट को विकसित करने से रोकने के लिए बस को कितने प्रोग्रामर को उतारना चाहिए?" । सही उत्तर: हर कोई।

बस फैक्टर क्या है?

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

आप कहेंगे कि पीट होना कितना अच्छा है! हर कोई उसे प्यार करता है, उसकी सराहना करता है, उसकी जरूरत है।

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

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

गुणवत्ता कोड बस संख्या को बढ़ा देता है।

पठनीयता

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

खुद के लिए, मैंने रैखिक कोड शब्द की पहचान की है - यह कोड है जिसे एक किताब की तरह पढ़ा जा सकता है।

रैखिक कोड को बाएं से दाएं, ऊपर से नीचे तक पढ़ा जाता है, पहले लिखे गए कोड पर वापस जाने के बिना।

ऐसे कोड का एक उदाहरण:

list.forEach((element1) => { if (element1.parent_id == null) { output.push(element1); list.forEach((element2) => { if (element2.parent_id == element1.id) { output.push(element2); list.forEach((element3) => { if (element3.parent_id == element2.id) { output.push(element3); list.forEach((element4) => { if (element4.parent_id == element3.id) { output.push(element4); } }) } }) } }) } })

यह कोड रैखिक है, लेकिन इसकी एक और समस्या है - यह बहुत भारी है। इसलिए, हमें घोंसले के शिकार की भी निगरानी करनी चाहिए।

Nonlinear कोड उदाहरण:

 if(!brk && html.childNodes[0].value && html.childNodes[0].max) { if(clear) html.childNodes[0].value = 1; else if(html.childNodes[0].value <= html.childNodes[0].max) { ++ html.childNodes[0].value; if(brk) { for(id = 1; id < html.childNodes.length; ++ id) findActive(html.childNodes[id], true); html.parentNode.className = ""; } return null; } else { html.parentNode.className = "Ready"; html.className = ""; return html; } }

यदि हम वह सब छोड़ देते हैं जो अतिश्योक्तिपूर्ण है और यह पता लगाने के लिए कि क्या रैखिकता को तोड़ता है, तो हम कुछ इस तरह देखेंगे:

 if (condition) { return; } else { return; }

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

नेस्टिंग को कम करने और रैखिक कोड कैसे प्राप्त करें?

शर्तों को मिलाएं । यह सबसे सरल बात है जो हम कर सकते हैं - नेस्टेड अगर मैं हालत में गठबंधन कर सकता हूं और घोंसले को थोड़ा कम कर सकता हूं।

यह था:

 if (isUser()) { if (isAdmin()) { console.log('admin'); } }

यह बन गया:

 if(isUser() && isAdmin()) { console.log('admin'); }

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

यह था:

 if (isAdmin()) { return admin; } else { return user; }

यह बन गया:

 if (isAdmin()) { return admin; } return user;

वादा श्रृंखला लागू करें । यह एक विशिष्ट प्रोटेक्टर कोड है। मैंने E2E परीक्षण इतने लंबे समय से पहले नहीं लिखा था, और इस तरह के कोड ने मेरी आंखों को चोट पहुंचाई:

 ptor.findElement(protractor.By.id('q01_D')).click().then(() => { ptor.findElement(protractor.By.id('q02_C')).click().then(() => { ptor.findElement(protractor.By.id('q03_D')).click().then(() => { console.log('done'); }); }); })

वादा श्रृंखला के साथ, कोड बदल जाता है:

 ptor.findElement(protractor.By.id('q01_D')).click() .then(() => { return ptor.findElement(protractor.By.id('q02_C')).click(); }) .then(() => { return ptor.findElement(protractor.By.id('q03_D')).click(); }) .then(() => { console.log('done'); });

यदि हम एरो फ़ंक्शन के ज्ञान का उपयोग करते हैं, तो हम यह कर सकते हैं:

 ptor.findElement(protractor.By.id('q01_D')).click() .then(() => ptor.findElement(protractor.By.id('q02_C')).click()) .then(() => ptor.findElement(protractor.By.id('q03_D')).click()) .then(() => console.log('done'));

यह पठनीय, घोषित, सुंदर है - सब कुछ स्पष्ट रूप से दिखाई देता है।

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

 Observable.of(1,2,3) .subscribe(item => { item += 2; Observable.of(item) .subscribe(element => { element += 1; }) })

और यह वास्तव में वयस्क परियोजनाओं को प्रभावित करता है। आप यह कर सकते हैं:

 Observable.of(1,2,3) .mergeMap(item => Observable.of(item + 2)) .mergeMap(element => Observable.of(element + 1)) .subscribe()

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

नेस्टेड टर्नरी ऑपरेटर

मेरी राय में, कोड में पाया जा सकता है सबसे खराब नामांकित टर्नरी ऑपरेटरों है । ब्लॉक सशर्त बयानों पर उन्हें फिर से लिखें, कोशिश करें कि उनका उपयोग न करें। हम अंतर्निहित स्थितियों के बारे में बिल्कुल भी बात नहीं करेंगे - यह एक विफलता है।

नेस्टेड टर्नरी ऑपरेटरों और निहित स्थितियों का एक उदाहरण:

 arr.length > 0 ? arr[1] == 1 ? arr[1] = 2 : arr[1] = 1 : console.log('empty arr'); !a && b && func()

मैंने 5 मिनट में यह सरल टर्नरी लिखी। इसमें सरणी की लंबाई और कुछ ऑपरेशन हैं, लेकिन इसे पढ़ना मुश्किल है, क्योंकि कहीं एक प्रश्न, कहीं और - सब कुछ स्पष्ट नहीं है। मल्टी-लाइन नेस्टेड टर्नरी ऑपरेटरों का उपयोग करके इस कोड को फिर से लिखा जा सकता है:

 arr.length > 0 ? arr[1] === 1 ? arr[1] = 2 : arr[1] = 1 : console.log('empty arr');

आप कहेंगे:

- ठीक है, ठीक है!
- देखा?
- यह दिखाई दे रहा है!

और आप इसको क्या कहते हैं:

 return query instanceof RegExp ? (function () { fn.each(function (id) { if (id.match(query)) { seatSet.push(id, this); } }); return seatSet; })() : (query.length == 1 ? (function (character) { //user searches just for a particual character fn.each(function () { if (this.char() == character) { seatSet.push(this.settings.id, this); } }); return seatSet; })(query) : (function () { //user runs a more sophisticated query, so let's see if there's a dot return query.indexOf('.') > -1 ? (function () { //there's a dot which separates character and the status var parts = query.split('.'); fn.each(function (seatId) { if (this.char() == parts[0] && this.status() == parts[1]) { seatSet.push(this.settings.id, this); } }); return seatSet; })() : (function () { fn.each(function () { if (this.status() == query) { seatSet.push(this.settings.id, this); } }); return seatSet; })(); })() );

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

नामकरण

एक और बुरा कोड:

 var _0x30119c = function() { var _0x3af68e = { 'data': { 'key': 'cookie', 'value': 'timeout' }, 'setCookie': function(_0x3543f3, _0x13e5c1, _0x586dac, _0x1c9d63) { _0x1c9d63 = _0x1c9d63 || {}; var _0x47b83f = _0x13e5c1 + '=' + _0x586dac; var _0xae3be = 0x0; for (var _0xae3be = 0x0, _0x5d2845 = _0x3543f3['length']; _0xae3be < _0x5d2845; _0xae3be++) { var _0x440369 = _0x3543f3[_0xae3be]; _0x47b83f += ';\x20' + _0x440369; var _0x411875 = _0x3543f3[_0x440369]; _0x3543f3['push'](_0x411875); _0x5d2845 = _0x3543f3['length']; if (_0x411875 !== !![]) { _0x47b83f += '=' + _0x411875; } } _0x1c9d63['cookie'] = _0x47b83f; } };

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

नामकरण में आपको क्या विचार करने की आवश्यकता है

CamelCase संकेतन का उपयोग करें: camelCaseNotation । लिप्यंतरण नहीं है, विधियों के सभी नाम केवल अंग्रेजी में हैं : ssylka, vikup, tovar, yslyga या checkTovaraNaNalichieTseni एक विफलता है। उत्तरार्द्ध, वैसे, मैंने लिखा था जब मैं सिर्फ कार्यक्रम शुरू कर रहा था।

कोई आइटम, डेटा, एल, एचटीएमएल, गिरफ्तारी , खासकर जब सरणियों के माध्यम से पुनरावृति। उदाहरण के लिए, किसी उत्पाद या ऑफ़र के लिए, अनुकूल नाम चुनें: product, offer, etc वस्तु और उत्पाद के बीच अंतर इतना महान नहीं है, लेकिन पठनीयता अधिक है। यहां तक कि अगर आपके पास एक-लाइन फ़ंक्शन है जो कुछ प्लस करता है, तो व्यापार-अनुकूल नाम पठनीयता बढ़ाएगा।

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

बड़े अक्षरों में स्थिरांक : const BLOCK_WIDTH = 300; , और पूंजीकृत मामले में वर्ग के नाम: class SomeClass । मैं टाइपस्क्रिप्ट में लिखता हूं और वहां सब कुछ स्पष्ट है, ईएस 6 में सब कुछ स्पष्ट है, लेकिन ऐसी विरासत परियोजनाएं भी हैं, जिनमें new ऑपरेटर के साथ सभी फ़ंक्शन क्लास कैपिटल में लिखते हैं।

कोई एक अक्षर चर : u = user । यह मेरे लिए एक संदर्भ है - नहीं। स्पष्ट रूप से लिखें, अर्थात, कार्यात्मक रूप से व्यापार करें। चेक विधि बनाने की कोई आवश्यकता नहीं है, जो कुछ की जाँच करता है, लेकिन जो स्पष्ट नहीं है। विधियों के addProductToCard(); sendFeedback() नाम लिखें: addProductToCard(); sendFeedback() addProductToCard(); sendFeedback() ।

अनिवार्य

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

यह सरल लेकिन अनिवार्य कोड है जिसमें लूप, वैरिएबल है। यह स्पष्ट नहीं है कि उन्हें यहां क्यों जोड़ा गया है।

 for (let i = 0; i >= 10; i++) { const someItem = conferences[i]; const prefixString = 'Hello '; if (someItem === 'Frontend Conf') { console.log(prefixString + someItem); } }

इंपीरियल कोड समस्याएं : बहुत सारे वैरिएबल, इन वैरिएबल्स के बहुत सारे मेंटेनेंस कंस्ट्रक्शन और ढेर सारे कमेंट्स, क्योंकि इन वैरिएबल्स को किसी तरह बताने की जरूरत है - आप वैरिएबल नहीं बना सकते हैं और इसके बारे में भूल जाते हैं। यह सब कोड की पठनीयता को प्रभावित करता है।

निवेदक

घोषित शैली बदल गई है। हम जावास्क्रिप्ट में लिखते हैं और यह हमारे लिए उपलब्ध है। घोषणात्मक शैली इस तरह दिखती है:

 conferences .filter(someItem => someItem === 'Frontend Conf') .forEach(someItem => console.log('Hello' + someItem));

यह समान रूप से समान है, लेकिन बहुत सरल और अधिक समझने योग्य है।

एक घोषणात्मक कोड के लाभ

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

समस्या तब शुरू होती है जब बहुत अनुभवी डेवलपर्स विश्वविद्यालय से नहीं आते हैं जहां उन्होंने पास्कल का अध्ययन किया और इस तरह लिखा:

 const prefix = 'Hello '; conferences .forEach(someItem => { if (someItem === 'Frontend Conf') { const result = prefix + someItem; console.log(result) } });

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

चर बनाना

चरों के लिए वैरिएबल न बनाएं - यह एक बुरा विचार है। जब मुझे डेवलपर्स से पता चला कि वे ऐसा क्यों कर रहे हैं, तो मैंने सुना:

- खैर, यह पठनीयता बढ़ाता है!

यहाँ पठनीयता क्या बढ़ जाती है - const username = user.name ? यदि आप एक वैरिएबल बनाना चाहते हैं, तो नाम को महत्व दें। उदाहरण के लिए, हमारे पास एक नियमित अभिव्यक्ति है:

 const somePattern = /[0-9]+/; str.split(somePattern); const someResult = a + b - c;

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

वैरिएबल बनाने के लिए वैरिएबल बनाना इसके लायक नहीं है।

अस्पष्ट चर ओवरराइड

मान लीजिए कि हमने एक element चर बनाया है, जिसके नाम से यह स्पष्ट नहीं है कि यह क्या है। हमने DOM element लिखा है, किसी कारण से एक सरणी में अपना ओवरराइड लिखा है, और छोड़ दिया है:

 let element = document.getElementById('someId'); arr.forEach(item => { // ... //      // ... element = document.getElementById('someItem') if (typeof item === 'string') { let element = document.getElementById('some' + item); element.appendChild(); } });

सब कुछ ठीक है, चला गया, भूल गया। पेट्या के बाद, जो हमारी टीम में काम करती है, आई और आई ब्लॉक को जोड़ा। यह क्या है? बस चर को फिर से परिभाषित किया, और छोड़ दिया। और दायरा पहले से ही अलग है। जब अगला डेवलपर इस कोड को समझने की कोशिश करता है, खासकर यदि विधि बड़ी है, तो यह कुछ someId या someItem प्रतीक्षा करेगा, और वहां यह बिल्कुल नहीं है। यह एक ऐसी जगह है जहाँ आप समस्या की तलाश में बहुत समय खो सकते हैं। हम एक debugger लिखेंगे, एक brake point , देखें कि क्या है - सामान्य तौर पर, ऐसा नहीं लिखें।

तरीकों में विभाजन

हम संक्षेप में विभाजन के तरीकों पर विचार करते हैं और आसानी से अमूर्तता की ओर बढ़ते हैं।

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

कोड प्रतिरूपकता

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

अमूर्तता के पीछे छिपना

उदाहरण के लिए, एक कोड है जो एक बटन बनाता है, उसे एक आईडी प्रदान करता है, एक वर्ग और उस पर क्लिक करता है - सब कुछ सरल है।

 const element = document.createElement('button'); element.id = 'id_button'; element.classList = 'red'; document.body.appendChild(element); element.click();

आप बटन कोड में एक फ़ंक्शन जोड़ सकते हैं, इसे लपेट सकते हैं, और बटन बनाते समय createButton फ़ंक्शन का उपयोग कर createButton :

 const.button = createButton('id_button'); button.click(); function createButton((id') { element = document.createElement('button'); element.id = id; element.classList = 'red'; document.body.appendChild(element); return element; }

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

 button.component.js let button = createButton('id_button'); button.click();

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

 button.helpers.js function createButton(id) { let button = document.createElement('button'); button.id = id; button.classList = 'red'; document.body.appendChild(element); return button; }

टाइपिंग

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

कोड बदबू आ रही है

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

कोड शैली

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

यदि आप किसी विशिष्ट तकनीक या ढांचे का उपयोग करते हैं, तो उनके पास आमतौर पर अपनी स्वयं की कोड शैली भी होती है, जो देखने लायक होती है। उदाहरण के लिए, कोणीय में, यह कोणीय शैली गाइड , या Airbnb से प्रतिक्रिया / JSX शैली गाइड है।

यह हमारी कोड शैली का एक उदाहरण है।

यहां चर बनाने के लिए एक अनुभाग है, और यह वर्णन करता है कि कैसे नहीं करना है और कैसे करना है।

तकनीकी ऋण

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

टेक ऋण बैसाखी और कम गुणवत्ता वाला कोड बनाता है।

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

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

कोष

चलिए कमिट मैसेज पर चर्चा करते हैं। तस्वीर वास्तविक संदेशों के उदाहरण दिखाती है जो मैंने विभिन्न परियोजनाओं में देखी थी। आपको लगता है कि उनमें से कौन सा जानकारीपूर्ण है?

सही उत्तर

जानकारीपूर्ण संदेश ब्लॉक में हैं, लेकिन "एक सुविधा जोड़ी", "एक बग को ठीक किया गया" - जानकारीपूर्ण नहीं हैं।

संदेश दें

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

Gitflow

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

उपकरण

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

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

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

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

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

फ़ॉर्मेटर आपको कोड को एकल शैली में रखने की अनुमति देता है।

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

— error tracking runtime. , , . - — . Error tracking DOM-, , . Sentry , TrackJS , .

Sentry, . क्यों? , Sentry. .

, , : «, iOS, , , Android — , iOS».

Sentry StackTrace — , .

Sentry. , — : . , , : « , ?». — . , . , — «» .

-

- , .

.
— .
.
. , frontend-developer Tinkoff.ru.
Code style, . — .
— . , , .
Git Flow — , . — .
— , . , .

. « » , — , . . , , , . , , .

: Twitter Facebook .

— Frontend Conf . ? Frontend Conf ++ : , , .

— FrontendConf ++. — , . , 27

कोड की गुणवत्ता