मल्टी स्टोरी प्रोग्रामिंग की चुनौतियां

नमस्कार प्रिय हेब्रतचेटेली और प्रोग्रामर!

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

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

समय के साथ, कार्यक्रम फर्श से ऊँची इमारत की मंजिल की तरह बढ़ता गया, कभी-कभी प्रलय में बदल जाता है, जिसे घंटों तक भटकना पड़ता है, लेखक की पूरी योजना को स्मृति में नवीनीकृत करता है, या यहां एक और बैसाखी की तलाश करता है।

कार्यक्रम को अंतिम रूप देने पर काम धीरे-धीरे और अधिक कठिन और धूमिल हो गया। प्रत्येक नई गड़बड़ पिछले एक की तुलना में अधिक कपटी थी, और ऐसा हुआ कि कार्यक्रम के विकास के लक्ष्य को त्रुटियों से छुटकारा पाने के लक्ष्य से बदल दिया गया। नए कार्यों को लिखना मुश्किल है, यह जानना कि पुराने व्यवहार के साथ कुछ गलत है। ऐसे समय में, आपको एहसास होता है कि सॉफ्टवेयर विकास कितना कठिन है। शुरुआत में सभी पाप और मिसकल्चर, आर्किटेक्चर की खामियां और सम्मिलित बैसाखी मेरे लिए एक दुःस्वप्न के रूप में दोहराई गई। इस तथ्य के अलावा कि ये बेहद अप्रिय कार्यक्रम खामियां थीं, उन्होंने मुझे इस बुरे सपने से छुटकारा पाने की कोशिश करते हुए भी घंटों काम करने के लिए मजबूर किया। अंत में, एक विकल्प था: या तो एक बुरे सपने से उठना और फिर से कार्यक्रम शुरू करना, इस उम्मीद में कि दूसरे (तीसरे, चौथे) समय के लिए, मैं सभी नुकसानों को दूर कर सकता हूं, और इस बार मैं एक प्रतिस्पर्धात्मक वास्तुकला बनाऊंगा, अवधारणाओं के अनुसार सब कुछ विभाजित करूँगा, जटिलता और encapsulate करूँगा। मैं अलग-अलग स्थानों में दोहराव कोड निकालूंगा; या उस स्थिति में कार्यक्रम को संरक्षित करें जिसमें वह उस समय था, सभी सबसे अधिक दिखाई देने वाली त्रुटियों को समाप्त करें और बेहतर समय की प्रतीक्षा करें, इस कार्यक्रम के लिए नई प्रेरणा या नए विचार।

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

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

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

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

परंपरागत रूप से, कार्यक्रम में मामलों की स्थिति के तीन चरण हैं:

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

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

समाधान बेशक मूल है, लेकिन जाहिर है कि केवल एक ही नहीं है। आखिरकार, Microsoft, Apple, Oracle हैं जो विकास की इन कठिनाइयों को दूर कर सकते हैं। वे इसे कैसे करते हैं? ग्रीन ज़ोन के संरक्षण के तरीके क्या हैं?

मेरा सुझाव है कि आप अपना उत्तर टिप्पणियों में लिखें। मैं अपने विचार भी बताऊंगा।

आपकी टिप्पणी के लिए धन्यवाद।