गोवनोकॉड या सुपर पदानुक्रम? पहले बकवास, और फिर विकासवादी रिफैक्टिंग!

लेख का जवाब ।

यदि आप मशीनों या स्वचालित जीवन-समर्थन प्रणालियों आदि के लिए सॉफ़्टवेयर विकसित नहीं करते हैं, तो उचित उपयोग के साथ आपके लिए निम्नलिखित कार्य करता है।

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

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

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

कुछ विशिष्ट उदाहरण।

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

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

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

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

वास्तविक घटनाओं के साथ संयोग यादृच्छिक हैं, यदि वह ;-)

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

उनमें से अधिकांश रिफ्लेक्टर नहीं, जैसा कि होना चाहिए, न कि जब आवश्यक हो। Php में, एक उदाहरण एक प्रारंभिक मेगा-लिंक्ड ज़ेंड है, जब OOP OOP के लिए होता है, और सरल ऑपरेशन के लिए, 100,500 फ़ंक्शन कॉल प्लस अल्ट्रा-हाई कनेक्टिविटी। सिंफ़नी 2 के शिथिल युग्मित घटक खराब नहीं होते हैं, लेकिन कुछ प्रकार के अतिव्यापी भी होते हैं।

आज मैं अपने प्रोग्रामर्स को रिफ्लेक्टर के लिए समय देता हूं, जैसा कि मैं खुद एक अग्रणी प्रोग्रामर (अतीत में, एप्लिकेशन सॉफ्टवेयर, फिर वेब डेवलपमेंट) से प्रोजेक्ट मैनेजर के रूप में विकसित हुआ हूं।
क्योंकि मुझे तकनीकी ऋण के बारे में याद है और इसे कम करने की कोशिश करता हूं।

मैं वसंत के 17 उदाहरणों से एक गीत के शब्दों के साथ समाप्त होगा: "लेकिन सामान्य तौर पर, आपको बस पहले क्षण से आखिरी तक के कर्तव्य को याद रखना होगा।"

मैं आपको रिफ्लेक्टर और आवश्यक कौशल के लिए हर समय कामना करता हूं!