एचएच फ्रंट-एंड कोड गुणवत्ता

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

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

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

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

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

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

• वह अधिक लचीला है
• इसके लिए सभी प्रकार के प्लगइन्स हैं।
• विभिन्न कंपनियों के पास तैयार-तैयार कॉन्फ़िगरेशन हैं

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

लेकिन दुर्भाग्य से, एस्क्लिंट ने कोड स्वरूपण के सभी पहलुओं को कवर नहीं किया, इस समस्या को हल करने के लिए प्रीटीयर जोड़ा गया था ।

सौभाग्य से, एस्लिंट और प्रीटियर एक साथ अच्छी तरह से काम करते हैं, आपको बस एस्लिंट-प्लगइन- प्रेटियर और एस्लिंट-कॉन्फिग- .eslintrc और फिर इस तरह से .eslintrc ठीक .eslintrc होगा:

 ... "plugins": ["prettier"], "extends": ["@hh.ru/eslint-config", "prettier"], "rules": { "prettier/prettier": ["error"], ... 

ठेस के लिए यह सब जारी करने से पहले, पूरे कोड आधार के माध्यम से जाना और नए नियमों का पालन करने के लिए इसे सही करना आवश्यक था, यह बिल्कुल भी मुश्किल नहीं निकला: yarn eslint --fix <path_to_js>

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

• सभी js और jsx की जाँच की जाती है और एस्लिंट और प्रेटियर का उपयोग करके ऑटो-फिक्स्ड किया जाता है।
• कम के लिए, स्टाइललिंट का उपयोग किया जाता है।
• अजगर flake8 के लिए।

संशोधित फ़ाइलों का उपयोग करते समय डेवलपर की मशीन पर जाँच की जाती है, लिंट-स्टेज्ड का उपयोग करते हुए, यहाँ हमारा .lintstagedrc :

 { "*.{js,jsx}": ["eslint --fix", "git add"], "*.less": "stylelint", "*.py": "flake8", "package.json": "bash -c 'yarn check-versions && yarn install --frozen-lockfile'", } 

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

समीक्षा के बाद, डॉक कंटेनर को इकट्ठा किया जाता है, विधानसभा के दौरान सभी ऑटोटेस्ट और लिंटर को चलाया जाता है। अब पूरी विधानसभा प्रक्रिया में लगभग 7.5 मिनट लगते हैं, जबकि अब हमारे पास लगभग 1000 js और 650 कम फाइलें हैं। यह सब आवश्यक है, क्योंकि मशीन पर स्थानीय रूप से आप --no-verify का उपयोग कर छोड़ सकते --no-verify , और गिटब में टिप्पणियां कार्य को अवरुद्ध नहीं करती हैं। विधानसभा को धोखा देने से काम नहीं चलता।

ऑटोटेस्ट्स पास करने के बाद, मैन्युअल परीक्षण शुरू होता है। यदि परीक्षक को एक बग नहीं मिलता है, तो कार्य ठेस पर जाता है।

यदि किसी भी स्तर पर कोई त्रुटि होती है, तो कार्य पुनरीक्षण के लिए वापस आ जाता है।

परिणाम था:

• कोड लिखना आसान और तेज़ है।
• समीक्षा करना आसान है
• विज़ार्ड में हमेशा एक गुणवत्ता कोड होता है
• कम विवाद, ज्यादा खुशी

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

• कस्टम पृष्ठ अनुकूलन
• बुनियादी ढाँचा बदल जाता है
• कोडबेस सुधार

सभी उत्पाद टीमों को अपना 70% समय व्यावसायिक कार्यों को विकसित करने में, और 30% कर पर खर्च करना चाहिए - इससे प्रत्येक डेवलपर को बुनियादी ढांचे के कार्यों में संलग्न होने, उत्कृष्ट स्थिति में कोड आधार बनाए रखने और सभी टीमों में परियोजना के बुनियादी ढांचे के बारे में ज्ञान का प्रसार करने का अवसर मिलता है। कर के रूप में, अपनी टीम के कार्यों को करना आवश्यक नहीं है; आप परियोजना के किसी भी हिस्से में कोड लिख सकते हैं। कोई भी कर का सुझाव दे सकता है, यदि यह उपयोगी लगता है, तो इसे बैकलॉग में जोड़ा जाएगा। इसके अलावा, ऐसी आर्किटेक्चर टीमें हैं जो हर समय तकनीकी विशेषताओं से निपटती हैं। यह सब आपको कोड आधार को अद्यतित रखने की अनुमति देता है।