विकास के साथ समानांतर में रिफ्लेक्टर: हमारा अनुभव और दो चेकलिस्ट

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

अगर हम 3-5 लोगों के लिए एक भौतिक बिंदु में संपीड़ित मिनी-टीमों के बजाय परिपक्व टीमों के बारे में बात कर रहे हैं, तो "विकास" में कोड लिखने के अलावा टीम की विभिन्न गतिविधियों की एक पूरी मेजबानी शामिल है। "विकास" में, आप कई लोगों द्वारा अप्रकाशित बैठकों को लिख सकते हैं, प्रलेखन के साथ काम कर सकते हैं, कार्य प्रबंधकों में रिपोर्ट को बनाए रख सकते हैं, और इसी तरह। यह सब विकास के लिए आवंटित हमारी घड़ियों के लगभग 30% को खा जाता है। और किसी तरह, किसी का ध्यान नहीं है, यह पता चलता है कि "80 घंटे का कोड, 20 घंटे का रिफैक्टिंग" चित्र के बजाय, हम सीधे, रिफैक्टिंग के लिए ~ 13 घंटे का भद्दा आंकड़ा प्राप्त करते हैं, क्योंकि बाकी सब कुछ अन्य गतिविधियों में अवशोषित हो गया था।

नीचे हम आपको बताएंगे कि रिफैक्टरिंग के साथ विकास को कैसे संयोजित किया जाए ताकि परियोजना का तकनीकी ऋण स्नोबॉल की तरह न बढ़े, लेकिन समय और प्राथमिकता के सही वितरण के बारे में भी बात करें।

क्यों refactoring कई समस्याओं का कारण बनता है? सबसे पहले, इस तथ्य के कारण कि टीमें अपने स्वयं के संसाधनों का पर्याप्त मूल्यांकन नहीं कर सकती हैं और इस प्रक्रिया को विकास के साथ जोड़ सकती हैं। लोगों को यह लगता है कि यदि उनका कार्य दिवस प्रति दिन 8 घंटे (प्रति सप्ताह 40) है, तो सभी 40 घंटे वे कथित रूप से विकास में लगे हुए हैं। ऐसा नहीं है।
संपूर्ण विकास प्रक्रिया को दो भागों में विभाजित किया जा सकता है: ये साइड एक्टिविटीज और सब कुछ है जो सीधे कोड से संबंधित है।


यहां हमारी विकास टीमों में से एक का वितरण समय कैसा दिखता है।

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

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

निम्नलिखित स्लाइड कुछ उत्तर देती है:


समय लॉग रखें, यह बेतहाशा उपयोगी है

बैठकें और समीक्षाएं अछूती रहती हैं, क्योंकि हमारा मानना ​​है कि इन गतिविधियों को जितना संभव हो अनुकूलित किया जाता है और पर्याप्त न्यूनतम रखा जाता है (जो टीमों में काम करते हैं जहां बैठकों और कोड समीक्षाओं में 70% समय लगता है, हमारे शब्दों की पुष्टि करेगा)। इसलिए, हम समय को कोड को रिफलेक्टर करते हैं और विकास से बग को ठीक करते हैं। और यहाँ हम फिर से "एक और दो तिहाई" दृष्टिकोण लागू करते हैं और हमारे द्वारा प्राप्त मानव-घंटे को "रिफैक्टिंग" और "बग" में विभाजित करते हैं, इन अवधारणाओं को स्पष्ट रूप से अलग करते हैं। ऐसा मॉडल व्यवहार्य है और आपको परियोजना पर आदेश को बहाल करने का समय खोजने की अनुमति देता है, कम से कम तकनीकी ऋण में वृद्धि के बिना। यदि हम कई "विकास" घंटे काटते हैं, तो परियोजना ठप हो जाएगी।

हम रिफैक्टरिंग प्रक्रिया को सही तरीके से अपनाते हैं

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

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

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

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


वही कार्ड

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

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

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

प्राथमिकता

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

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

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

यह दृष्टिकोण ऊर्ध्वाधर प्रबंधन मॉडल में बहुत खराब रूप से फिट बैठता है और कभी-कभी आप परिस्थितियों का सामना करेंगे जब आपको ग्राहक के सामने अपने फैसले का बचाव करना होगा। लेकिन अन्यथा कुछ भी नहीं।

परिणामस्वरूप हमें क्या मिलता है

वर्णित दृष्टिकोण के साथ, हम तकनीकी विकास में रिफैक्टिंग प्रक्रियाओं को व्यवस्थित रूप से एकीकृत करते हैं, तकनीकी ऋण के आकार (या वृद्धि को रोकते हैं) और बिना किसी बड़ी दुर्घटना के यह सब करते हैं।

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

उपयोगी सामग्री:

1. एलेक्सी कटावे की रिफ़ैक्टरिंग पर रिपोर्ट: अधिक व्यावहारिक उदाहरण, साथ ही मैनेजर ग्लीब की एक अद्भुत कहानी, जो रिफ्लेक्टर नहीं करना चाहते थे, फिर भी ...



2. कार्यों की चर्चा के लिए हमारे नियम

3. हमारी चेकलिस्ट कोड की समीक्षा