जब कल किसी प्रोजेक्ट की जरूरत थी तो विरासत कोड के साथ टैक्सी कैसे चलाएं

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

हम परियोजना से निपटते हैं

यह सुनिश्चित करने के लिए कि विरासत के साथ कितना सटीक, विचारशील और श्रमसाध्य काम होना चाहिए, मैं कार्ड के एक घर के साथ एक सादृश्य दूंगा।


यह वह है जो विरासत कोड की तरह दिखता है। यदि हम इस इमारत से कम से कम एक कार्ड को हटाने या बदलने का निर्णय लेते हैं, तो हम पूरे घर को ज़मीन से ज़मीन पर गिराने का जोखिम उठाते हैं।

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

1. हमने एक "सरल" साइट बनाई है, और अब आप एक नया "बन" प्राप्त करना चाहते हैं, और हमें यह सब फिर से लिखना होगा, क्योंकि हमारे पास विरासत है ...
2. कोई नहीं जानता कि यह कैसे काम करता है ..
3. एक मॉड्यूल जोड़ने के लिए, आपको पूरी साइट की जांच करने की आवश्यकता है - केवल इस तरह से हम समझेंगे कि यह क्या और कहां से निकल सकता है ...
4. मैं किसी भी मामले में वहां नहीं जाऊंगा, वहां सब कुछ पहले से ही खराब है ...

लेकिन प्रोग्रामिंग में अनुभव से पता चलता है कि विरासत के बाद जीवन मौजूद है। प्रोग्रामिंग में कोई समस्या नहीं हैं। केवल ऐसे कार्य हैं जिन्हें संबोधित करने की आवश्यकता है। और एक एक्शन प्लान "विरासत कोड को पार करने के लिए" तैयार करने से पहले, आपको यह समझने की आवश्यकता है कि समग्र रूप से परियोजना पर कितनी बुरी चीजें हैं। अभ्यास के दौरान, उन्होंने परियोजना की समस्या के 6 चरणों की पहचान की:

1. कोई तकनीकी दस्तावेज नहीं। समस्याओं की सबसे कम सीमा, क्योंकि आप परीक्षण कर सकते हैं और प्रारंभिक अनुमान लगा सकते हैं कि यह कैसे काम करना चाहिए।
2. कोई व्यावसायिक प्रलेखन नहीं। यदि सभी दस्तावेज (तकनीकी और व्यावसायिक दोनों) गायब हैं, तो यह महसूस होता है कि "ऐसा लगता है कि हम इतिहास में फंस गए हैं" अनैच्छिक रूप से आता है। वास्तव में, यहां तक ​​कि एक व्यवसाय भी याद नहीं करता है कि यह कैसे काम करना चाहिए, जिसका अर्थ है कि टीम, कम से कम, अपेक्षित परिणाम के बारे में कोई समझ नहीं है।
3. ऐसा कोई नहीं है जिसने इसे डिजाइन किया हो। अगर, प्रलेखन की कमी के अलावा, कोई भी डेवलपर नहीं है जो समझा सकता है कि परियोजना को कैसे काम करना चाहिए, तो यह पहले से ही तली हुई है।
4. हमें नहीं पता कि उपयोगकर्ता को आखिरकार क्या मिलना चाहिए। यह एक बात है जब केवल बैकएंड के आसपास ही सवाल उठते हैं, लेकिन अगर हमें अभी भी पूरी तरह से पता नहीं है कि सामने वाले को क्या प्रदर्शित किया जाना चाहिए, तो यह पहले से ही राज्य के करीब है "रोगी के जीवित रहने की तुलना में मृत होने की अधिक संभावना है"।
5. प्रत्येक फ़ंक्शन का 200+ उपयोग और उन्हें गेटए कहा जाता है । पांचवें कठिनाई स्तर: जब आप विरासत में जाते हैं, तो आप फ़ंक्शन ए और 200 उपयोग देखते हैं, और कोई नहीं जानता कि यह क्यों है ...
6. ऐसे कोई प्रोग्रामर नहीं हैं, जो विकास करना चाहते हैं / कर सकते हैं। कोई टिप्पणी नहीं।

व्यवसाय को समझें

व्यापार पैसे गिनता है। व्यवसाय केवल पहले से ही काम करने के लिए अतिरिक्त वित्तीय संसाधनों को खर्च नहीं करना चाहता है। एक व्यवसाय कभी भी विचार नहीं खरीदेगा: "मैं इसे नए तरीके से करूंगा क्योंकि मुझे यह पसंद नहीं है।" इसलिए, हमेशा अधिक की पेशकश करें।

अक्सर, डेवलपर्स व्यापार को बेकार विचारों पर धकेल देते हैं। इस अवसर पर, एक अलग "गोल्डन कोट्स का फण्ड" है।

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

एक पुराने कोड के पुनर्जन्म के संबंध में व्यवसाय के साथ बातचीत करने के लिए, जिसे नए लाभदायक सुविधाओं की चटनी के तहत परोसा जाता है, यह नए व्यवसाय क्षितिज खोलने की स्थिति से आवश्यक है। हालाँकि, बातचीत से पहले, निम्नलिखित प्रश्नों का उत्तर दिया जाना चाहिए:

1. क्या व्यापार बढ़ने के लिए तैयार है? आपको समझने की आवश्यकता है: क्या व्यवसाय के पास वित्तीय मानक बढ़ाने के लिए अनुरोध है या बस अधिक सक्षम रूप से काम करने के लिए सेवा की आवश्यकता है।
2. प्रोटोटाइप चरण? अक्सर, एक व्यवसाय एक सरल प्रोटोटाइप का आदेश देता है, जिसके साथ वह उत्पाद की प्रासंगिकता के समय बाजार की "जांच" करना चाहता है। और केवल अगर वह पैसा बनाना शुरू करता है, तो व्यवसाय एक अधिक उन्नत और पूर्ण परियोजना में सुविधा विकसित करने के लिए तैयार है।
3. विकास पूरा हुआ और अब केवल समर्थन? कार्यों की पूरी श्रृंखला को समझना महत्वपूर्ण है।
4. क्या हमारी आँखों में पर्याप्त आग है और क्या यह बाहर नहीं जाएगी? परियोजना को प्रेरित करना चाहिए, न कि तोड़फोड़ करना। यह बहुत महत्वपूर्ण है कि आपकी टीम लिगेसी के पुनर्जन्म में संलग्न होना चाहती है, अन्यथा लोग धीरे-धीरे उनके लिए अधिक दिलचस्प परियोजनाओं में बिखर जाएंगे।
5. क्या कोई आर्किटेक्ट है? यह सबसे महत्वपूर्ण सवाल है - क्या आपके पास एक ऐसा व्यक्ति है जो सही वास्तुकला बना सकता है और पहले से ही अच्छा कोड लिखना शुरू कर सकता है। इसका कोई मतलब नहीं है कि अगर कोई वास्तुकार नहीं है, तो इसे शुरू करने का प्रयास करें। अन्यथा, एक हफ्ते में आप वह बन जाएंगे जिसने समस्या की विरासत बनाई थी।

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

पी - योजना

तकनीकी ऋण के साथ जल्दी और कुशलता से काम करने के लिए, आपको एक योजना की आवश्यकता है।

1. उन कार्यों की परिभाषा जिन पर हम परजीवीकरण करेंगे। परजीवी क्यों? यह अक्सर होता है: हमने एक विशेषता बेची, और इसके द्वारा हम आंशिक रूप से रिफैक्टिंग का मतलब है।

2. उच्च स्तरीय आवश्यकताओं की परिभाषा। सही दस्तावेज़ तैयार करने के लिए "उच्च मानक" के लिए एक स्पष्ट व्यावसायिक अनुरोध पंजीकृत करना आवश्यक है।

3. सिस्टम के मुख्य मॉड्यूल की परिभाषा, मॉड्यूल का थोपना। रिफैक्टिंग शुरू करने से पहले, आपको सिस्टम के मुख्य मॉड्यूल को समझने की आवश्यकता है: कहां, कैसे, क्या, और क्या बातचीत कर सकते हैं और कोड को अनुभागों में सीमांकित कर सकते हैं।

4. एकीकरण की परिभाषा। एक विशिष्ट मॉड्यूल बनाते समय, हमें पड़ोसी विरासत में इसे माउंट करने की क्षमता के बारे में पहले से सोचने की आवश्यकता है।

5. टीम की परिभाषा। रिफैक्टरिंग क्षेत्र में से एक योद्धा नहीं है। टीम एक सफल परिणाम का एक बहुत महत्वपूर्ण तत्व है। Fervor, टीम ड्राइव और प्रतिभागियों के बीच उत्कृष्ट बातचीत की प्रक्रिया होनी चाहिए।

6. हम कैसे परीक्षण करेंगे? यदि आप एक उच्च-गुणवत्ता वाली परियोजना लेने जा रहे हैं, तो आपको आगे और उत्पाद परीक्षण के विकल्पों पर विचार करने की आवश्यकता है।

उपरोक्त के साथ, यह निर्धारित करना भी महत्वपूर्ण है कि वांछित अंतिम परिणाम क्या होना चाहिए, एक स्केलिंग योजना तैयार करें और परियोजना की बाधाओं को पंजीकृत करें। उदाहरण के लिए, कोड स्केलिंग के मामले में, यह समझना महत्वपूर्ण है कि उच्च लोड स्थितियों के तहत समस्याएं कहां उत्पन्न हो सकती हैं (यह एक डेटाबेस, या भारी क्वेरी या ग्रिड या कुछ अन्य मध्यवर्ती लिंक हो सकता है जो "गिर सकता है")।

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

निंजा विरासत तकनीक

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

1. पहिया को सुदृढ़ न करें। मेरे लिए, यह कोड लिखने के लिए मुख्य जीवन हैक है। सब कुछ आप से पहले का आविष्कार किया गया है, विरासत कोड के साथ समस्याओं को हल करने के लिए तम्बुओं और अन्य प्रयोगों के साथ नृत्य का सहारा न लें।

2. कोड मानक है। एक मानक के बिना, प्रत्येक डेवलपर अपने तरीके से लिखेंगे। "लेखक की शैली" अराजकता और अधिक कोड कचरा बढ़ाने में योगदान करेगी।

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

4. स्टेटिक कोड एनालाइजर, PHP मेस डिटेक्टर आदि (एक हजार किताबों के बजाय) । इन और अन्य स्वचालित तकनीकों को प्रक्रिया की गति बढ़ाने की आवश्यकता होगी, विशेष रूप से समान समीक्षा कोड के साथ।

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

6. डेटाबेस आर्किटेक्चर, डेटा स्रोत। यह वह डेटाबेस है जिसे मैं किसी भी लिगेसी की पहली अड़चन मानता हूं। लेकिन हर कोई डिजाइन करता है जैसा वह चाहता है, और यहां तक ​​कि एसक्यूएल में भी, आप अनफोकस्ड खामियां पा सकते हैं। नए डेटाबेस के साथ काम करने के लिए यहां कुछ सुझाव दिए गए हैं:

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

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

8. डेकोरेटर, एडेप्टर, पिक्स ... नए कोड को पुरानी विरासत में एकीकृत करने के लिए ये पैटर्न मुख्य हैं।

9. योजना बी, या एकीकरण के लिए रोलबैक योजना। कई लोग इसके बारे में भूलने की गलती करते हैं। नई सामग्री डालते समय यह स्थिति में महत्वपूर्ण है "जब कुछ गलत होता है"। यही है, जैसे ही हम वास्तुकला का निर्माण शुरू करते हैं, पहले से ही इस स्तर पर हमें यह समझना चाहिए कि बग के मामले में हम इसे कैसे रोल करेंगे।

10. एक नए कोड के बिना (डॉक्स) परीक्षण एक सप्ताह में एक विरासत बन जाता है। कोई फर्क नहीं पड़ता कि आपका कोड कितना सुंदर होगा, एक सप्ताह में प्रलेखन के बिना यह "विरासत" स्थिति में होगा - इसकी समझ की अक्षमता के कारण।

11. परीक्षण। यदि यूनिट परीक्षण बहुत महंगे हैं, तो हम धूम्रपान, कार्यात्मक और एकीकरण परीक्षणों का उपयोग करते हैं। "नौकरी को सुंदर बनाने के लिए" सॉस के साथ व्यवसाय के लिए यूनिट परीक्षणों को बेचना कितना यथार्थवादी है? हमारी वास्तविकताओं में, यह एक पैटर्न की बजाय दुर्लभता है। यदि किसी कारण से यह "इकाइयों" के साथ काम नहीं करता है, तो हम धूम्रपान, कार्यात्मक या एकीकरण परीक्षणों की ओर रुख करते हैं, और यह भी नहीं भूलते हैं कि हम कार्य को, उदाहरण के लिए, मैन्युअल परीक्षक को सौंप सकते हैं।

एक उपसंहार के बजाय

इस कहानी में सबसे महत्वपूर्ण बात यह है कि काम करना और 6 समस्याग्रस्त चरणों की विरासत को पीछे न छोड़ना (सरल से अधिक जटिल क्रम में सूचीबद्ध):

• कोई तकनीकी दस्तावेज नहीं
• कोई व्यावसायिक प्रलेखन नहीं
• इसे विकसित करने वाला कोई नहीं है
• हमें नहीं पता कि उपयोगकर्ता को क्या प्राप्त करना चाहिए।
• प्रत्येक फ़ंक्शन का 200 + उपयोग और उन्हें गेटा कहा जाता है ()
• ऐसा कोई नहीं है जो इसे विकसित / पसंद कर सके।