सर्वोत्तम अभ्यास को अपनाने में क्या बाधाएँ हैं? उन्हें कैसे दूर किया जा सकता है? [बन्द है]

Question

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

सबसे स्पष्ट जवाब (मेरे लिए) "अज्ञान" है, लेकिन मुझे यकीन है कि एकमात्र कारण नहीं है। अन्य क्या हैं? खराब कोड लिखने के प्रलोभन को दूर करने के लिए हम क्या कर सकते हैं?

Comments

लागत ---------- सरल में सादा।

— डस्टप्रोग्रामग्राम

क्या कारण है कि आप आज यह कह सकते हैं कि कोड खराब तरीके से लिखा गया है, ऐसा क्यों लिखा गया?

@ Thorbjørn: मुझे क्षमा करें, मुझे यह प्रश्न समझ में नहीं आया?

— क्रामि ने मोनिका

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

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

— एसके-तर्क

Answer 1

परिवर्तन का विरोध।

वह अज्ञानता, खराब प्रबंधन आदि के पीछे प्रमुख चालक है।

पीपुल्सवेयर 2 संस्करण का अध्याय 30 इस विषय के लिए समर्पित है। और यह एक किताब से एक और काफी प्रसिद्ध सलाहकार द्वारा उद्धृत किया गया है, हालांकि थोड़ा पहले लिखा गया है:

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

निकोलो मैकियावेली: द प्रिंस (1513)

डेमार्को और लिस्टर लोगों को बदलने के लिए कहने से पहले ध्यान रखने के लिए मंत्र बताते हैं:

परिवर्तन की मौलिक प्रतिक्रिया तार्किक नहीं, बल्कि भावनात्मक है।

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

धैर्य और दृढ़ता के साथ, अंततः टीम कैओस से अगले चरण, अभ्यास और एकीकरण तक पहुंचती है। लोग, हालांकि नए उपकरणों / प्रक्रियाओं के साथ पूरी तरह से सहज नहीं हैं, इनमें से लटका पाने के लिए शुरू करें। सकारात्मक "अहा" अनुभव हो सकते हैं। और धीरे-धीरे, टीम एक नई स्थिति प्राप्त करती है।

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

---

संदर्भ के लिए, ऊपर वर्णित चरणों को मूल रूप से व्यंग्य परिवर्तन मॉडल ( वर्जीनिया सतिर के नाम पर ) में परिभाषित किया गया था ।

Comments

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

— एंड्रयूकेस

@AndrewKS, यह न केवल डेवलपर्स बल्कि प्रबंधकों और ग्राहकों को भी चिंतित करता है। एक अच्छी विकास टीम और प्रक्रिया में, समय सीमा वास्तविक होती है और डेवलपर्स को उनकी वर्तमान क्षमताओं के ऊपर कार्य सौंपे नहीं जाते हैं - या कम से कम उचित सलाह और सत्यापन के बिना नहीं। इनमें विफलता लगभग हमेशा एक संकेत है कि प्रबंधन सर्वोत्तम प्रथाओं को अपनाने का विरोध करता है।

— पेटर टॉर्क

वास्तव में अच्छा बिंदु - मैं अब तक इस स्थिति में गैर-प्रोग्रामर के बारे में नहीं सोच रहा था।

— एंड्रयूक्र्स

अनिच्छा के परिणामस्वरूप अक्सर एक निश्चित आलस्य होता है, जो अंततः अज्ञानता पैदा करता है।

— S.Robins

Answer 2

पेटर टॉर्क सही है, लेकिन एक महत्वपूर्ण और आशावादी बिंदु छोड़ दिया है:

• लोग उस बदलाव को पसंद कर सकते हैं जिसमें वे शामिल हैं, लेकिन वे लगभग कभी भी ऐसे बदलाव को पसंद नहीं करते हैं जो उनके लिए "होता है"

इसलिए उन्हें शामिल होने दें, उन्हें विचारों का योगदान करने दें, उन्हें इसमें हिस्सेदारी बनाने दें, और यह इतना दर्दनाक नहीं होगा

नोट: यह प्रोग्रामिंग के लिए प्रासंगिक है जिसमें कई तकनीकी रूप से सफल सॉफ़्टवेयर प्रोजेक्ट विफल हो जाते हैं क्योंकि उपयोगकर्ता उन्हें अस्वीकार कर देते हैं ।

Comments

वास्तव में परिवर्तन को प्रबंधित करने का एक शानदार तरीका

— न्यूटोपियन

आपको बिकेशिंग से सावधान रहने की आवश्यकता है ! उन्हें शामिल करने मत देना!

— शेप दें

Answer 3

जहाँ मैं काम करता हूँ वहाँ समय बड़ा लगता है।

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

(यह स्पष्ट रूप से अच्छी तरह से समाप्त नहीं होता है)

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

Comments

यहां समय बहुत बड़ा है। मेरे बॉस ने वास्तव में एक स्टाफ मीटिंग में हमसे कहा, "बिज़नेस महान काम के लिए भुगतान नहीं करता है"।

— जोशुआ स्मिथ

@ जोशुआ स्मिथ: wtf !? गंभीरता से? मुझे आश्चर्य नहीं होगा यदि वे ठीक वैसा ही प्राप्त करें जैसा वे करते हैं ।

— स्टीवन एवर्स

मैंने अक्सर यह देखा है कि हम इसे सही नहीं कर सकते। लेकिन, हम गंदगी को ठीक करने के लिए अंतहीन समय व्यतीत कर सकते हैं। परामर्श देने वाली कंपनियों के लिए कि घंटे के हिसाब से, कौन सा दृष्टिकोण सबसे अच्छा है?

— बिलथोर

@jwenting: अपनी पिछली टिप्पणी को संदर्भ में रखने के लिए, मैं एक स्टाफ मीटिंग में यूनिट परीक्षणों की वकालत कर रहा था। वर्तमान में, हम में से केवल दो यूनिट परीक्षण लिख रहे हैं (और हमें धूर्त पर ऐसा करना होगा)। व्यक्तिगत रूप से मैं इकाई परीक्षणों को सोने की छंटनी और हीरे की सजावट नहीं मानता।

— जोशुआ स्मिथ

@shapr: जो कि ROCKETS और MISSILES को बनाने वाली कंपनी से सुनने के लिए भयानक बात है। >: पी

— श्री जावास्क्रिप्ट

Answer 4

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

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

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

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

इसके प्रमाण के रूप में, अपने आप से पूछें कि आपने आखिरी बार किसी को गोटो का उपयोग करते देखा था।

Comments

+1: दूर करने का सबसे अच्छा तरीका उदाहरण के द्वारा नेतृत्व करना है, सबसे अच्छा अभ्यास खुद को अपनाकर। "आपको वह परिवर्तन होना चाहिए जो आप दुनिया में देखना चाहते हैं।" ?

— Johnsyweb

Answer 5

यह न जानने या सोचने का परिणाम है कि कोई आदर्श विधि जानता है। लोग खराब तरीके से कोड लिखना पसंद नहीं कर रहे हैं ; यह बेहतर नहीं जानने का मामला है। " नाइंटी ", " अज्ञानता " के विपरीत एक बेहतर शब्द होगा।

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

Comments

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

— जस्टिन

Answer 6

दो कारण

• अज्ञान।

• अहंकार।

उन्हें कैसे दूर किया जा सकता है?

• प्रोत्साहन राशि।

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

Comments

यह सच है: विशेष रूप से घातक अज्ञानी + अभिमानी कॉम्बो।

— स्किलिव्ज

Answer 7

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

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

अधिकांश "सर्वश्रेष्ठ अभ्यास" अभ्यास मुनाफे में सुधार नहीं करते हैं। जो व्यापक रूप से अपनाए जाते हैं, उन्हें करना चाहिए। इसलिए "सर्वश्रेष्ठ अभ्यास" का अभ्यास नहीं किया जाता है।

Answer 8

स्वीकार्य जोखिम

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

आखिरकार, आप पर्याप्त बार जल जाते हैं और आप अपने तरीके बदलते हैं। उन सभी 'सर्वोत्तम प्रथाओं' के बारे में सोचें जो वहाँ हैं। क्या आप उन सभी का पालन कर सकते हैं? क्या कोई एक दूसरे के विरोधाभासी है? आप हर आउटलाइन को संभालने में समय बर्बाद नहीं करना चाहते हैं।

यदि मैं बुरा कोड लिखता हूं जो काम करता है और कोई भी इसे फिर से नहीं देखता है, तो क्या यह अभी भी बुरा माना जाता है? (कृपया, 'बुरा कोड' क्या है, इस पर बहस करके दार्शनिक बहस को बर्बाद न करें।)

Comments

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

— श्री जावास्क्रिप्ट

Answer 9

IME यह एक संयोजन है जो अन्य लोगों ने कहा है। अज्ञानता ("मैंने केवल DataSets का उपयोग किया है, इस LINQ सामान से क्यों परेशान हैं?", समय की कमी ("बॉस चाहता है कि जितनी जल्दी हो सके, हम उस पर बहुत समय खर्च नहीं कर सकते"), अभाव समझ ("कोड-पीछे में मेरे सभी कोड लिखने में क्या गलत है?") सभी योगदान करते हैं।

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

Answer 10

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

एक सिद्धांत है कि डेवलपर्स 'जानबूझकर आलसी' हैं। दूसरे शब्दों में, वे कम से कम प्रतिरोध का रास्ता चुनते हैं।

एक बार जब आप जल्दी से उन्हें एक बेहतर अभ्यास के लाभ दिखाते हैं (जैसे कि टीडीडी, या कहें, एसओएलआईडी सिद्धांतों का पालन करते हुए) और यह वास्तव में उन्हें बेहतर (लेकिन अभी भी 'आलसी') डेवलपर होने की अनुमति देता है, तो आप उस प्रतिरोध को पिघलाते हैं। दूर।

यह शिक्षा की बात है :)

Comments

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

— बिलचोर

"कम से कम प्रतिरोध" काफी वर्णनात्मक है। अनुभवी प्रोग्रामर को बस इस बात का बेहतर अंदाजा है कि आवेदन के पूरे जीवनकाल में "कम से कम प्रतिरोध" का क्या मतलब है।

Answer 11

(अभाव) ज्ञान और कौशल + निवेश करने का समय

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

इस तथ्य के अलावा कि XCode ने इन दिनों यूनिट-इन-परीक्षण किया है, मेरे पास कोई सुराग नहीं है कि कहां से शुरू करें। क्या मैं इस बात पर जोर देता हूं कि उन्हें बनाने के लिए एक रूटीन चलाने के बाद उस पर एक्स बटन हैं? इस बात का पता लगाने के बारे में कि मेरे टैग को कॉल करने के बाद मेरे UIView को उचित रूप से व्यवस्थित किया गया है?

हेक, मैं एक्सकोड में एक इकाई परीक्षण भी कैसे लिख सकता हूं ? मुझे सीखने में समय बिताने की जरूरत है।

Answer 12

@ ज़ूस और @ जोशुआ स्मिथ

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

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

यूनिट टेस्ट के लिए भी। दुर्भाग्य से मैं एक ग्राहक से मिलना बाकी हूं, जो उन लोगों के लिए बजट आवंटित करने के लिए तैयार है। विशिष्ट उत्तर की तरह है “स्वचालित प्रतिगमन परीक्षण ठीक है मैं समझता हूं लेकिन इकाई परीक्षण? हमारे पास उसके लिए समय नहीं है! हमें इसे तेजी से बाजार में लाने की जरूरत है! ”

Comments

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

— न्यूटोपियन

दुर्भाग्य से, बेहतर प्रोग्रामिंग तकनीक उन तकनीकों की तुलना में तेज़ हो सकती हैं जिन्हें आप सुधारना नहीं कर सकते।

— बिलथोर

Answer 13

मेरे अधिकांश अनुभव में दो भाग:

• पहर
• पर्याप्त लोगों को इस बात पर सहमत होने के लिए कि मौजूदा स्थिति के लिए क्या अभ्यास सर्वोत्तम हैं

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

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

Answer 14

कभी-कभी, आप पाएंगे कि भयानक कोड लिखने में आदत का भी बड़ा योगदान होता है।

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

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

हम में से उन लोगों के लिए विचार के लिए कुछ भोजन जो केवल नकारात्मक निष्कर्ष पर छलांग लगाने के लिए आसान लगता है ... भले ही दुख की बात है कि आप अधिक बार नहीं सही होंगे।

Answer 15

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

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