तो क्या सॉफ्टवेयर विकास धीमा हो रहा है?
इस सवाल पर एक पल के लिए सोचें। यह कैसे होता है कि अब आप कुछ विकसित करते हैं, और अधिक कठिन और अप्रिय यह आपके आवेदन में नई सुविधाओं को जोड़ना है, वास्तुकला के माध्यम से देखा जा सकता है?
और कार्यों को पहले क्यों हल करना इतना आसान था, लेकिन अब वे भ्रामक और लागू करने में मुश्किल दिखते हैं?
ऐसा लगता है कि स्थिति में सुधार होना चाहिए, क्योंकि आप लंबे समय से परियोजना में हैं, क्या आपने नहीं? सब कुछ दूसरे तरीके से क्यों हो रहा है?
उत्तर खोज रहे हैं
ठीक है, आपको इस तथ्य के लिए खुद को दोष नहीं देना चाहिए कि उत्तर अपने दम पर आपके सिर में पॉप नहीं करते हैं, अधिकांश डेवलपर्स समान हैं। हां, और प्रश्न, आप देख रहे हैं, आसान नहीं है।
यदि हम सभी प्रश्नों के उत्तर जानते, तो कोई समस्या नहीं होती।
फिर भी, आप प्रबंधकों, ग्राहकों और यहां तक कि अन्य डेवलपर्स के साथ एक से अधिक बार आएंगे जो असफल रूप से इन्हीं सवालों के जवाब तलाशते रहेंगे।
और सबसे पहले, हर कोई प्रक्रिया को दोष देना शुरू कर देता है। आखिरकार, यह स्पष्ट है कि प्रक्रिया के साथ समस्याएं विकास की गति पर प्रतिकूल प्रभाव डालती हैं।
यह समझ में आता है। फिर भी, मैंने पाया कि अक्सर यह आपकी समस्याओं की जड़ नहीं है।
यदि टीम निष्क्रिय नहीं है, और महत्वपूर्ण कार्यों को सही ढंग से प्राथमिकता दी जाती है, तो सबसे अधिक संभावना है कि प्रक्रिया दोषी नहीं है।मैं चाहता हूं कि आप मुझे यहीं समझें। यही है, मैंने जिन दो चीजों का उल्लेख किया है वे केवल वही नहीं हैं जो आपको उत्तेजित करना चाहिए, मैं सिर्फ यह कहने की कोशिश कर रहा हूं कि चूंकि टीम वास्तव में उन चीजों पर काम करती है जो परियोजना के लिए वास्तव में महत्वपूर्ण हैं, आप प्रक्रियाओं को जादुई रूप से स्थापित करने में सक्षम नहीं हैं, कम से कम किसी तरह। तब टीम के विकास की उत्पादकता में उल्लेखनीय वृद्धि हुई (ज्यादातर मामलों में)।
निम्नलिखित विकल्पों पर भी विचार किया जाता है:
- जोड़ी प्रोग्रामिंग
- स्कैन को कन्नन में बदलें?
- क्या हमें बैकलॉग को अलग तरह से परिभाषित नहीं करना चाहिए?
- हो सकता है कि हमें कार्यों का मूल्यांकन करने के लिए तोते का उपयोग करना चाहिए? मंजिला बिंदु? या यहां तक कि सभी बैकलॉग समान आकार के होते हैं?
- क्या हमें और अधिक डेवलपर्स की आवश्यकता है? या व्यापार विश्लेषकों?
- क्या मुझे टीमों का पुनर्गठन करना चाहिए?
बेशक, ये सभी अद्भुत सवाल हैं जो आपको समय-समय पर खुद से पूछना चाहिए, लेकिन मैं लगातार यह सुनिश्चित करता हूं कि एक और बड़ी समस्या है ...
आपका कोड!
थोड़ा प्रयोग करते हैं।
सभी प्रक्रियाओं के बारे में भूल जाओ, घोटाले और बैकलॉग और कहानी के बिंदु और बाकी सब के बारे में भूल जाओ।
आप एक डेवलपर हैं। आपको अपना कार्य करने की आवश्यकता है, कोड में कुछ बदलें। आप अकेले बैठे हैं, कोई प्रक्रिया नहीं है, विश्लेषक हैं। केवल आप और आपका काम।
आप उस चीज के बारे में सोच सकते हैं जो आपने हाल ही में किया था या अभी विकसित कर रहा हूं, मैं सिर्फ यह चाहता हूं कि आप हर उस चीज से अमूर्त हो जाएं जो इस सुविधा के डिजाइन या कोडिंग से सीधे संबंधित नहीं है।
निश्चित रूप से आपके पास निम्नलिखित विचार होंगे:
1. यह सुविधा जल्दी और आसानी से लागू की जाएगी, मुझे पता है कि इसे कैसे और कहां जोड़ना है, सब कुछ टिप-टॉप होगा!तो, महान! यह पता चला है कि वास्तव में आपको कोई समस्या नहीं है।
2. कुछ मुझे समझ नहीं आ रहा है कि क्या किया जाना चाहिए। सिस्टम में इसका उपयोग कैसे और कहाँ किया जाएगा?हम्म, इस मामले में, आपको सबसे अधिक संभावना है कि प्रक्रिया के साथ कुछ समस्याएं हैं। हो सकता है कि आपको अधिक स्पष्ट रूप से समस्या के बयान की आवश्यकता हो या आपको अधिक प्रश्न पूछना चाहिए। वास्तव में ऐसा होता है। अर्ध-तैयार विचार प्रक्रिया में आते हैं और किसी को निश्चित रूप से चारों ओर भागना होगा और डेवलपर्स को
वास्तव में उनसे निपटने से पहले अपने दिमाग को स्थानांतरित करना होगा।
3. मुझे कुछ बदलने से डर लगता है, यह लगभग असंभव है। शुरू करने से पहले, आपको आवेदन के अन्य भागों में खुदाई करने और समझने की आवश्यकता होगी: क्या, कैसे और क्यों यह काम करता है (और यह कैसे काम करना चाहिए)।यह दुखद नहीं है, लेकिन यह सबसे अधिक संभावित परिणाम है। दूसरे और तीसरे पैराग्राफ के बीच कुछ, क्योंकि उनके पास एक और एक ही कारण है - समाप्त कोड और या तो मृतक, या "वह-नहीं" वास्तुकला।
और मैं इस तथ्य का सामना करना जारी रखता हूं कि अधिकांश अनुप्रयोगों का विकास स्वयं के कोड या मूल डिजाइन के नुकसान के कारण धीमा हो जाता है।
लेकिन आपको ऐसी समस्याएं केवल सफल कंपनियों में ही दिखाई देंगी, क्योंकि ...
कभी-कभी आपको ढीले जूते के साथ चलने की आवश्यकता होती है
एक समय था, मैंने एक जोड़े को असफल स्टार्टअप की सलाह दी। और मुझे कहना होगा, उनके पास एक चीज आम थी (जैसा कि अधिकांश अन्य स्टार्टअप में): कोड के साथ शून्य समस्याएं। हाँ, उत्कृष्ट कोड आधार, कंघी, अच्छी तरह से तैयार, यह अच्छी खुशबू आ रही है।
मैंने मृत स्टार्टअप में सर्वश्रेष्ठ वास्तुकला और सही कोड देखा है।शायद ऐसा लग रहा है कि मैं खुद का विरोध कर रहा हूं। मैं अब समझाता हूँ।
समस्या यह है कि स्पार्कलिंग कोड वाले स्टार्टअप बाजार के साथ तालमेल नहीं रख रहे हैं। वे शुरुआत में खड़े होते हैं और अपने फावड़े पर सुंदर धनुष बांधते हैं, चारों ओर देखते हैं और प्रत्येक स्थान की सावधानीपूर्वक जांच करते हैं जहां वे अपना पैर रखने जा रहे हैं।
क्या चल रहा है? वे सुंदर कोड, शांत वास्तुकला बनाते हैं। लेकिन बहुत देर हो गई। प्रतियोगी
आगे बढ़ रहे हैं और
दो कैफीनयुक्त नहीं-काफी-प्रोग्रामर-लेकिन-आई-बिट-कोडेड आपको उनके वीबी 6 आवेदन के साथ बाईपास करते हैं, जो उनके घुटनों पर कल रात लिखा गया था । हां, यह बिल्कुल नहीं हो सकता है कि ग्राहक क्या चाहता था, लेकिन कितनी जल्दी!
लेकिन क्या, मैं वास्तव में अब कहता हूं कि आपको एक नैपकिन govnokod लिखने और जल्दी से इसे पारित करने की आवश्यकता है, अन्यथा विफलता?
या मैं यह कह रहा हूं कि आप अच्छी प्रथाओं और गुणवत्ता कोड पर एक सफल कार्यालय नहीं बढ़ा सकते हैं?
नहीं। लेकिन मैं यह कहना चाह रहा हूं कि सबसे सफल कंपनियों ने सबसे पहले अपने प्रयासों को ग्राहक पर केंद्रित किया और उसके बाद ही सॉफ्टवेयर पर।
दूसरे शब्दों में, यदि आप पिछले पांच वर्षों में एक दर्जन सफल कंपनियों के कोड को देखते हैं, तो उनमें से 9 में आपको चमकदार वास्तुकला और मूल डिजाइन और अच्छे शिष्टाचार से बहुत दूर एक प्रणाली मिलेगी।
तो पैंट के बारे में क्या?
ठीक है, मैं यह सब किस लिए कर रहा हूं?
जीतने वाली कंपनियाँ दौड़ती हैं और बच जाती हैं! हालांकि, 5 वर्षों के बाद, वे अभी भी उतनी ही मुश्किल से भागते हैं जितना वे कर सकते हैं और उनके बदसूरत जूते अनछुए होने लगते हैं।
वे यह भी ध्यान नहीं दे सकते हैं कि उनके फावड़े तब तक अछूते नहीं हैं, जब तक कि वे एक-दो बार उनके ऊपर न फंसे। बकवास, वे अभी भी चल रहे हैं। एक तरफ, यह अच्छा है, क्योंकि यह वही है जो उन्हें समृद्ध बनाता है, और अन्य जो रुकने का फैसला करते हैं और पीछे छोड़ दिया जाता है, अपने फावड़े बाँधते हैं, शर्मनाक हारे हुए हैं।
यह समस्या आमतौर पर पांच साल के लगातार चलने के बाद महसूस होती है, जब कंपनियां तय करती हैं कि यह एक नए स्तर पर जाने का समय है। अब तक, यह उनके लिए अच्छा रहा है, वे एक तरफ से दूसरी तरफ जा रहे हैं और अपने पैरों को अलग रखने की कोशिश कर रहे हैं ताकि वास्तव में लेस पर न जा सकें।
यह बस थोड़ा सा है जो उन्हें धीमा कर देता है और इसलिए वे लगातार चलते रहते हैं, हिंसक रूप से सुविधाओं को लहराते हैं और लार के साथ छिड़काव करते हैं।
और अब झटके से पैंट उनके ऊपर से गिरने लगी! लेकिन गंभीर कंपनियों के पास बिना किसी कारण के धीमा होने का समय नहीं है और वे अपनी फिसलने वाली पैंट को खींचना शुरू कर देते हैं!
बाहर से, यह सब बहुत सकारात्मक दिखता है। वे शरमाते हैं, अपनी पूरी कोशिश करते हैं कि वे उसी गति से दौड़ते रहें, लेकिन उनकी पैंट और ढीले ढाले रन को अजीबोगरीब तेज चलने में बदलने के लिए पर्याप्त हैं।
उसकी टखनों पर भार के साथ एक बूढ़ी औरत उन्हें एक सिर शुरू कर देती है , लेकिन वे अभी भी एक ब्रेक लेने और अपनी पैंट खींचने में बहुत व्यस्त हैं! और पिछली बार से हमने अभी तक नहीं बनाया है!
और फिर वे सोचने लगते हैं। क्या करें? अपनी पैंट को फिर से धीमा या खींचे बिना समस्या को कैसे हल करें? सुधार शुरू होता है। वे कूदने की कोशिश कर रहे हैं। किसी को यह भी विचार है कि आपको अधिक पैरों की आवश्यकता है ... =)
मुझे लगता है कि आपको विचार मिला। वास्तव में, आप बस की जरूरत है ...
बंद करो, लेस बांधो और अंत में अपनी पैंट खींचो!
मुझे आशा है कि सादृश्य स्पष्ट है और अब आप समझते हैं कि ossified वास्तुकला और बासी प्रणाली कोड के साथ क्या हो रहा है।
जब आप सभी मूर्खता के साथ दौड़ रहे होते हैं, तो आपके जूते-चप्पल बेकार हो जाते हैं, और आपकी पैंट लगातार गिरने लगती है, यह सब आपको वास्तव में धीमा कर देता है।
और यह तब तक और खराब होगा जब तक आप अंततः यह नहीं पाएंगे कि आप वास्तव में पिछड़े हुए हैं।
दुर्भाग्य से, मेरे पास कोई जादू का जवाब नहीं है। यदि आप सिस्टम के आर्किटेक्चर और डिजाइन पर समग्र रूप से स्कोर करके तेजी ला सकते हैं, तो जल्द या बाद में आपको सामान्य रूप से सब कुछ भुगतान करना होगा और रिफ्लेक्टर करना होगा।
शायद आप खरोंच से शुरू करेंगे। सब कुछ डालने के लिए आपको अपनी सभी सेनाओं को मिलाना पड़ सकता है। किसी भी मामले में, आपको रोकना होगा। हालांकि हो सकता है कि किसी ने दौड़ने के दौरान फावड़े बांधने की कोशिश की हो? =)
दुखी मत हो, तुमने कुछ गलत नहीं किया है। इसके अलावा, आप बच गए जब अन्य बहुत सावधान और असफल रहे। बस अपनी पैंट को अनदेखा न करें, जिसमें आप हर कदम पर भ्रमित हो जाते हैं, कुछ डरावना करें!
लगभग। perev।: मैं अनुवादक नहीं हूं, मैं सभी के समान हूं, इसलिए अधिक या कम मुक्त अनुवाद निकला। मैंने लेख की विडंबना को बताने की कोशिश की। कृपया पीएम में टाइपो और चूक के बारे में लिखें। आपका ध्यान के लिए धन्यवाद और आपका दिन शुभ हो!