आप अपने दैनिक कार्यों में "इसे सही कैसे करें" और "इसे एएसएपी" के बीच संतुलित करते हैं? [बन्द है]


180

मैं खुद को समय-समय पर इस सवाल पर विचार कर रहा हूं, बार-बार। मैं चीजों को सही तरीके से करना चाहता हूं: स्वच्छ, समझने योग्य और सही कोड लिखना जो बनाए रखना आसान है। हालाँकि, मैं जो कर रहा हूं वह एक पैच पर पैच लिख रहा है; सिर्फ इसलिए कि कोई समय नहीं है, ग्राहक इंतजार कर रहे हैं, एक बग को रात भर में ठीक किया जाना चाहिए, कंपनी इस समस्या पर पैसा खो रही है, एक प्रबंधक कड़ी मेहनत कर रहा है, आदि।

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

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

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


12
सरल: इसे सही करने के लिए और तेजी से यह करना
रेन

158
@ren: ठीक है, मुझे लगता है कि आप एक प्रोग्रामर नहीं हैं, आप एक प्रबंधक हैं :-)
Flot2011

44
अनिवार्य। xkcd.com/844
माइकइलियार

5
इसे ASAP करें। फिर अगर आपके पास अभी भी समय है, तो इसे सही से करें।
लॉरेंट कौविदौ

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

जवाबों:


106

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

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

सॉफ्टवेयर कारीगरों, डेवलपर्स, प्रोग्रामर के रूप में, जो लोग एक नौकरी के लिए कोड करते हैं - यह "यह सही है" करने के लिए हमारा स्वाभाविक झुकाव है। "यह करो ASAP" जब हम जीवित रहने के लिए काम करते हैं तो ऐसा होता है, जैसा कि हम में से अधिकांश करते हैं। संतुलन कठिन है।

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

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

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

अंत में, वास्तविक जीवन सभी को रौंद देता है। यदि आप एक ऐसी कंपनी के लिए काम कर रहे हैं, जिसे आप जो विकसित कर रहे हैं उसे बेचने की जरूरत है, तो आप इस व्यापार-बंद का सामना रोजाना करेंगे। केवल अच्छे विकास सिद्धांतों को प्राप्त करने के लिए प्रयास करने से ही मैं कोड क्वालिटी वक्र से आगे रहने में सफल रहा।

डेवलपर्स और सेल्समेन के बीच धक्का और खींच मुझे एक मजाक की याद दिलाता है। "एक प्रयुक्त कार विक्रेता और एक सॉफ्टवेयर विक्रेता के बीच क्या अंतर है? कम से कम प्रयुक्त कार विक्रेता जानता है कि वह झूठ बोल रहा है।" अपनी ठोड़ी को ऊपर रखें और जाते समय "सही काम करने" का प्रयास करें।


14
"अक्सर बिक्री टीम हमें एक कमीशन पाने के लिए मुसीबत में डाल देती है" - आप किस बिंदु पर विचार करेंगे कि बिक्री को कुछ बेचने के लिए जिम्मेदार ठहराया जाना चाहिए जिसे व्यवसाय वितरित नहीं कर सकता - यह मानते हुए कि एक है? क्या आपके पास ऐसे उदाहरण हैं जहां उन्होंने आक्रामक विपणन और ओवरसेलिंग के बीच की रेखा को पार किया है?
टॉम डब्ल्यू

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

9
+1 - "मैं उस सुविधा में गुणवत्ता का बलिदान नहीं करूंगा जो ग्राहकों को चला रही है, उसे ASAP प्राप्त करने की आवश्यकता है, लेकिन कुछ जाएगा" ... यह शानदार था।
जोएल बी

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

4
मैं इस तरह का जवाब टाइप करने के लिए प्यार करता था, लेकिन मेरे पास एक ग्राहक है जो फोन पर अपने बॉस को देखता है। "अक्सर बिक्री टीम हमें एक कमीशन प्राप्त करने के लिए मुसीबत में पड़ जाती है।" यहाँ भी ... लेकिन किसी तरह वे अभी भी उन बोनस मिलता है!
केंजो

62

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

क्योंकि आप जानते हैं कि वास्तव में आपके प्रबंधक को आपको या आपके ग्राहक को धक्का देने से क्या होगा ? खराब गुणवत्ता


43
जबकि आमतौर पर एक अच्छा काम करने का समय होता है, आमतौर पर इसे पूरी तरह से करने का समय नहीं होता है। दोनों के बीच अंतर की दुनिया है।
डोना फेलो

2
@ डॉनलॉफेलो कोर्स। 'राइट' हमेशा "इस बिंदु पर समस्या की हमारी सर्वश्रेष्ठ समझ का उपयोग करते हुए, हमारी सर्वोत्तम क्षमता के अनुसार" सर्वोत्तम प्रथाओं का पालन करता है। लोग गलती करते हैं। आवश्यकताएँ बदल जाती हैं। सर्वोत्तम अभ्यास बदलते हैं। जब सामान होता है तो कोनों और रिफ्लेक्टर को न काटें ।
तेलस्टिन डे

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

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

7
+1 - टेलस्टाइन के लिए, जबकि सभी ग्राहक चाहते हैं कि उनका सामान अब किया जाए। अधिक ग्राहक चाहते हैं कि उनका सामान अब काम करने की तुलना में अधिक काम करे। ऐसा लगता है कि हर कोई जो तेलस्टिन के दावे से असहमत है, का दावा है कि अगर वह जल्दी से काम नहीं करता है तो वे एक ग्राहक खो देंगे। यह अब तक अपवाद नहीं है और नियम नहीं है। क्या नियम है, कि ज्यादातर लोग जो असहमत हैं, वह यह है कि वे इस बात को नजरअंदाज कर रहे हैं कि वे शोडर उत्पाद वितरित करके कहीं अधिक ग्राहकों को खो देंगे। दावा है कि ग्राहक अब यह गुणवत्ता के बारे में परवाह नहीं है लोगों द्वारा सामान्य बहाना है। इसलिए मुझे दावा किए गए जोखिम पर संदेह है।
डंक

21

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

  • संचारी मूल्य

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

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

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

  • वही लानत है पेज पर टीम जाओ

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

  • राइट टूल चुनें

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

  • एफएफएस, यदि इंजीनियर्स निर्णय नहीं लेते हैं, तो उपकरण लेने पर कम से कम इंजीनियर इनपुट प्राप्त करें

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

  • कार्यान्वयन पर डिजाइन पर ध्यान दें

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

  • अपनी चिंताएं दर्ज करें

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


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

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

19

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

संपादित करें: इस श्वेतपत्र में उल्लेखित "रखरखाव की बढ़ती लागतों की भरपाई" पर कुछ अच्छे संसाधन हैं: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf


12
एक बेहतर विकल्प है: आप नियमित रूप से कोडिंग की आदत का हिस्सा बना सकते हैं। Dayly। प्रति घंटा। जब भी आप किसी फ़ंक्शन को जोड़ते हैं या बदलते हैं। इसलिए आपको इसके लिए अतिरिक्त समय आरक्षित करने की आवश्यकता नहीं है, या "प्रबंधन को मनाएं"।
डॉक ब्राउन 13

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

1
@ Flot2011 फिर आपके पास केवल एक समाधान है। "दिन-प्रतिदिन" को प्रतिबिंबित करने को अपना नियमित कार्य मानें। उदाहरण के लिए हर tuesday केवल कोड की गुणवत्ता में सुधार पर ध्यान केंद्रित करता है। सुनिश्चित करें कि यह प्रबंधन द्वारा सम्मानित किया गया है और सुनिश्चित करें कि वे जानते हैं कि रिफैक्टरिंग समय की बर्बादी नहीं है। इन दोनों स्थितियों के बिना जल्दी या बाद में वे "कुछ ऐसा है जो पहले से ही यहाँ है और यह काम कर रहा है" सुधार के विचार को छोड़ देंगे।
आंद्रेज बोबाक

1
@DocBrown जब आप प्रबंधन से बात करते हैं तो यह काम करता है। यदि आप वरिष्ठ डेवलपर से बात करते हैं और उसे बताते हैं कि आप फॉर्म में दो फ़ील्ड जोड़ रहे हैं और इसमें आपको 3 दिन लगेंगे ... खैर शुभकामनाएँ :)।
आंद्रेज बोबाक

2
रखरखाव समय प्राप्त करने के लिए अपने अनुमानों को बढ़ाने के लिए कई कारणों से समस्याग्रस्त है। कभी-कभी तकनीकी ऋण वास्तव में खर्च करने योग्य होता है। क्या होता है जब बिज़ अचानक नोटिस करता है कि आपातकालीन स्थिति में दो नए खेतों को थप्पड़ मारने में 15 मिनट लग गए जब पिछली बार 8 दिन लगे थे। IMO, biz को तकनीकी ऋण और इसके दीर्घकालिक प्रभाव के प्रति सचेत रहने की आवश्यकता है। इस समस्या को समझने की जरूरत है कि या तो आप अभी भुगतान करते हैं या आप बाद में 5 बार भुगतान करते हैं जब सब किया जाता है।
एरिक रिपेन

14

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

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

यदि वह मदद नहीं करता है, तो अभी भी चीजों को सही करने के लिए पर्याप्त समय पाने के लिए "स्कॉटी की रणनीति" है: अपने सभी अनुमानों को 4 के कारक से गुणा करें:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/


स्कूटी की रणनीति काम करती है। बस अपने बॉस को पता न चलने दें कि आप यह कर रहे हैं। कई बार वास्तविकता में लगने वाला समय दोगुना होता है। हमेशा देर से जल्दी खत्म करना बेहतर होता है।
ल्यूक

11

मैं अपनी नौकरी को सर्वश्रेष्ठ गुणवत्ता सॉफ्टवेयर प्रदान करने के रूप में देखता हूं जो परियोजना के लिए समय की कमी के कारण संभव है। अगर मुझे चिंता है कि गुणवत्ता का स्तर कम होगा, तो मैं परियोजना के मालिक को संलग्न करूंगा। मैं अपनी चिंताओं का वर्णन करता हूं और उस राज्य में सॉफ्टवेयर को तैनात करने के संभावित जोखिमों पर चर्चा करता हूं। इस बिंदु पर 3 चीजों में से एक होगा:

  1. प्रोजेक्ट के मालिक जोखिमों को स्वीकार नहीं करना चाहते हैं और हमें सॉफ्टवेयर गुणवत्ता पर अधिक समय बिताने की अनुमति देने के लिए अनुसूची को वापस ले जाएंगे।

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

  3. परियोजना के मालिक जोखिमों को स्वीकार करेंगे और निम्न गुणवत्ता वाला सॉफ्टवेयर समय पर निकल जाएगा। कभी-कभी कुछ भी नहीं (या देर से तैनाती) को तैनात करने का व्यावसायिक जोखिम कम गुणवत्ता वाले सॉफ़्टवेयर को तैनात करने के व्यावसायिक जोखिम से बहुत अधिक होता है, और केवल परियोजना का मालिक ही यह निर्णय ले सकता है।

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


7

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


7

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

फिक्सिंग कोड जिसने सर्वोत्तम प्रथाओं का पालन नहीं किया है उसे अक्सर अधिक समय लगता है। यह पता लगाने की कोशिश की जा रही है कि कॉल निरस्त () की तरह लगने पर अशक्त कहां से आ रही है, इसमें लंबा समय लग सकता है।

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

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

जब भी संभव हो, न्यूनतम कार्य समाधान प्रदान करें। मैंने सप्ताह में सोने की बर्बादी के समाधान देखे हैं। स्कोप को लेकर बेहद सावधान रहें।

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

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

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


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

1
@ ErikReppen कोड जो भ्रामक, अवैध है और बड़े पैमाने पर कैस्केडिंग वंशानुक्रम योजनाओं का कार्यान्वयन DRY की मेरी परिभाषा को विफल करेगा। यदि आपको प्रत्येक बार कोड का उपयोग करने की आवश्यकता होती है, तो डिज़ाइन स्पष्ट रूप से DRY को विफल कर देता है भले ही कार्यान्वयन पास हो।
BillThor

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

6

इसे काम बनाओ तो इसे परिपूर्ण बनाओ

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

उम्मीद है कि इससे आपको इन मुद्दों पर लौटने और उन्हें सही बनाने में अधिक समय मिलेगा।

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

बस एक तरीका खोजें जो आपके लिए काम करे ; और फिर इसके साथ रहना। सभी के पास परियोजनाओं से निपटने का अपना तरीका है और कोई भी "एक आकार सभी फिट नहीं होता है"। एक दृष्टिकोण खोजें, और इसे अपना बनाएं।


3
जब प्रबंधन जानता है, कि यह काम करता है। वे इसे पूरा कर लेते हैं और नहीं चाहते कि आप रिफैक्टरिंग आदि पर कोई अन्य प्रयास करें
एड्रोनियस

5

"इसे सही करना" का अर्थ है किसी विशेष स्थिति के लिए सही ट्रेडऑफ़ बनाना। उनमें से कुछ हैं:

  1. विकास का समय और लागत
  2. पढ़ने में आसानी, डिबगिंग और बाद में कोड को अपडेट करना (चर नाम से वास्तुकला तक सब कुछ)
  3. समाधान की संपूर्णता (किनारे के मामले)
  4. निष्पादन की गति

जाहिर है, अगर कोड का एक टुकड़ा एक बार इस्तेमाल किया जाएगा और फेंक दिया जाएगा, तो # 2 को किसी भी अन्य के लिए बलिदान किया जा सकता है। (लेकिन खबरदार: आप सोच सकते हैं कि आप इसे फेंकने जा रहे हैं, फिर आप को इसका उपयोग करते हुए और इसे बनाए रखना होगा, जिस बिंदु पर लोगों को यह समझाने के लिए कठिन होगा कि आप कुछ "सुधार" करने के लिए समय दें।)

यदि आप और / या आपकी टीम कुछ कोड का उपयोग और अद्यतन करने जा रहे हैं, तो अब शॉर्टकट लेने का मतलब है कि बाद में खुद को धीमा करना।

यदि आप वर्तमान में छोटी गाड़ी कोड दे रहे हैं (# 4 पर कमजोर) और इसे करने में लंबा समय ले रहे हैं (# 1 पर कमजोर), और ऐसा इसलिए है क्योंकि आप कोड को अपडेट करने की कोशिश कर रहे हैं जो # 2, कमजोर पर था, आपने अपनी प्रथाओं को बदलने के लिए एक ठोस, व्यावहारिक तर्क मिला।


1
मैं सुझाव दूंगा: "अगर कोई NOBODY कभी कोड का एक टुकड़ा बनाए रखने जा रहा है ...": कचरा लिखना, डंप करना और चलाना एक विकल्प नहीं होना चाहिए (किसी व्यक्ति के लिए विवेक के साथ), लेकिन यह सब बहुत बार होता है; ठेकेदार / सलाहकार / प्रबंधक सुनिश्चित करते हैं कि वे पंखे से "हिट" होने से ठीक पहले दरवाजे से सुरक्षित बाहर निकल गए।
फिल डब्ल्यू।

@PhillW। - बिलकुल सहमत। तदनुसार संपादित किया गया।
नाथन लॉन्ग

4

यदि यह बग है, तो इसे ASAP करें, यदि यह एक नई सुविधा है, तो अपना समय लें।

और अगर आप किसी ऐसी कंपनी के लिए काम करते हैं, जो डेवलपर के काम का सम्मान नहीं करती है, तो आपके पास विकल्प नहीं हो सकता है लेकिन इसे तेजी से करें और गुणवत्ता पर बलिदान करें।

मैंने कई कंपनियों के लिए काम किया है, जो सिर्फ प्रोजेक्ट से प्रोजेक्ट पर जाएंगी, और सबकुछ तेजी से करेंगी। अंततः, उन्हें हर परियोजना में बहुत कम सफलता मिली क्योंकि कार्यान्वयन (सिर्फ प्रोग्रामिंग नहीं) के माध्यम से चला गया था।

वहां की सर्वश्रेष्ठ कंपनियां समझती हैं कि अच्छा सॉफ्टवेयर समय और शिल्प कौशल लेता है।


3

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


5
समस्या यह है कि लगभग कभी भी उपयुक्त समय नहीं है, यही समस्या है, और इस तरह के कीड़े को हमेशा सबसे कम प्राथमिकता मिलेगी।
Flot2011

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

3

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


3

यहाँ एक अच्छी योजना है:

  1. अपनी do-it-right योजना को do-it-asap की तुलना में ठीक उसी समय लें।
  2. अपने पर्यावरण को खुश होने तक इसे करने के लिए अपना समय अनुकूलित करें; गुणवत्ता बनाए रखें
  3. ???
  4. सफलता

1

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

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

अगर मैं ऐसा करता रहूं तो अक्सर मेरी दिनचर्या कोडिंग में सुधार होता रहेगा, मुझे लगता है।


1

सॉफ्टवेयर अजीब सामान है और सॉफ्टवेयर विकास प्रक्रिया अजीब है।

वास्तविक जीवन में अधिकांश चीजों के विपरीत, लेकिन अधिकांश चीजें कंप्यूटर के साथ करना पसंद करती हैं

तेजी से और अधिक विश्वसनीय है

यह हर उस अंतर्ज्ञान के खिलाफ जाता है जो आपने अभी तक जीवन को सिखाया है, उच्च स्तरीय कारें मानक लोगों की तुलना में अधिक बार टूट जाती हैं, जल्दी से निर्मित घर अधिक तेज़ी से टूट जाते हैं, स्कूल बस के पीछे किए गए होमवर्क को उच्च अंक नहीं मिलते हैं।

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


मुझे यकीन नहीं है कि मैं आपसे सहमत हूं लेकिन यह एक दिलचस्प, अपरंपरागत दृष्टिकोण है। बॉक्स से बाहर सोचने के लिए +1।
Flot2011

-1

नौकरी आपके लिए सही नहीं है।

निम्न गुणवत्ता कोड "क्योंकि कोई समय नहीं है, ग्राहक इंतजार कर रहे हैं, एक बग को रात भर में ठीक किया जाना चाहिए, कंपनी इस समस्या पर पैसा खो रही है, एक प्रबंधक कड़ी मेहनत कर रहा है" एक खराब प्रबंधित कंपनी का लक्षण है।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.