कोणीय अनुप्रयोगों को विकसित करते समय स्टाइलगाइड के बाद के लाभ

2018 के अंत में, समारा में पांडा-मीटअप # 9 फ्रंटेंड हुआ। इस आयोजन में, मैंने खुद को एक नई भूमिका में आजमाया और एक प्रस्तुति दी। मेरा नाम इवगेनी Kholmov है। मैं एक छात्र के रूप में 10 साल पहले प्रोग्रामिंग में आया था। पिछले 5 वर्षों से, मैं प्रमुख रूसी बैंकों में दूरस्थ सेवा प्रणाली विकसित कर रहा हूं, जिनमें से दो साल प्रबंधक के रूप में। इस समय के दौरान, मैंने कई प्रमुख रूसी उद्यम-अनुप्रयोगों के निर्माण में भाग लिया, जो भारी वास्तुशिल्प, एकीकरण और प्रक्रिया समाधान के कांटों से गुजर रहे थे। कई बड़े इंटरनेट बैंकों को विकसित करने के अपने अनुभव के आधार पर, मैंने मितप के मेहमानों से कहा कि यदि आप विकास में एक अच्छी शैली के नियमों का पालन करते हैं तो इससे क्या लाभ होगा। आवाज के आंकड़ों ने दर्शकों को प्रभावित किया। बैठक में भाग लेने वालों ने मुझे सवालों के जवाब दिए। यह संभव है कि Habré के पाठकों के बीच इस विषय पर एक जीवंत प्रतिक्रिया मिलेगी।



आप मेरी प्रस्तुति का वीडियो Youtube पर देख सकते हैं।


और खाबरोवस्क नागरिकों के लिए, मैंने अपनी रिपोर्ट का एक पाठ संस्करण तैयार किया।

कोड पठनीयता के मुद्दों का अध्ययन करते हुए, मैं एक जिज्ञासु विषय पर StackOverflow में आया। इसने चर्चा की कि व्यापार-पठनीय कोड कितना महत्वपूर्ण है, और क्या यह प्रदर्शन और शुद्धता से अधिक महत्वपूर्ण है। परिणामस्वरूप, समुदाय के सदस्यों के अनुसार, सबसे महत्वपूर्ण मानदंड कोड की पठनीयता थी।

उस समय, मुझे कोड पठनीयता की समस्याओं में कोई दिलचस्पी नहीं थी - मैं अगला इंटरनेट बैंक विकसित कर रहा था। सीमांत HTML5, AngularJS, LESS का उपयोग किया। परियोजना को रूस के सबसे बड़े बैंकों में से एक के लिए विकसित किया गया था। मैंने Promsvyazbank से इस परियोजना पर स्विच किया, जहां मैंने एक बहुत ही समान इंटरनेट बैंक विकसित किया: ग्राहकों का एक ही खंड, उपयोगकर्ताओं की समान संख्या, लगभग समान प्रौद्योगिकी स्टैक (HTML5, AngularJS, SCSS)। लेकिन, परियोजनाओं की मजबूत समानता के बावजूद, मेरे लिए संक्रमण बहुत मुश्किल था। यह शैली के बारे में है। इन परियोजनाओं के लिए कोड हड़ताली डिजाइन और सामान्य पठनीयता में भिन्न था। अगर Promsvyazbank में डेवलपर्स ने दिशानिर्देशों का कड़ाई से पालन किया, तो नई परियोजना में कोई स्पष्ट शैली नियम नहीं थे।

यह तब था कि मैं यह समझने में सक्षम था (और यहां तक ​​कि गणना) कि एक बड़ी परियोजना सख्त शैली गाइड के लिए क्या लाभ लाती है। मेरी नई परियोजना की विकास लागतों का विश्लेषण करने के बाद, मैं उसी निष्कर्ष पर पहुंचा, जैसा कि स्टैकऑवरफ्लो पाठकों: पठनीयता सबसे महत्वपूर्ण मानदंड है।

अच्छी शैली के नियम

AngularJS और Angular 2+ के लिए, दृश्यपटल विकास की दुनिया में जाने-माने विशेषज्ञ John Papa ने स्टाइल गाइड बनाए, जो Angular अनुप्रयोगों को विकसित करते समय अच्छी शैली के नियमों का वर्णन करते हैं। प्रोमेस्वाज़बैंक में काम करते हुए, मैंने इन स्टाइल गाइड के बारे में सीखा। टीम ने स्पष्ट रूप से सभी परियोजनाओं पर उनका अनुसरण किया। लेकिन नए प्रोजेक्ट पर, कोड उन ठेकेदारों से आया, जिन्होंने प्रोग्रामिंग शैली के बारे में इतनी गंभीरता से नहीं सोचा था। अपनी नई टीम के साथ, मैं उन दैनिक कार्यों में आया, जिन्हें मैंने पहले हल किया था। हालांकि, इससे मुझे कोई फायदा नहीं हुआ, बल्कि केवल दर्द और पीड़ा ही मिली।

खोए हुए समय की एक कहानी या हमें इन सभी नियमों की आवश्यकता क्यों है

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

एक सरल से शुरू करते हैं

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

अब, स्टाइल गाइड से बूटस्ट्रैपिंग नियम (शैली 02-05) को देखें।

उस कोड को रखें जो एक अलग फ़ाइल में एप्लिकेशन को लॉन्च करने का काम करता है, और इस फ़ाइल में एप्लिकेशन लॉजिक को न रखें। तर्क को सेवाओं और घटकों में रखा जाना चाहिए।

लाख उदाहरण

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

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

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

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

• एक नियम - मैंने इस नियम का उल्लंघन करने के लिए खोए हुए समय का 25% लिखा;
• सिंगल रिस्पॉन्सिबिलिटी - इस सिद्धांत से विचलन ने 35% के समग्र नुकसान में योगदान दिया;
• लिफ्ट - दृष्टिकोणों के इस समूह का उल्लंघन, मुझे लगता है कि हम में से 40% लोग ऐसे थे जिन्होंने सबसे ज्यादा धीमा किया।

एक का नियम

हमारे ऑनलाइन बैंक ने कई भुगतानों का समर्थन किया, जिनमें से कुछ उनके मॉडल में एक दूसरे से पूरी तरह से अलग थे। फिर भी, प्रोग्रामरों ने एक "सार्वभौमिक" भुगतान फ़ॉर्म बनाने की कोशिश की जो सभी भुगतान विकल्पों के साथ काम कर सकता है।
फ़ॉर्म में ही, कई अलग-अलग ब्लॉक बनाए गए थे, जिन्हें कुछ शर्तों के तहत दिखाया गया था और कभी भी दूसरों के तहत नहीं दिखाया गया था। उसी समय, उन्हें सामान्य तर्क द्वारा सेवा दी गई, जिसने ViewModel'i को बहुत फुलाया।

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

अब देखते हैं कि नियम के नियम क्या कहते हैं।

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

एकल जिम्मेदारी

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

एकल जिम्मेदारी सिद्धांत (SRP) लागू करें।

LIFT

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

बुद्धिमान शैली गाइड भी इस समस्या को जानता है। इसे हल करने के लिए, एक LIFT नियम समूह बनाया गया है। LIFT का मतलब लोकेट, आइडेंटिफाई, फ्लैट और DRY होने की कोशिश करना है। LIFT के सिद्धांतों के अनुसार, परियोजना संरचना को इस तरह से व्यवस्थित करना आवश्यक है:

• यह स्पष्ट था कि नए घटकों को कहाँ रखा जाए और मौजूदा लोगों की तलाश कहाँ की जाए (पता लगाएँ);
• यह फ़ाइल के नाम से घटक का उद्देश्य स्पष्ट था (पहचानें);
• फ़ोल्डरों को नेविगेट करना आसान था, उनके लिए सबसे सपाट संरचना (फ्लैट) का उपयोग करें;
• अपने कोड को दोहराने की कोशिश न करें, लेकिन अन्य नियमों की कीमत पर नहीं (कोशिश करें DRY)।

LIFT दृष्टिकोण दो और नियमों द्वारा पूरक है।

कुल मिलाकर संरचनात्मक दिशानिर्देश प्रत्येक व्यक्तिगत घटक के लिए एक फ़ोल्डर बनाने और उसमें इस घटक से संबंधित सभी फ़ाइलों को समूह बनाने की पेशकश करते हैं। उदाहरण के लिए, यह तब अधिक सुविधाजनक होता है जब भुगतान-form.controller.js फ़ाइल नियंत्रक फ़ोल्डर में नहीं होती है, लेकिन भुगतान-फ़ॉर्म फ़ोल्डर में भुगतान-फ़ॉर्म। Html और भुगतान-फ़ॉर्म के साथ होती है।

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

परिणामस्वरूप, यदि कोड के लेखकों ने LIFT नियमों का पालन किया, तो परियोजना की संरचना कुछ इस तरह दिखाई देगी:



सहमत हूं, कोड को व्यवस्थित करने का यह विकल्प पाठक के लिए बहुत अधिक सुविधाजनक है। और वह हमारी पूरी टीम को बहुत समय बचाते थे।

अच्छे प्रोग्रामर बार में जाते हैं

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

यदि इस पाठ ने आपको कुछ के बारे में सोचा या किसी चीज़ को परिचित रूप से याद दिलाया, तो मुझे यह टिप्पणी पोस्ट में देखने में खुशी होगी।