मेरी टीम को "आधुनिक" बनने की शुरुआत कहां से करनी चाहिए? [बन्द है]

Question

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

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

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

इन सभी तकनीकों में से, जिन्हें मैं आज के सॉफ्टवेयर विकास की दुनिया में "अपेक्षित" के रूप में देखता हूं, मैं उन्हें खुद और टीम दोनों पर हावी हुए बिना एक नए खिलाड़ी के रूप में एक टीम में कैसे एकीकृत करूं?

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

Comments

"आधुनिक"? स्ट्रिप कि "चुस्त" आपकी सूची से चर्चा करता है और मैं केवल 20 साल की उम्र के साथ चीजें देख सकता हूं।

— डॉक ब्राउन

शायद "आधुनिक" इस अर्थ में कि उनमें से व्यापक रूप से गोद लेना आधुनिक है, विचारों का जीन नहीं है, तब? मैं इस विषय का विशेषज्ञ नहीं हूं , यह सिर्फ मेरी धारणा है।

— वानाबेकोडर

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

— डॉक्टर ब्राउन

@DocBrown ने स्वीकार किया, आपने अपनी टिप्पणी करने से पहले मार्टी को इन सभी चीजों को बनाने के लिए समय पर वापस भेज दिया।

— अशक्त

मुझे इस बात की अधिक चिंता है कि उनका कॉलेज उन चीजों को सामने नहीं पढ़ा रहा है - मैं स्कूल से बाहर हो गया हूं 15+ साल और उन चीजों में से अधिकांश बहुत जल्दी कवर हो गए। (बूब्स के शब्द, निश्चित रूप से)।

— एलन गाउन

Answer 1

यह मुझे लगता है जैसे आप घोड़े से पहले गाड़ी डाल रहे हैं।

आपकी टीम किस प्रमुख समस्या का सामना कर रही है और कौन सी प्रौद्योगिकियां इसे ठीक करने में मदद करेंगी?

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

याद रखें कि आप जिस व्यवसाय के लिए काम करते हैं उसका उद्देश्य पैसा कमाना है, न कि कोड बनाना।

Comments

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

— Jaydee

इसे स्वीकार करना, लेकिन मैं इस पेशेवर के जोखिम को संबोधित करने के लिए एक अनुवर्ती की सराहना करूंगा (जैसे "मेरे फिर से शुरू में अधिक सामान होगा, लेकिन मेरी पुरानी नौकरी बहुत अच्छी तरह से परिवर्तन को गले नहीं लगाती थी")

— वानाबेकोडर

@WannabeCoder - कुशल होने से पहले आपको इसका उपयोग शुरू करना होगा। आप अभी भी उत्पादन में कोड डाल सकते हैं। कभी-कभी कोडिंग एक मेडिकल डॉक्टर होने की तरह है। हम सब अभी भी अभ्यास कर रहे हैं।

— जेफ

बहुत बढ़िया जवाब। आपको समस्याओं को हल करने के लिए केवल इन चीजों को लागू करना चाहिए, न कि समस्याओं का निर्माण करने के लिए।

— किक

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

— jpmc26

Answer 2

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

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

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

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

Comments

बहुत अच्छा जवाब (+1), विशेष रूप से अंतिम पैराग्राफ। एक बहुत ही आधुनिक पुस्तक (इस अर्थ में आधुनिक कि आज मुझे यह बहुत प्रासंगिक लगती है) मैं हाल ही में पढ़ रहा हूँ SICP है।

— जियोर्जियो

+1 यह उल्लेख करने के लिए कि ये buzzwords और लोकप्रिय भाषाएँ कितनी जल्दी बदलती हैं। एक अच्छा देव अच्छा कोड डालकर किसी भी कार्यप्रणाली को रौंद देता है। क्या काम करता है और अच्छी तरह से काम करता है!

— वीरेल

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

— jpmc26

कोई भी नहीं कहता है "समस्याओं का समाधान न करें", समस्या तब होती है जब समाधान को हल करने के लिए समस्याओं की तलाश शुरू की जाती है। वे उतने महत्वपूर्ण नहीं हैं, जितने कि मालवाहक किसान सोचते हैं कि उपकरण एक महत्वपूर्ण हिस्सा हैं, जहाँ वे वास्तव में सिर्फ उपकरण हैं। इसका अभ्यासी जो मायने रखता है, और जो भी उपकरण सही स्थानों पर काम करते हैं, वे ही चुनने वाले होते हैं। मेरी बात यह है कि टूलबॉक्स में कभी भी टूल का चयन न करें।

— gbjbaanb

एक उपकरण के साथ एक मूर्ख अभी भी एक मूर्ख है।

— पीट बेकर

Answer 3

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

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

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

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

Comments

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

— djeikyb

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

— ड्रूजॉर्डन

"कई कंपनियां इस तरह से फंस गई हैं; आपको यह जानकर भी आश्चर्य हो सकता है कि आपके कुछ 'डेवलपर' सहकर्मी स्वयं-सिखाया गए हैं और कोई भी औपचारिक पृष्ठभूमि वाले डेवलपर नहीं बने हैं।" ये अक्सर अपने डोमेन विशेषज्ञता के कारण सबसे मूल्यवान डेवलपर्स बन जाते हैं।

— pmf

ठीक है, मैं पूरी तरह से सहमत हूं। पहले पैराग्राफ को फिर से संगठित किया ताकि यह कम कृपालु लगे। मैं सिर्फ यह सुनिश्चित करना चाहता था कि ओपी को पता था कि वहां के कर्मचारियों का एक अच्छा हिस्सा वास्तव में एक औपचारिक पृष्ठभूमि नहीं है। मेरी ओर से शब्दों का गरीब विकल्प।

— DrewJordan

Answer 4

मुझे आशा है कि आपने अपने सहकर्मियों के समक्ष उन मुद्दों को प्रस्तुत नहीं किया होगा जैसा आपने अपनी पोस्ट में हमसे किया था। यह पेशेवर आत्महत्या होगी।

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

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

उपरोक्त सभी से, शिक्षक होने से बचें (जब तक कि यह एक क्षेत्र / तकनीक से संबंधित न हो जिसमें वास्तव में आपके पास पर्याप्त अनुभव हो)। एक अधिक तटस्थ प्रस्तुति, फायदे, कहने, स्वचालित परीक्षण, और प्रबंधन को चुनने का संकेत देती है, जो उन प्रथाओं के पेशेवरों और विपक्षों पर शोध करना चाहते हैं।

अब, उन "सर्वोत्तम प्रथाओं" को प्रस्तुत करने के लिए, आपकी टीम को उन्हें समझाने के दो तरीके हैं:

• क्योंकि मैं कहता हूं कि वे सबसे अच्छे अभ्यास हैं, और यह पर्याप्त है।
• क्योंकि वे उपयोगी हैं और समस्या को हल करने में मदद करते हैं।

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

काम करने के लिए दूसरे दृष्टिकोण के लिए, यह अहसास होना चाहिए कि एक समस्या मौजूद है । इसलिए:

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

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

उद्यम आईटी की दुनिया में आपका स्वागत है, लड़का! :-P

¹ : ठीक है, शायद मैं थोड़ा बहुत एक्साइट कर रहा हूं, लेकिन बहुत ज्यादा नहीं।

Comments

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

— winkbrace

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

— एसजुआन76

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

— एसजुआन76

यह कहना थोड़ा गड़बड़ है कि "सुनिश्चित करें कि आप वास्तव में काम कर रहे हैं"। निश्चित रूप से आपको काम करना चाहिए लेकिन आपको दीर्घकालिक सोचने की भी ज़रूरत है और हर दिन आपको सुधार करना चाहिए। हमारे प्रबंधक को इस तथ्य को खरीदने में मुझे 5 महीने लग गए कि यूनिट टेस्ट में मदद मिलती है तब भी जब हम "फास्ट" कोड करने की कोशिश कर रहे होते हैं। लेकिन ऐसा होने के लिए मुझे हर दिन और यहां 10min लेने की जरूरत थी।

— रुडोल्फ ओलाह

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

— एसजुआना76

Answer 5

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

यदि आप पेशेवर कारणों से एक नया ढांचा (या कुछ) सीखना चाहते हैं बजाय इसके कि आपके वर्तमान प्रोजेक्ट को वास्तव में इसकी आवश्यकता है, तो आपको इसका उपयोग किसी व्यक्तिगत परियोजना (अपने समय पर) में करना चाहिए।

Comments

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

— लुकास

Answer 6

स्रोत नियंत्रण।

आपने इसका उल्लेख नहीं किया, उम्मीद है क्योंकि यह पहले से ही है, लेकिन, अगर यह नहीं है, तो वहां से शुरू करें।

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

और आप अकेले शुरू कर सकते हैं अगर कोई शुरू में नहीं खरीदता है।

Comments

सबसे बड़ा बैंग-फॉर-बक सही स्थानों में कुछ ASSERTs की तरह है।

— पीटर मोर्टेंसन

@PeterMortensen सच है, लेकिन केवल अगर आप जानते हैं कि सही स्थान क्या हैं।

— एमिलियो एम बुमाचार

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

— डॉटान्चेन

Answer 7

एक सीधा जवाब

अन्य उत्तर बेहतर प्रथाओं को अपनाने के बारे में अच्छा 'मेटा-पॉइंट्स' बनाते हैं, लेकिन, बस आपको कुछ सीधे प्रासंगिक मार्गदर्शन देने के लिए , यहाँ सबसे अच्छी प्रथाओं का एक मोटा क्रम दिया गया है, जो मैं आपकी टीम (या किसी भी टीम) को अपनाने (पहले) का सुझाव दूंगा :

1. स्रोत नियंत्रण
2. अंक ट्रैकिंग (परियोजना और कार्य प्रबंधन)
3. स्वचालित निर्मित ¹
4. स्वचालित तैनाती

^{1 _{एक बहुत ही संबंधित अभ्यास स्वचालित या कम से कम दस्तावेज़ , प्रत्येक ऐप या सॉफ़्टवेयर प्रोजेक्ट के निर्माण और विकास के माहौल को स्थापित करने या विकसित करने या बनाए रखने के लिए है। यह बहुत कम उपयोगी थो है क्योंकि आप (उम्मीद) यह बार-बार या शायद ही कभी कर रहे हैं।}}

बाकि सब कुछ

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

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

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

चुस्त विकास स्पष्ट रूप से इस्तेमाल किसी भी अन्य कार्यप्रणाली से बेहतर नहीं है। और बहुत से लोगों को (अपने आप को) इसके साथ भयानक अनुभव हुए हैं। लेकिन बहुत सारे लोग वास्तव में इसे पसंद करते हैं (या इसे प्यार करते हैं) भी। कोशिश करो!

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

कोड समीक्षा बहुत उपयोगी हो सकती है - क्या आपने अपने सहकर्मियों से अपने कोड की समीक्षा करने के लिए कहा है? ध्यान रखें कि अच्छी प्रथाओं को अपनाने के लिए आपको एक औपचारिक प्रक्रिया की आवश्यकता नहीं है!

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

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

Comments

मैं वहाँ स्वचालित निर्माण और तैनाती के साथ स्वचालित प्रतिगमन परीक्षण डालूंगा। इसका यह भी फायदा है कि यह ऐसा कुछ है जिसे आप वेतन वृद्धि पर काम कर सकते हैं।

— सद्दाम

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

— रुडोल्फ ओलाह

Answer 8

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

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

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

Answer 9

एक दोष खोजें। एक दोष ठीक करें। ठीक करके दिखाओ।

आइए पहले सामान्यीकरण करें *। और वास्तव में, मैं आपको इसे पहले लेने का सुझाव दूंगा, क्योंकि सामान्यीकरण की कमी के कारण वास्तविक बुग्गी डेटा का परिणाम हो सकता है जो अन्यथा मौजूद नहीं हो सकता है, जबकि बाकी ऐसे मामले हैं जहां सबसे अच्छा अभ्यास संभव मदद कर सकता है लेकिन यह कहना मुश्किल है "बग A पॉलिसी X का पालन नहीं करने के कारण हुआ था ”। यदि आपके पास एक डेटाबेस है जो सामान्यीकृत नहीं है, तो आपके पास एक जगह है जहां डेटा असंगत हो सकता है।

यह एक अच्छी शर्त है कि आप असंगत डेटा के वास्तविक मामले को खोजने में सक्षम होंगे। अब आपको दो चीजें मिल गई हैं:

1. आपके डेटा में एक बग।

2. आपके डेटाबेस स्कीमाटा में बग।

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

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

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

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

* संयोग से, बहुत आधुनिक नहीं। कारण यह कहा जाता है सामान्य और नहीं सामान्य या कुछ और, उस समय यह एक सामयिक मजाक रहना था -ization रिचर्ड निक्सन के के नाम पर मजाक बनाने के लिए चीजों के अंत पर वियतनामीकरण नीति।

Answer 10

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

Comments

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

— पटकथा

आप अपने संगठन को बदलने या आपके संगठन को बदल सकते हैं

— रुडोल्फ Olah

Answer 11

प्रोग्रामिंग प्रतिमान में सुधार के लिए बहुत सारे प्रस्ताव आए हैं । अब के सबसे पुराने buzzwords फुर्तीले प्रोग्रामिंग और ऑब्जेक्ट-ओरिएंटेड लगते हैं। या क्या वे? दोनों पांच साल पहले की तुलना में काफी फीके हैं।

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

: वहाँ एक प्रतिमान है कि विवादास्पद रूप से 1960 के दशक में शुरू किया गया था प्रोग्रामिंग संरचित : केवल "उच्च स्तर" की तरह का निर्माण का उपयोग while, for, repeat, if/ then/ else, switch/ caseबड़ी मात्रा में प्रयोग करने के बजाय बयान gotoबयान जो डिफ़ॉल्ट रूप से स्वीकार कर लिया गया था। कर रहे हैं अभी भी बहस है कि क्या के बारे में gotoसब पर किसी भी वैध उपयोग है।

मैं स्वीकार करता हूं कि इसका उपयोग कम से कम करना gotoअच्छी बात है, लेकिन सभी अच्छी चीजों की तरह, बहुत दूर जाना संभव है।

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

एजाइल का सबसे मूल्यवान सबक, जो लंबे समय पहले जाना जाता था, यह है कि तैयार उत्पाद के लिए एक बेहतर रास्ता खोजने के लिए लचीलापन एक अच्छी बात है और उस पथ को खोजने की क्षमता किसी से भी आ सकती है - न कि केवल ऊपरी प्रबंधन।

---

विरोधी गोटो रिंग्डर एज्जर डिक्स्ट्रा द्वारा एक लेखन से:

प्रोग्रामिंग की कला जटिलता को व्यवस्थित करने की जटिलता और यथासंभव कमीने अराजकता से बचने की कला है।

—दिक्स्ट्रा, इन: दहल, दिज्क्स्त्र और होरे १ ९ ra२, पृष्ठ। 6. (पेज 6 यहां देखें ।)