यदि एक धाराप्रवाह कोडर अच्छी प्रथाओं की अवहेलना करता है, तो क्या उसका प्रवाह उसके खिलाफ काम नहीं करता है? [बन्द है]


16

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

एप्लिकेशन का महत्वपूर्ण हिस्सा इंटर्न, n00bs आदि द्वारा लिखा गया था; लेकिन मास्टर डेवलपर के पद पर एक प्रोग्रामर भी रहा है, और सभी विनम्रता के साथ, जिस कोड को वह पीछे छोड़ गया है वह संदिग्ध है और साथ ही साथ एक अलग तरीके से भी।

दी, उसका कोड काम पूरा करने के लिए जाता है - ज्यादातर समय - लेकिन यह आम तौर पर गुप्त है, पहिया को सुदृढ़ करना (जैसे कि एक सामान्य कस्टम डीबी बैकअप को पूरा करने वाला एक बड़ा कस्टम तरीका) आदि, मूल रूप से, अनावश्यक भ्रम और अतिरंजना के बहुत सारे।

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

यह मानते हुए कि यह सच है, कुछ कारण जो मैं सोच सकता था:

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

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

उसके बारे में क्या ख़याल है? क्या यह सच है (यदि हां तो किस हद तक)?


24
"मुझे एक पेड़ को काटने के लिए छह घंटे का समय दें और मैं पहले चार कुल्हाड़ियों को तेज करने में खर्च करूंगा।" - एब्राहम लिंकन "अपने समय पर अपने कुल्हाड़ी को तेज करें।" - अधिकांश बॉस
जेफ

15
शीर्षक के कारण मेरे लिए यहाँ कुछ भ्रम है, जब मैंने 'धाराप्रवाह' पढ़ाI.ThinkOf(this).KindOfThing()
बेन्जोल

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

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

1
अत्यधिक संबंधित: यह और यह । कुछ (बहुत सारे) लोग इस अवस्था में फंस जाते हैं ...
BlueRaja - Danny Pflughoeft

जवाबों:


22

यदि आप आसानी से कोडिंग कर रहे हैं, तो यह महसूस होता है (या वास्तव में, कम समय में) बस मौके पर अपने स्वयं के समाधान को स्नैप करने के लिए तेज है, पुस्तकालयों की ओर मुड़ते हुए, बिना किसी कार्यक्षमता के आदि।

हाँ। मैं वह आदमी रहा हूं। और मैंने सीखा है कि यह एक भयानक बात है।

यह आपके लिए बहुत अच्छा है, आपको कुछ नया सीखने की जरूरत नहीं है।

लेकिन आपकी टीम के बाकी खिलाड़ियों का क्या? वे आप पर बहुत भरोसा करते हैं। वे आपके द्वारा लिखे गए ऑब्जेक्ट-रिलेशनल मैपर पर सहायता प्राप्त करने के लिए "क्लाइव की क्विक ओआरएम" के लिए Google नहीं कर सकते।

और फिर वह दिन आता है जब उन्हें किसी नए व्यक्ति को नियुक्त करने की आवश्यकता होती है और वे क्लाइव के क्विक ओआरएम में अनुभव वाले लोगों की तलाश नहीं कर सकते।

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

हां, हाइबरनेट सीखने से कुछ हल्का लिखने में अधिक समय लग सकता है। लेकिन ऐसा करने का फायदा इमो को नजरअंदाज करने के लिए बहुत अच्छा है।


1
मैं वह आदमी भी रहा हूं - और मैं दूसरे वाक्य से असहमत हूं। अधिकांश समस्याओं को हल करने में सक्षम होने का मतलब यह नहीं है कि आपके समाधान मजबूत, बनाए रखने योग्य, लचीले, स्केलेबल हैं ... या यहां तक ​​कि प्रारंभिक कार्यान्वयन को भी विकसित किया गया है। भाषा / पुस्तकालय संदर्भ पुस्तिकाओं के बाहर आपके द्वारा सीखे जाने वाले बहुत सारे विचार ऐसी चीजें हैं जो "मैंने ऐसा क्यों नहीं सोचा?" सरल, और भी लचीला, स्केलेबल, आदि। सबसे बुरी चीजों में से एक - यह महसूस करना कि मैं पहले एक विचार से अवगत कराया गया था, फिर भी इसे बिना किसी व्यावहारिक उपयोग के एक निरर्थक अकादमिक गैरबराबरी के रूप में खारिज कर दिया, इसलिए जब मुझे इसकी आवश्यकता हुई ...
Steve314

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

2
@ टोबी: फेयर पॉइंट। लेकिन वे कंपनियां आम तौर पर वैसे भी बचत से परे हैं।
पीडीआर

यूएस एयर फोर्स का उल्लेख नहीं करना वैसा ही है जैसा कि उन कंपनियों का उल्लेख है। हमने रूबी को रेल के माध्यम से धक्का देने की कोशिश की, लेकिन उन्हें यह पसंद नहीं आया।
ट्रैविस पेसेटो

@ कुछ ऐसे मामले हैं जहां पहिया को फिर से मजबूत करना सही काम है, कुंजी यह सुनिश्चित करना है कि आप यह समझें कि आप क्यों हैं
जेके।

14

• यदि आप आसानी से कोडिंग कर रहे हैं, तो यह महसूस होता है (या वास्तव में, कम समय में) बस मौके पर अपने स्वयं के समाधान को स्नैप करने के लिए तेज है, पुस्तकालयों की ओर मुड़ते हुए, बिना किसी कार्यक्षमता के आदि।

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

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

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


1
हाँ सचमुच। और मुझे लगता है कि मैं इस तरह के लोगों के प्रति अधिक विरोधाभास करूंगा यदि मैंने उनके बाद साफ करने के लिए आने वाले वर्षों में अच्छा जीवन नहीं कमाया ... ;-)
माइक वुडहाउस

4

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

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

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


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

मैं भाग्यशाली रहा हूं। मुझे स्थानांतरित करने के बाद घर से काम करने की अनुमति दी गई थी। हर कोई जानना चाहता है कि क्या यह हो गया है और क्या मैं काम नहीं कर रहा हूं। मैं जवाब जानने के लिए दंडित नहीं होने जा रहा हूँ।
जेफ

3

100%।

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

संक्षेप में, धाराप्रवाह कोडर प्रतियोगियों की भीड़ से अधिक नुकसान कर सकते हैं, लेकिन कीमत आमतौर पर कई वर्षों से भुगतान की जाती है। और वे आमतौर पर अपना काम कर रहे थे (जैसा कि किसी और द्वारा परिभाषित किया गया है)।

कैसे बताएं कि आप डेवलपर या कोडर हैं? मुझे लगता है कि यह असंभव है, लेकिन हर बार जब आप गुणवत्ता को कम करने के बिना अपने कोड को सरल बनाने का एक तरीका ढूंढते हैं, तो आपने आत्मज्ञान की ओर एक और कदम बढ़ाया है।


1

आपके द्वारा वर्णित समस्या मूल रूप से NIH ("यहां आविष्कार नहीं किया गया") - क्या अन्य लक्षण हैं?

कभी-कभी NIH, विशेष रूप से अगर यह एक या दो लोगों के लिए अलग-थलग है, तो एक समूह चर्चा में निपटा जा सकता है ("जो यहाँ मानक पुस्तकालयों का उपयोग करते हुए SQL बैकअप करने में कुछ अनुभव है - आपको क्या लगता है, जो?")। यह आप से सीधे टकरा सकता है, बस सीधे उस व्यक्ति के पास जा रहा है और कह रहा है "अरे! मानक पुस्तकालय का उपयोग करें, डमी!" :)


1

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

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


0

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

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

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


यह पूछे गए प्रश्न का उत्तर कैसे देता है?
कुटकी

@gnat सवाल "आप उस बारे में क्या सोचते हैं?", मेरा जवाब वही था जो मैंने सोचा था। मैं अभी भी एक ही राय का हूँ: प्रवाह (इस प्रकार त्वरित समाधान, हैक्स, आदि करने में सक्षम) लंबे समय में हानिकारक कोड का कारण बन सकता है। आप बस एक भाषा में धाराप्रवाह नहीं हो सकते, आपको यह जानना होगा कि कोड को कैसे व्यवस्थित किया जाए।
MPelletier
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.