सच कहूँ तो, आप चरवाहे कोडिंग पसंद करते हैं? [बन्द है]


66

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

मुझे पता है कि यह निर्भर करता है। कृपया, स्पष्ट करें कि आप एक या दूसरे का उपयोग कब करेंगे। कृपया, बताएं कि काउबॉय कोडिंग के क्या फायदे हैं।

विकिपीडिया पर चरवाहे कोडिंग के बारे में देखें


13
उन लोगों के दो समूहों के साथ एक बार एक प्रयोग किया गया था जिन्हें एक निश्चित समय सीमा में मिट्टी के बर्तन बनाने के लिए कहा गया था। समूह 1 को बताया गया कि वे उच्चतम गुणवत्ता वाले बर्तन बना सकते हैं, समूह 2 को बताया गया कि वे उत्पादित सभी बर्तनों के वजन पर मापा जाएगा। अंतिम समूह 2 बर्तन की गुणवत्ता समूह 1 बर्तन की तुलना में अधिक थी। काश, मैं इस प्रयोग के मूल स्रोत को खोजने में सक्षम नहीं था, लेकिन ओवरराइडिंग बिंदु "पुनरावृत्तियों की संख्या जितनी अधिक होगी, गुणवत्ता उतनी ही बेहतर होगी"। समूह 2 काउबॉय थे? शायद।
एडोल्फ लहसुन

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

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

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

क्या यह व्यक्ति किसी प्रकार के स्रोत नियंत्रण प्रणाली का उपयोग नहीं करता है, या कंपनी के उपयोग से इंकार करता है?
थॉमस

जवाबों:


201

मुझे लगता है कि लगभग हर अनुभवी प्रोग्रामर तीन चरणों से गुजरा है और कुछ चार से गुजरे हैं:

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

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

  3. क्वासी-इंजीनियर अक्सर वास्तविक , प्रशिक्षित इंजीनियरों के लिए खुद को गलती करते हैं क्योंकि वे वास्तव में सक्षम हैं और कुछ इंजीनियरिंग सिद्धांतों को समझते हैं। वे अंतर्निहित इंजीनियरिंग और व्यावसायिक अवधारणाओं से अवगत हैं: जोखिम, आरओआई, यूएक्स, प्रदर्शन, रखरखाव, और इसी तरह। ये लोग डिजाइन और प्रलेखन को एक निरंतरता के रूप में देखते हैं और आमतौर पर परियोजना की आवश्यकताओं के लिए वास्तुकला / डिजाइन के स्तर को अनुकूलित करने में सक्षम होते हैं।

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

  4. डक्ट टेप प्रोग्रामर AKA गुरु या उच्च-भुगतान सलाहकारों को पता है कि परियोजना की आवश्यकताओं को सुनने के बाद पांच मिनट के भीतर वे किस वास्तुकला और डिजाइन का उपयोग करने जा रहे हैं। सभी वास्तुकला और डिजाइन का काम अभी भी हो रहा है, लेकिन यह एक सहज स्तर पर है और इतनी तेजी से हो रहा है कि एक अप्रशिक्षित पर्यवेक्षक इसे काउबॉय कोडिंग के लिए गलती करेगा - और कई करते हैं

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

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

यदि आप एक चरवाहा कोडर हैं, तो आप कोई अन्य तरीका नहीं जानते हैं।

यदि आप एक आर्किटेक्चर अंतरिक्ष यात्री बन गए हैं, तो आप बिना किसी डिज़ाइन के सॉफ्टवेयर का निर्माण करने में शारीरिक और मनोवैज्ञानिक रूप से अक्षम हैं

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

और यदि आप एक डक्ट-टेप प्रोग्रामर हैं, तो "काउबॉय कोड" का कोई कारण नहीं है क्योंकि आप एक गुणवत्ता वाले उत्पाद का निर्माण कर सकते हैं ।

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


27
सुंदर ढंग से व्यक्त किया गया।
ब्रैंडन

4
विरोधाभास के बावजूद अच्छे योगदान के लिए +1। आपने कहा कि एक क्वैसी-इंजीनियर जरूरत पड़ने पर सचेत चुनाव करते हैं। कई बार ज्ञान के साथ अनुभवी प्रोग्रामर को उन नियमों को तोड़ने की जरूरत होती है जिन्हें वह जानते हैं और कुछ बाधाओं के कारण मानते हैं। बेशक अगर एक प्रोग्रामर अपने काम पर एक अच्छा और त्वरित है, तो उसे चुनने की आवश्यकता नहीं है, लेकिन कुछ पेशेवरों में यह गुण है। वैसे भी, सवाल उत्तेजक है।
मनिएरो सेप

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

19
मुझे यह भी पता नहीं है कि मैं इस सूची में कहां हूं: एस कभी-कभी मैं एक परियोजना के बारे में सुन सकता हूं और तुरंत जान सकता हूं कि मैं इसे कैसे बनाने जा रहा हूं, जैसे 4, और फिर मुझे गंभीर विश्लेषण पक्षाघात होगा और वास्तुकला पर विचार करना होगा, जैसे 2, तब मैं YAGNI पर विचार करता हूं और व्यावसायिक मूल्य के बारे में सोचता हूं और व्यावहारिक होने की कोशिश करता हूं, और महसूस करता 3हूं, और फिर मैं एक गड़बड़ बना देता हूं 1
कार्सन मायर्स

14
मुझे आपको यह देने के लिए -1 देना चाहिए कि एक अत्यधिक भुगतान किया गया सलाहकार डक्ट टेप प्रोग्रामर स्किल लेवल पर है (संकेत: उनमें से ज्यादातर नहीं हैं, करीब भी नहीं)। लेकिन मैंने आपको वैसे भी +1 दिया।
फाल्कन

47

हाँ।

मैं अपने मोजे फर्श पर छोड़ना पसंद करता हूं, जहां मैंने उन्हें उतार दिया, मेरा डेस्क प्रिंटआउट और पुराने स्नैक रैपर, गंदे व्यंजनों से भरा मेरा सिंक, और मेरा बिस्तर अनमना हो गया।

मैं पहले से ही एक उचित छुट्टी होने के लिए नियोजित छुट्टी पर विचार नहीं करता, पोषण युक्त भोजन की ओर एक मन के साथ खाया जाने वाला भोजन, या ज्ञात ट्रेल्स पर उचित लंबी पैदल यात्रा पर रहना।

मुझे मज़े करना पसंद है, आश्चर्यचकित होना, नई चीजें सीखना, गलतियाँ करना और अगर मैं इसे वापस करने जा रहा हूं तो कभी भी निश्चित नहीं होना चाहिए। और कभी-कभी, यह रवैया वही है जो जमीन से एक परियोजना प्राप्त करने के लिए आवश्यक है ...

... लेकिन ज्यादातर समय, यह सिर्फ गैर जिम्मेदाराना है। जब नृत्य समाप्त होता है, तो पिपेर का भुगतान किया जाएगा ... इसे अपने जोखिम पर भूल जाओ।


मुझे "पुराने स्नैक रैपर, गंदे व्यंजनों से भरा मेरा सिंक, और [सबसे महत्वपूर्ण] मेरा बेड अनमेड।" क्या बिल्ली, +1 क्योंकि चरवाहा कोडिंग का रोमांच और न जाने से असुविधा अगर आप इसे वापस कर सकते हैं तो मूर्ख यूएमएल, डिजाइन और विनिर्देशों के साथ समय बर्बाद करने के लिए भी सशक्त है। वे मेरे कार्यान्वयन से अपने विनिर्देशों को लिखते हैं, कभी दूसरे तरीके से नहीं। :: व्यंग्य
क्रिस

31

आप बिल्कुल सही हैं। इस "काउबॉय प्रोग्रामिंग" दृष्टिकोण को तेजी से कोड का पहला संशोधन मिल सकता है, लेकिन उस समय की बचत खो जाने से अधिक होगी:

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

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

अपने सहकर्मियों का विश्लेषण करने और यह विचार करने के लिए कि क्या उनकी आदतें फायदेमंद हैं या नेत्रहीन रूप से करने के बजाय हानिकारक हैं।


6
हमेशा अपवाद होते हैं। कुछ कोडर जीनियस हो सकते हैं, फोटोग्राफिक मेमोरी हो सकती है लेकिन थोड़ा धैर्य। दूसरे वे तेज नहीं हैं, लेकिन लगातार हैं; वे एक समय में एक-एक बाइट को तब तक पीसते हैं जब तक कि यह उनकी कुतिया न बन जाए। एक अच्छा प्रोग्रामर बनने के कई तरीके हैं। शायद चरवाहे प्रोग्रामिंग उसके लिए काम करता है। यह पूछने वाले या कई अन्य लोगों के लिए काम नहीं कर सकता है। हालांकि, किसी को कैसे काम करना चाहिए, जब महत्वपूर्ण बात दर और परिणामों की गुणवत्ता है। 12-सिलेंडर इंजन को प्रतिबंधित करने वाले कानून को क्यों पारित करें, जब आप कर के माध्यम से उच्च mpg को पुरस्कृत कर सकते हैं?
जॉब

@ जोब: मैं सहमत हूँ। हर किसी की एक अलग प्रक्रिया होती है; यह प्रक्रिया आमतौर पर सफल नहीं होती है लेकिन हो सकती है। मैं फेनमैन एल्गोरिथ्म का एक कुख्यात उपयोगकर्ता हूं, और मैं इस क्षेत्र में रहते हुए भी चरण 3 जितनी तेजी से संभव हूं।
जॉन पूर्डी

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

2
@ जोब: हां मैं सहमत हूं, एक बिंदु तक। लेकिन किसी और चीज पर विचार करने से इनकार करना (जो = सीखने से इनकार करना), और स्रोत नियंत्रण का उपयोग करने से इनकार करना दो बड़े लाल झंडे हैं जो मुझे कहते हैं: तेजी से हो सकता है, लेकिन एक वास्तविक खतरनाक बोफहेड।
जल्दी_जुन

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

29

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

मैं इस पर यहाँ कुछ फेंकने जा रहा हूँ जो वास्तव में अलोकप्रिय हो सकता है: ग्राहक आमतौर पर एक चरवाहे फैशन में संभाले हुए सामान चाहते हैं

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

टीम के तरीके और संरचना एक परियोजना के खेल क्षेत्र को समतल करने और एक ही पृष्ठ पर डेवलपर्स के अलग-अलग स्तर प्राप्त करने के लिए डिज़ाइन किए गए हैं, समान लक्ष्यों के लिए, एक ही तरीके से काम कर रहे हैं।

सफल "काउबॉय" जिसके साथ मैंने काम किया है:

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

इस तरह के लोग बहुत कम प्रबंधन और संरचना ओवरहेड के साथ वास्तव में शानदार परिणाम देते हैं, लेकिन वे दुर्लभ हैं।


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

3
ग्राहक जरूरी नहीं कि यह चरवाहा-शैली चाहते हैं, वे इसे सस्ते और तेज चाहते हैं। यह तो हम तक पहुंचाने के लिए है।

@ user1249: यह मुझे परियोजना प्रबंधन त्रिकोण की याद दिलाता है: सस्ता, तेज, अच्छा - दो उठाओ।
डैनमैन

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

13

EDIT: भविष्य के संदर्भ के लिए, मेरा उत्तर एक और प्रश्न के लिए है, जिसे इस में मिला दिया गया है। यहाँ काफी जगह है, लेकिन वह मेरी कॉल नहीं थी।


वह सिर्फ आलसी, घमंडी, अज्ञानी और बेहद स्वार्थी है। यह व्यवहार लापरवाह है।

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

लेकिन, मुख्य बिंदु यह है: संस्करण नियंत्रण में कितना समय लगता है?
अगर उसे हर बार 5 सेकंड का निवेश करने के लिए आश्वस्त नहीं किया जा सकता है, तो आपको इसे अपने बॉस तक ले जाना चाहिए। संस्करण नियंत्रण वैकल्पिक नहीं है। पूर्ण विराम।

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


2
कभी-कभी सच्चाई बहुत सरल और सरल होती है ...
ChaosPandion

+1 यह कहने के लिए कि ऐसे स्वार्थी लोगों के साथ टीमवर्क असंभव है। अगर वे जिन्न हैं, तो भी काउबॉय टीम के खिलाड़ी नहीं हैं; वे मुख्य शो हैं और हम समर्थन समूह हैं
Mawg

11

यह पूरी तरह से इस बात पर निर्भर करता है कि मैं एकल काम कर रहा हूं, या एक टीम में।

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

लेकिन अगर मैं अकेले काम करता हूं, तो बेशक मैं एक चरवाहा बनना चाहता हूं। दुनिया में सभी महान कृतियों का आविष्कार एक ही दिमाग, या अधिकांश दो, काम कर रहे चरवाहे-शैली द्वारा किया गया है। कुछ लोगों का नाम बताने के लिए:

  • शास्त्रीय यांत्रिकी? काउबॉय आइजैक न्यूटन, बाद में लाइबनिज, लाग्रेंज, हैमिल्टन के अतिरिक्त।
  • विमान? काउबॉय राइट।
  • सापेक्षता का सिद्धांत? काउबॉय अल्बर्ट आइंस्टीन।
  • कंप्यूटर का मौलिक विज्ञान? चरवाहा एलन ट्यूरिंग।
  • ट्रांजिस्टर? काउबॉय वाल्टर ब्रेटन और जॉन बार्डीन।

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


मुझे लगता है कि आप कुछ प्रसिद्ध चरवाहे सफलताओं का उल्लेख ऊपर से गुज़र रहा है, जबकि नोटिस अब तक अधिक संख्या में चरवाहे विफलताओं।
मग

7

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

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

इसके अलावा, मुझे लगता है कि डिजाइन का बड़ा हिस्सा पहले से ही वरिष्ठ डेवलपर्स हेड के अंदर एक पृष्ठभूमि थ्रेड में संसाधित किया गया था।

जब वरिष्ठ डेवलपर किसी जटिल प्रणाली की कक्षाएं, या स्क्रैच से नए एप्लिकेशन, और योजना चरण के बिना मंथन करना शुरू करता है, तो आपको चिंता शुरू करनी होगी।


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

1
@ जारोड: या नहीं। अधूरा / शिथिल कोड करने का कोई मतलब नहीं है।
डेनिस डे बर्नार्डी

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

@ चेस्ट: यह मान लिया जाएगा कि आप कोड की एक पंक्ति को संपादित करने से पहले लॉग में देख रहे हैं। बहुत स्पष्ट रूप से, मैं बहुत कम कोडर्स जानता हूं जो वास्तव में करते हैं ... और फिर भी (जैसा कि मैं करता हूं ...), वे बहुत कम रुचि रखते हैं कि यह क्यों / इसके बजाय प्रतिबद्ध था, क्योंकि यह क्यों बदल गया था मूल कोड से।
डेनिस डे बर्नार्डी

@steve: सरल कार्यों के लिए टिप्पणी के साथ एकल प्रतिबद्ध का उपयोग करना आसान है "जोड़ा गया कार्य जो त्वरण मापदंडों की गणना करता है", सह-लेखन की तुलना में: "PaternX कंकाल", "कोड की पहली पंक्ति", "फिक्स्ड ए बग", "एक और फिक्स्ड" बग "। यदि कम "शोर" होता है, तो परियोजना के वैश्विक परिवर्तनों को ट्रैक करना आसान है। और ऐसे अलमारियां हैं जिनका उपयोग अपूर्ण कोड के लिए डटालॉस से बचने के लिए किया जा सकता है।
कोडर

6

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


कोई आपके SWINE का उपयोग कैसे करता है? संवादों का वर्णन करने के लिए भाषा क्या है?
जॉब

@ जॉब यह अभी तक तैयार नहीं है।
नील बटरवर्थ

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

@ जारोड संस्करण नियंत्रण। खैर, हम rcs था। रिहाई प्रबंधन? यह एक निवेश बैंक था! आप जितना जोर से लिखते हैं, दरवाजे को उतनी ही तेजी से बाहर धकेलते हैं।
नील बटरवर्थ

वापसी पर स्वागत है।
पी शेव

5

मेरे अनुभव से, बड़े नियंत्रण प्रणालियों को विकसित करने के लिए स्रोत नियंत्रण के साथ गाय बॉय कोडिंग सबसे अच्छा और सबसे बग मुक्त तरीका है।


2
मिट्टी की एक बड़ी गेंद बनाने की कीमत पर (मेरा खुद का जवाब ;-))
डेनिस डी बर्नार्डि

4

मुझे लगता है कि टिप्पणीकारों में से एक के पास यह सही था - इसके परिणामों के बारे में।

यदि व्यक्ति एक अच्छा उत्पाद तैयार कर सकता है - कुछ ऐसा जो उसके काम को करने वाला हो, और बनाए रखने योग्य और विश्वसनीय हो - तो औपचारिक कार्यप्रणाली या प्रक्रियाओं का पालन करने से क्या फर्क पड़ता है? गुणवत्ता में एक मंजिल सुनिश्चित करने के लिए प्रक्रियाएं बहुत अच्छी हैं, लेकिन यदि कोई व्यक्ति उस मंजिल से ऊपर काम कर रहा है, तो प्रक्रियाएं समीकरण में कुछ भी नहीं जोड़ती हैं। इन दिनों बहुत सारे डेवलपर्स, imo, लगता है कि प्रोग्रामिंग का बिंदु प्रक्रियाओं का पालन करना है, एक अच्छा उत्पाद बनाने के विपरीत ।


4

इस तरह के व्यक्ति को हैकर कहा जाता है, और यह आमतौर पर हमारे बीच अधिक पेशेवर से एक मानार्थ शब्द नहीं है।

जैसा कि आपने देखा है, डिज़ाइन, संगठन और नियंत्रण में सहेजा गया समय डीबगिंग में खो जाता है। और अक्सर यह पता लगाने में कि कौन सा कोड वास्तव में भेज दिया गया था। यदि आप इसे बिल्कुल पा सकते हैं!

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

तो, यह कहीं और एक सामान्य दृष्टिकोण हो सकता है, लेकिन मेरी जगह पर (और मैं एक वरिष्ठ कोडर हूं, जो इस दृष्टिकोण की प्रवृत्ति है, अहम) हम इसे पीड़ित नहीं करते हैं। ऐसा नहीं है कि हम प्रक्रियाओं और प्रक्रियाओं के एक टन की मांग करते हैं, लेकिन हम संगठन की एक न्यूनतम राशि पर जोर देते हैं, स्रोत कोड नियंत्रण (जो ईमानदारी से खूनी है पूर्व और उपयोगी उपयोगी है!)

केंट बेक एट अल, वे सभी पेशेवर हैं जिन्होंने पुराने प्रक्रिया-आधारित तरीकों को अपने आप में खराब देखा था, इसलिए उन्होंने कोडिंग को व्यवस्थित करने के लिए नई पद्धति बनाई, जबकि इसे और अधिक शिल्प-उन्मुख रखते हुए, और फिर इसके बारे में बाकी सभी को बताया - किताबें प्रकाशित करके ( आपने इसे इंटरनेट से पहले वापस कैसे किया? '

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

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


+1 यह दुर्भाग्यपूर्ण है कि 'हैकर' इसका अर्थ बदल गया है। हैकरडोम का एक संक्षिप्त इतिहास
ज्ञान उर्फ ​​गैरी ब्यून

4
मैं "हैकर" के बजाय "हैक" कहूंगा।
माइक शेरिल 'कैट रिकॉल'

2
वे एक चरवाहे हैं, जैसा कि ओपी ने कहा है कि एक हैकर क्या नहीं है। उस मीडिया को छोड़ दें।
ओसोडो

यह "रॉकस्टार" प्रोग्रामर हो सकता है ... 'छोटी-छोटी बातों' के बारे में चिंता करने के लिए अहंकार और प्रतिभा से भरा हुआ। अब मेरा बाथटब ब्लू एम एंड एमएस से भरा कहाँ है ?! मुझे वह चाहिए, अभी!
gbjbaanb

3

एकमात्र महत्वपूर्ण तथ्य टीम के दीर्घकालिक उत्पाद परिणाम हैं।

एक दावा है कि एक महान प्रोग्रामर (या अधिक) सहित एक टीम एक औसत दर पर कोडिंग औसत प्रोग्रामर की एक बड़ी संख्या के साथ एक टीम की तुलना में बेहतर परिणाम उत्पन्न करेगी।

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

यदि काउबॉय के साथ टीम कई आदमी महीनों / वर्ष के बाद भी गंदगी (दस्तावेज़, डिबग, एकीकृत, बनाए रखने) को साफ नहीं कर सकती है, तो जो भी अग्रिम चरवाहे ने बनाया, उसने टीम को लंबे समय तक लाभ नहीं दिया।

जो तय करें, और टीम के रोस्टर का अनुकूलन करें।

प्रत्येक प्रोग्रामर काम नहीं करता है (या काम करना चाहिए) उसी तरह, जब तक कि अंतिम परिणाम अच्छा हो।


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

धारणा जरूरी नहीं कि सही हो। एक सम्मेलन की एक समय सीमा या अपने उत्पाद के किसी अन्य शो को पूरा करना बेहद महत्वपूर्ण भी हो सकता है।

1
@ थोमस: जोखिम कारक दोनों तरह से कटते हैं। सभी पेचेक का वित्तपोषण करने वाला व्यक्ति अगले वित्त वर्ष के दौर से बाहर निकल सकता है जब एक हैक-एक साथ प्रूफ-ऑफ-कॉन्सेप्ट जल्द ही पर्याप्त नहीं होता है। आपके धीमे घोड़े अब कितने अच्छे लगते हैं? सभी इंजीनियरिंग विकल्प जुआ हैं। अपने चिप्स रखें।
हॉटपावर 2

@ hotpaw2 - जुआ यह है कि क्या (संभावित टर्मिनल) काउबॉय कोडिंग से लागत आएगी इससे पहले कि आप अपनी निधि प्राप्त करने में सक्षम हों। सामान्य तौर पर, मेरी शर्त चरवाहे की कोडिंग के खिलाफ है (और इसमें अधिक समय लगेगा)। ओह, आप मुझे १/१० बार या १/५ भी हरा सकते हैं। लेकिन कुल मिलाकर, साल-दर-साल के रूप में संभावनाएं ढेर हो जाती हैं, चरवाहे कोडर आपको लाभ से अधिक खर्च करेंगे।
थॉमस

1
@ Thorbjørn Ravn Andersen, @ hotpaw2 - यहाँ खेलने के लिए एक और गतिशील है। एक कोडर जो उपयोग करने के लिए तैयार है, अगर सक्रिय रूप से पीछा नहीं करना है, तो जोखिम भरी तकनीकें, यहां तक ​​कि उन जोखिमों के अनावश्यक होने पर, सामान्य रूप से जोखिम वाले विकल्प को कहीं और बनाने के लिए जा रहा है। यानी, स्रोत नियंत्रण के खिलाफ उनकी पसंद व्यवहार के एक जोखिम भरे पैटर्न का संकेत है जो अंततः उन्हें और उनकी कंपनी को काट देगा। एक जुआ में, कभी-कभी आप घर को हरा सकते हैं, लेकिन अंततः प्रतिशत आपको हरा देते हैं।
थॉमस

3

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

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

या, यह एक रैंक शौकिया का संकेत हो सकता है।

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

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

बस कोई बहाना नहीं है - एक रिपॉजिटरी सेट करने के लिए 10 मिनट लगते हैं और एक कमिट करने के लिए 10 सेकंड। यह आपके कुल विकास समय का शायद 1% है। टेस्ट, अगर आप जल्दी में हैं, तो आसानी से एक दिन में 20-30 मिनट तक नीचे गिराया जा सकता है और फिर भी यथोचित उपयोगी हो सकता है।

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


2

हां, लेकिन आपको यह पहचानना होगा कि ऐसा कब नहीं करना है।

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

मुझे भी लगता है कि आपको हारून के जवाब के माध्यम से निश्चित रूप से सोचना चाहिए। काउबॉय का मतलब अलग-अलग लोगों के लिए अलग-अलग चीजें हैं।


2

जब मुझे लगता है कि "पारंपरिक" तरीके हैं, तो मुझे लगता है कि "प्रबंधन डेवलपर्स को समझने का तरीका नहीं जानता है, इसलिए डेवलपर्स दुनिया में आने के बजाय और यह समझने के लिए पर्याप्त है कि क्या चल रहा है, वे डेवलपर्स को उनकी दुनिया में आते हैं"।

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

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

उदाहरण के लिए, मेरे पास अपने आप पर काम कर रहे प्रोजेक्ट के लिए सबसे सरल बैकलॉग नहीं होगा ... यह सिर्फ एक टू-डू सूची होगी। अगर हम में से दो हैं, तो मेरे पास शायद वह सूची साझा होगी, लेकिन एक बहुत ही सरल प्रारूप में (शायद हमारे कोड भंडार में संग्रहीत एक नोट)। एक बार जब मेरे पास 3 या 4 होते हैं, तो मैं किसी प्रकार की कार्य वस्तु प्रणाली की तलाश करता हूं।


1

केवल जब बहुत सरल सुविधाओं का प्रोटोटाइप।

फिर एक बार और सही तरीके से विचार करने पर, मैंने कोड को खोद लिया और गंभीर हो गया।


1

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

हालांकि, मैं दिल से "साफ-सुथरा" हूं और विकास के शूट-से-हिप शैली को नापसंद करता हूं।

दूसरी ओर, भारी प्रक्रिया-युक्त मॉडस ऑपरेंडी मेरे स्वाद के लिए भी नहीं है। मैं सिर्फ अभिनय करने से पहले योजना बनाना पसंद करता हूं।

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


2
अक्सर आपको समस्या को हल करने की आवश्यकता है ताकि यह पता लगाया जा सके कि इसे कैसे हल किया जाए ...

1

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

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

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


1

वहाँ दो शिविर दिखाई देते हैं - वे जो परिणामों का पक्ष लेते हैं, और वे जो सिद्धांतों का पक्ष लेते हैं। मैं बाद में आता हूं।

मैं एक औसत दर्जे का लेकिन यकीनन कर्तव्यनिष्ठ प्रोग्रामर हूं - कोडिंग करते समय मेरी मुख्य चिंता यह है कि काम पूरा करने से परे , यह है कि मैं मदद कर रहा हूं जो कोई भी अपने कोड का उपयोग अपने काम को करने के लिए करता है। मैं यह नहीं कह सकता कि मैंने हमेशा यही हासिल किया है - लेकिन यही मेरा उद्देश्य है।

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


हाँ, और यह संभव है (संभावना?) कुछ चरवाहा कोडर्स के लिए नहीं-महान कोड देने के लिए।
बर्नार्ड डाय

1

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

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

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

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


0

नहीं कभी नहीं।

मैं हमेशा आवश्यकताओं का विश्लेषण करता हूं, वास्तुकला के बारे में सोचता हूं, विवरण डिजाइन करता हूं, और फिर कोड। भले ही मैं एक व्यक्तिगत परियोजना के लिए घर पर एकल काम करता हूं।

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


-1: आपको यह भी ध्यान रखना चाहिए कि जो भी आपकी तनख्वाह लिख रहा है, वह किसके हित में है।
जिम जी।

@ जय: मैं तनख्वाह लिख रहा हूँ। इसलिए मुझे टीम के सदस्यों को फायर करने का पूर्वाभास है। शायद आपका पतन थोड़ा जल्दबाजी था। :-)
सिजेरॉन

हम इंजीनियर हैं और ग्राहक और उपयोगकर्ताओं के साथ एक जिम्मेदारी है। - कभी-कभी ग्राहक एक त्वरित जहाज की तारीख की मांग करता है। जोर: कभी-कभी त्वरित जहाज की तारीख गैर-परक्राम्य होती है।
जिम जी।

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

0

मुझे नहीं लगता कि काउबॉय कोडिंग एक वरिष्ठ दृष्टिकोण है।

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

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



0

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

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


0

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

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

व्यक्तिगत रूप से, मैं टीम में किसी को पसंद करने का मन नहीं बनाऊंगा, क्योंकि एक क्रंच में वे ऐसा कुछ कर सकते हैं जिसके बारे में कोई और नहीं सोचता।

दूसरी ओर, अपने स्वयं के व्यक्ति बनें और अपने लिए तय करें कि आपके प्रश्न का उत्तर क्या है, क्योंकि केवल एक चीज यह सुनिश्चित करने के लिए है कि सॉफ्टवेयर बनाने के बाद किसी को भी इसका पता नहीं चले। यह उन चीजों में से एक है जो इसे एक दिलचस्प क्षेत्र बनाती है ...


मैं सहमत हूं, जब तक कि इसके तदर्थ समाधान को फिर से छूने की आवश्यकता नहीं है, तब तक किसी प्रकार का पैटर्न होना महत्वपूर्ण है, क्योंकि इसका न केवल "इसे काम करने" के बारे में, किसी को अंततः "हुड के नीचे" देखने और समझ में आने की आवश्यकता होगी यह
programmx10
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.