एक प्रोटोटाइप से एक कार्यक्रम कैसे विकसित करें

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


लेकिन क्या होगा अगर मैं कहता हूं कि सभी परियोजनाएं समान नहीं हैं, और उनमें से कुछ ऐसे नहीं हैं जो आप कर सकते हैं, लेकिन यहां तक ​​कि सावधानी से प्रोटोटाइप से बढ़ने की आवश्यकता है ? मैंने यूनाइट’12 सम्मेलन में इस बारे में बात की थी , और अब मैं आपको बताऊंगा।

प्रविष्टि

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

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

इसलिए किसी भी इसी तरह की पोस्ट करने के लिए टिप्पणियों में एक उग्र होलीवर की अभिव्यक्तियाँ। इसलिए, मैं पहले उन परियोजनाओं की बारीकियों के बारे में बात करता हूं जो मैं आमतौर पर करता हूं।

परियोजनाओं

मैं इंटरएक्टिव लैब के लिए काम करता हूं। मूल रूप से, हम ऑफ़लाइन इंटरेक्टिव इंस्टॉलेशन करते हैं, सॉफ्टवेयर का निर्माण जिसके लिए पारंपरिक सॉफ्टवेयर विकास से बहुत अलग है:

• कोई स्पष्ट टीके नहीं है ( यहां एक प्रदर्शनी है, इसे शांत करें! )।
• सभी परियोजनाएं छोटी हैं, लेकिन बहुत अलग हैं ( बहुत अलग हैं, "उस परियोजना में हमने mysql का उपयोग नहीं किया है, और इसमें हम mongodb का उपयोग करेंगे - आपको CODE लोड करना होगा!" ) !
• बहुत कम समय-सीमाएँ जिन्हें पुनर्निर्धारित नहीं किया जा सकता है ( "क्षमा करें, हमारे पास समय नहीं है, कृपया एटम एक्सपो को एक या दो महीने में स्थानांतरित करें" ),
• अक्सर प्रदर्शनी के दौरान केवल 1 दिन काम कर रहा होता है, और फिर उन्हें बाहर निकाल दिया जाता है ( अपडेट : लेकिन, एक ही समय में, कोड को सही करने के लिए यह स्पष्ट होना चाहिए कि अगर समय सीमा से कुछ घंटे पहले अचानक कुछ टूट जाए ),
• सॉफ्टवेयर और विशेष हार्डवेयर का संयोजन,
• हार्डवेयर पर पूर्ण नियंत्रण ( धीमा हो जाता है? ऑप्टिमाइज़ करें? आप क्यों हैं, आइए gtx 690 खरीदें )।

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

प्रक्रिया है

पुनरावृत्ति विकास का सिद्धांत बिल्कुल भी नया नहीं है, और सैकड़ों लेख इसके लिए समर्पित किए गए हैं, जिसमें हैबे भी शामिल है। यह कैसे है, एजाइल इंजीलवादियों का कहना है? हम, फिर, एक फेलिशिस्ट, देखते हैं कि हम एक पुनरावृत्ति के लिए क्या कर सकते हैं, कहते हैं, दो सप्ताह में। हम करते हैं। हम फिर से देखें ...

तो बंद करो! Fichelist? हमारे पास न तो टीके हैं और न ही इस बात का कोई स्पष्ट विचार है कि यह क्या होना चाहिए। दो सप्ताह में गर्भाधान? हमारे पास केवल 15 कार्य दिवस हैं, दो सप्ताह क्या हैं?

यह हम निम्नलिखित एल्गोरिथ्म में पहुंचे:

1. विचार मंथन करें।
2. एक या दो दिन में परीक्षण संपत्ति के साथ सबसे सरल और सबसे तेज़ प्रोटोटाइप।
3. लक्ष्य आयरन टेस्ट।
4. बिल्कुल बेकार है? गोटो १।
5. यह बुरा नहीं लगता है, लेकिन कुछ को बदलना / जोड़ना होगा।
6. एक दिन में प्रोटोटाइप अपडेट करें।
7. यदि अभी समय सीमा नहीं है - GOTO 3।
8. हम सो जाते हैं।

जैसा कि आप देख सकते हैं, अंतिम आवेदन में 1-2 दिनों के लिए पुनरावृत्तियों बढ़ता है। और यह बहुत अच्छा काम करता है।

एल्गोरिथ्म के माध्यम से जाने के बाद, चक्र का एक दो बार पालन करना और उससे बाहर निकलना, आप तुरंत इसके स्पष्ट लाभों की कल्पना कर सकते हैं:

• इस अवधारणा को प्रोटोटाइप से प्रतिक्रिया के साथ पुनरावृति से बनाया गया है। काम शुरू करने से पहले एक संपूर्ण TOR लिखने की आवश्यकता नहीं है, जो अभी भी मूल विचार की सफलता की गारंटी नहीं देता है।
• पहले दो दिनों में कितनी अच्छी अवधारणा देखी जा सकती है। समय सीमा से पहले के दिन को समझने से ज्यादा कष्टप्रद कुछ भी नहीं है कि पूरा विचार पूरी तरह से बेकार है।
• समय सीमा के करीब हमेशा एक तैयार अनुप्रयोग है। इसमें सभी विशेषताएं नहीं हैं, यह पर्याप्त सुंदर नहीं है, लेकिन इसे पहले से ही प्रदर्शनी में रखा जा सकता है। बस कुछ भी नहीं हो सकता है जो हमारे लिए तैयार है।
• सॉफ्टवेयर + हार्डवेयर के एक समूह की सभी बारीकियों को पहले पुनरावृत्तियों के चरण में तुरंत पता लगाया जा सकता है। अगर आपको लगता है कि 4098x2304 के कुल रिज़ॉल्यूशन वाले 9 स्क्रीन और 5 वीडियो कार्ड पर आपका आवेदन उसी तरह काम करेगा जैसे कि फुलएचडी मॉनिटर, तो आप बहुत गलत हैं।
• प्रोटोटाइप के साथ खेलने के बाद, अंतिम एप्लिकेशन में * अधिक सही कोड * के साथ सब कुछ फिर से लिखने की आवश्यकता नहीं है। प्रोटोटाइप ही आवेदन होगा।

प्रोटोटाइप

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



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

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

सामान्य तौर पर, लाइनों की संख्या n> N के साथ govnokod को लिखित कोड का अभिसरण विशेष रूप से व्यक्ति पर निर्भर करता है। यदि आपका प्रोग्रामर अपने भविष्य के बारे में चिंता किए बिना एक प्रोटोटाइप पेड़ पर टेंटकल को डराता है, तो आपको क्यों लगता है कि सब कुछ फिर से लिखने के बाद, वह समान रूप से एक समान परिणाम के लिए अंत में अभिसरण नहीं करेगा?



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

और आपकी दादी के रूप में, शहर के बाहर उसके छोटे बगीचे में, स्प्राउट्स के चारों ओर घास खींचती है, उन्हें काटती है, कुछ किस्मों को दूसरों पर ग्राफ्ट करती है - इसलिए आपको अपने प्रोटोटाइप की सावधानीपूर्वक निगरानी करनी चाहिए क्योंकि यह बढ़ता है। यह वही है जो एक अच्छे प्रोग्रामर को बुरे से अलग करता है। एक अच्छा प्रोग्रामर देखता है कि उसका कोड कहाँ बढ़ता है, अब क्या करने की आवश्यकता है ताकि बाद में आपको मृत शाखाओं को काटना न पड़े; समझता है कि एक पेड़ को आतंकित करने वाले बीटल से सावधानीपूर्वक कैसे छुटकारा पाएं; पता है कि कब बाड़ लगाना है ताकि यह सही दिशा में बढ़े।

KISS, सूखा, OOP, डिजाइन और अन्य चरम सीमाओं

अगर मैं प्रत्येक लेख है, जो को संदर्भित करता है के लिए 10 रूबल था KISS या सूखी , मैं एक बीएमडब्ल्यू 3 क्या अपने सपने है खरीदा होगा। इन buzzwords ने पहले से ही अपनी बेल्ट में एक भयानक OOP चिपका रखा है, जिस पर The Gang of Four बैठी है और इसे डिज़ाइन पैटर्न (उसी चित्र, निश्चित रूप से) से सजा रही है।

यह सब मायने रखता है कि क्या कोई व्यक्ति एक प्रोटोटाइप से एक स्वस्थ पेड़ विकसित कर सकता है।

विशेष रूप से, हमारी वास्तविकताओं में, सब कुछ, इसके अलावा, बहुत जल्दी करने की आवश्यकता है। एक या दो दिन, कोई और अधिक। यहाँ और निरंकुश व्याख्याओं KISS, सूखी, और मस्तिष्क OOP के सभी प्रकार लड़ने लगते हैं। जो, ईमानदारी से, हमेशा काम नहीं करता है।

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

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

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

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

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

तो क्या करें?

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

लेकिन, कुछ समय के लिए, मस्तिष्क टूट जाएगा और आपको अपने आप को एक शासक के साथ हरा देना होगा, ज़ाहिर है। ठीक है, हम अमूर्त रूप से सोचना बंद नहीं कर सकते हैं और सिर में सब कुछ उलझा हुआ है।

तो, क्या करने की जरूरत है ताकि प्रोटोटाइप पेड़ विल्ट न हो? कुछ सरल सिद्धांत प्रतीत होते हैं:

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

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

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

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

हाथ से लाइन !!! और फिर पैरों और पैरों के साथ! अब हम केवल वर्तमान समस्याओं का समाधान करते हैं। सबसे तेज़ तरीका। जैसा कि अभ्यास से पता चलता है, ऐसी व्यापक विशेषताओं में नाटकीय रूप से या पूरी तरह से गायब होने की संभावना है।

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

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

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

***

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

और मुझे उम्मीद है कि इस लेख से हर कोई अपने लिए कुछ उपयोगी ले जाएगा। और वह प्रोटोटाइप पेड़ विकसित हो जाएगा, और "प्रोटोटाइप" शब्द अपने नकारात्मक अर्थ खो देगा।

अपडेट

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