प्लास्टिसिन वास्तुकला

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

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

अधिकांश असफल परियोजनाओं में एक पैटर्न होता है। वे पूरी तरह से संरचना से रहित हैं। मैं ऐसे सिस्टम की वास्तुकला को "प्लास्टिसिन" कहता हूं।

थोडा अमूर्त

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

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

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

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

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

कई कारण

ऐसा क्यों हो रहा है? कई विकल्प हैं, लेकिन उनमें से तीन मेरे लिए सबसे महत्वपूर्ण हैं:

1. अपर्याप्त समय सीमा जिसके भीतर परियोजना को कार्यान्वित किया जा रहा है।

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

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

मैं अपनी खुद की कंपनी में ऐसी परियोजनाओं के लिए दृष्टिकोण को ध्यान में रखते हुए, परिणामों को पाठक पर छोड़ता हूं।

2. अस्थायी विनिर्देश

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

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

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

3. संयोग से शुरू की गई परियोजना

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

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

क्या करें?

नतीजतन, सवाल उठता है: "प्लास्टिसिन" कोड को कैसे रोका जाए। कई महत्वपूर्ण चीजें हैं जिन्हें नजरअंदाज नहीं किया जा सकता है:

परियोजना में सिस्टम आर्किटेक्चर के लिए स्पष्ट रूप से समर्पित डेवलपर होना चाहिए (इसके अलावा, न केवल परियोजना की शुरुआत में, बल्कि पूरे विकास में)।

नियमित कोड निरीक्षण की आवश्यकता होती है, जिसमें नेता की भागीदारी अत्यधिक वांछनीय होती है। तकनीकी विशेषज्ञ न होते हुए भी, उन्हें इस बात का अंदाजा होगा कि उनके वार्ड कितनी गलतियाँ करते हैं।

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

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