जटिल प्रणालियों के विकास के लिए नियम। एक परियोजना का इतिहास

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

इस लेख में कोड और योजनाएं नहीं होंगी, इसमें केवल "और से" परियोजना बनाने का इतिहास होगा। मुझे लगता है कि कई लोग इस लेख में रुचि लेंगे। तो चलिए!

शुरुआत

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

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

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

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

मैंने कोड का विश्लेषण करना शुरू कर दिया। पहली छाप सिर्फ घृणित थी। मैं सदमे में था। मैं इस बात की सूची दूंगा कि इस परियोजना में मुझे किस बात का गुस्सा था।

1. अवयव और नियंत्रण।

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

2. कार्यक्रम के स्रोत कोड वास्तुकला का तर्क।

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

3. चर, तरीके और टिप्पणियां।

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

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

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

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

मैं यह भी नोट करना चाहता हूं कि कोड के कई टुकड़े थे जो कोडप्रोजेक्ट से जानबूझकर चुराए गए थे।

4. डेटाबेस

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

5. क्लाइंट सर्वर

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

वास्तव में, सब कुछ अलग दिख रहा था। क्लाइंट पर प्रोजेक्ट बनने के बाद, इसे सर्वर पर कतार में भेज दिया गया था। कतार में जाने के बाद, क्लाइंट तब तक ब्लॉक रहा जब तक सर्वर पर विश्लेषण नहीं हो जाता। कल्पना कीजिए कि 5 ग्राहक मशीनों के साथ एक संगठन है। प्रत्येक मशीन पर एक परियोजना बनाई जाएगी (औसत परियोजना 10 पृष्ठ और 10 वांछित चित्र हैं)। इस तरह की एक औसत परियोजना लगभग 1 घंटे में मिस करती है। यानी अगर 5 प्रोजेक्ट बनते हैं, तो आखिरी प्रोजेक्ट 4 घंटे बाद ही शुरू हो जाएगा। और ये सभी 4 घंटे क्लाइंट के लिए जमे हुए होंगे। हिंदुओं, मेरी राय में, यह नहीं जानते कि बहुविवाह क्या है।

समस्या हल करना

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

नई परियोजना

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

1. स्केलेबिलिटी और लचीलापन

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

2. प्रौद्योगिकी

किसी भी डिजाइनर का एक महत्वपूर्ण बिंदु, चूंकि विकास की सफलता और गुणवत्ता अक्सर उपयोग की जाने वाली तकनीकों पर निर्भर करती है। एक प्रोग्रामिंग भाषा के रूप में, मैंने C # और .NET 4.0 फ्रेमवर्क को चुना। यह मूल रूप से परियोजना में ही रखा गया था, इसलिए मैंने कुछ भी बदलना शुरू नहीं किया।

मैंने MSSQL 2008 r2 को चुना, मुझे MS के साथ काम करने की अधिक आदत है, इसलिए मुझे उन पर भरोसा है।

ग्राफिक्स के लिए, मैंने XNA 4.0 को चुना। एक अच्छी शक्तिशाली चीज, हालांकि इसकी कमियां हैं, लेकिन वे फायदे से अधिक महत्वहीन हैं।

3. डेटाबेस वास्तुकला और कक्षाएं

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

4. चर, तरीके और टिप्पणियां

जब विधियों और चर का नामकरण किया जाता है, तो मैंने उन्हें नाम देने की कोशिश की ताकि भविष्य में किसी विधि या चर के मूल्य को समझने में कोई भ्रम या समय बर्बाद न हो। मेरे पास कोड में "a", "b", "c" जैसे चर नहीं हैं, क्योंकि इस तरह के पदनाम का अर्थ नहीं होता है। इसका अपवाद i, j वैरिएबल है - मैं उनका उपयोग लूप में करने के लिए करता हूं। और चर x, y, z भी निर्देशांक हैं।

मैं इस पद्धति को समझने के लिए प्रत्येक विधि के सामने टिप्पणियाँ छोड़ता हूं। स्वयं विधियों में, मैं और अधिक टिप्पणियाँ छोड़ने का प्रयास करता हूँ। चूंकि यह भविष्य में कोड की समझ को बहुत सरल करता है।

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

5. स्मृति

भारी भरी हुई प्रणालियों में, उत्पाद के सामान्य संचालन के लिए मेमोरी की सफाई एक आवश्यक शर्त है। इसलिए, स्मृति को साफ करना आवश्यक है।

6. कॉपी-पेस्ट

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

7. बड़े से छोटे तक

शुरू में, कुछ बुनियादी चीजों को लिखने की कोशिश करें, और उसके बाद ही चिप्स को स्क्रू करें। यदि आप एक ही बार में लिखना शुरू करते हैं, तो आपको एक "स्प्रे" मिलेगा। यही है, आप अपना ध्यान और समय स्प्रे करते हैं। और अक्सर यह पता चलता है कि समस्या के मुख्य बिंदुओं में और अतिरिक्त समस्याओं में भी। यह "न तो खुद के लिए और न ही लोगों के लिए।"

परिणाम

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