क्या सॉफ्टवेयर डेवलपर कंपनी की गुणवत्ता / मानकों की अनदेखी करते हैं? [बन्द है]

10

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

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

4 साल पहले बंद हुआ ।

क्या सॉफ़्टवेयर डेवलपर जो कोड प्राथमिकता, मानकों और सर्वोत्तम प्रथाओं को सर्वोच्च प्राथमिकता के रूप में नहीं रखना चाहते हैं, उन डेवलपर्स की तुलना में अधिक उपयोगी कोड बनाते हैं जो अनुकूलन, कोडिंग मानकों के कार्यान्वयन और समय पर कार्य पूरा करने के ऊपर प्रथाओं के बारे में चिंता करना चाहते हैं?

व्यक्तिगत प्रदर्शन समीक्षा के दौरान इन भिन्न तरीकों की तुलना कैसे की जाती है?

इन शैलियों की तुलना सहकर्मी समीक्षाओं में कैसे की जाती है?

एसडीएलसी के दौरान अधिक सर्वोत्तम प्रथाओं को लागू करने के लिए अपनी टीम को प्रभावित करने का सबसे अच्छा तरीका क्या है?

code-quality teamwork

— जितेन्द्र व्यास
स्रोत

2

@ हेल्मे - मुझे लगता है कि मैंने जो मूल संपादन किया वह बेहतर था। यदि शीर्षक पहले वाक्य के समान है, तो शीर्षक का क्या मतलब है?

— ब्लैकजैक

1

@ ब्लेकजैक मैं आपके शीर्षक को वापस लाया और प्रश्न को थोड़ा और परिष्कृत किया। मुझे लगता है कि हम तीनों को एडिट हिस्ट्री में एक ही पोस्ट पर पेट भरते हुए पकड़ा गया। अब अच्छा होना चाहिए।

— थॉमस ओवेन्स

4

एसई अपने मालिक के बारे में किराए के लिए जगह नहीं है। हम सभी के बॉस हैं और हम में से अधिकांश के पास कमांड की श्रृंखला में कोई है जो सोचते हैं कि वे वहां नहीं हैं (मुझे नहीं लगता कि वे महान / बेकार हैं)। उनके बारे में यहाँ कोई अच्छी बात नहीं है।

— सोय्लेंटग्रे

1

@Chad: जबकि मैं आपकी हर बात से सहमत हूं, मुझे पूरा यकीन नहीं है कि ओपी का मतलब अपने बॉस (सीधे) के बारे में कुतिया होना है।

— हाइलम

2

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

— हेयरस्टाइल

32

नहीं, वे केवल इस परियोजना के मालिक से सम्मान प्राप्त करेंगे।

वे वर्षों के लिए ट्रैश किए जाएंगे :

भविष्य के रखवाले,
भविष्य के परीक्षक,
भविष्य के परियोजना के मालिक,
भविष्य के प्रबंधक,
और भविष्य में कोडबेस के साथ बहुत ज्यादा किसी को शामिल किया गया।

वे भी उसी से इलाज करवा सकते हैं:

वर्तमान परीक्षक,
वर्तमान तकनीकी दस्तावेज लेखक।

— haylem
स्रोत

@ इवान: धन्यवाद। दीर्घकालिक सोच हमेशा जीतती है।

— हाइलम

@ हाइलम - मैं आपसे सहमत हूं क्योंकि लोग जल्दी से नौकरी बदल रहे हैं। नए कोडर्स को कोड को जल्दी समझने के लिए इतना बेहतर कोड उपयोगी होगा

— जितेंद्र व्यास

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

— anon

6

मिथ्या द्वंद्ववाद: गुण ऑर्थोगोनल हैं।

                उच्च गुणवत्ता कम गुणवत्ता

लाभदायक भयानक स्केच

लाभहीन Iffy आग पहले

— tottinge
स्रोत

5

क्या इफ्की स्केच से बेहतर या बुरा है?

— HLGEM

1

@HLGEM: लाभदायक हमेशा लाभहीन से बेहतर है।

— डोनाल्ड फेलो

कि स्केच गुणवत्ता द्वारा बनाई गई भविष्य की लागतों को नजरअंदाज करता है

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

1

केवल डेवलपर की पीठ पर लाभप्रदता को सौंपना एक ओवरसिम्प्लीफिकेशन है। उत्पाद प्रबंधन, तैनाती के बुनियादी ढांचे के बारे में कैसे? क्या उनकी भी लाभप्रदता में कोई भूमिका नहीं है?

— डेविड

5

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

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

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

— किलियन फोथ
स्रोत

6

सर्वोत्तम अभ्यास कम समय में सभी परियोजनाओं को सही ढंग से पूरा करने में मदद नहीं करते हैं। वे केवल ऐसी चीजें हैं जो ज्यादातर समय ज्यादातर परियोजनाओं पर अच्छी तरह से काम करने के लिए देखी गई हैं।

— थॉमस ओवेन्स

2

ब्लाइंड पालन "सर्वोत्तम प्रथाओं" या किसी और की चीजों को घोषित करने का सबसे अच्छा तरीका विकास प्रक्रिया के लिए है जो कार्गो पंथ कोडिंग कोडिंग प्रक्रिया के लिए है। आपको यह समझने में सक्षम होना चाहिए कि अभ्यास का क्या मतलब है, यह वास्तव में आपकी स्थिति में सबसे अच्छी बात है या नहीं और यदि नहीं, तो इसे क्या बदलना चाहिए।

— ब्लरफ्ल

5

क्या मैं उन डेवलपर्स से सहमत हूं जो कोड अनुकूलन और प्रथाओं के बारे में परवाह नहीं करते हैं? नहीं।

क्या वे वह काम करते हैं जो उन्हें करने की आवश्यकता है? हाँ।

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

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

— इवान
स्रोत

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

— जितेन्द्र व्यास

1

@ जितेंद्र - अगर आप सारा दिन पहले से लिखे सामान को अनुकूलित करने में बिताते हैं और मुझे कोई नई कार्यक्षमता नहीं मिलती है तो मुझे खुशी नहीं होगी। जब तक अनुकूलन आपको स्रोत कोड में लाइनों और वर्णों की कम संख्या के अलावा कुछ नहीं मिलता है तब तक आप कुछ भी पूरा नहीं कर रहे हैं।

— सोयालेंटग्रे

3

@ जितेंद्र - मैंने ऐसा नहीं कहा था। और अपने कोड को पठनीय तरीके से लिखना महान है। जब आप अपने स्वयं के कार्यों को देखते हैं, तो अन्य लोगों के कोड 'फिक्सिंग' के आसपास जा रहे हैं।

— सोयालेंटग्रे

1

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

— जितेंद्र व्यास

4

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

— ग्रेग बरगार्ड

4

नहीं, और मुझे उक्त कंपनी से दूर का सबसे तेज रास्ता मिल जाएगा जो उन लोगों की सराहना करता है।

2

+1, बिंदु तक और सही होने के लिए छोटा है। एक कंपनी जो गुणवत्ता मानकों के बारे में परवाह नहीं करती है वह या तो बेवकूफ है, अज्ञानी है या एक घोटाला है।

— वेन मोलिना

3

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

आप रखवाले से नफरत करेंगे, लेकिन अपने मालिक से प्यार करेंगे।

— निकोलस स्मिथ
स्रोत

3

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

क्या आप अंतरिक्ष उपग्रह के लिए मार्गदर्शन प्रणाली लिख रहे हैं (आप शायद नहीं हैं)? तब नर्क इस तरह के काम में कभी भी खराब गुणवत्ता / प्रदर्शन कोड स्वीकार्य नहीं है।

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

बीच में सब कुछ: परक्राम्य, विशेष रूप से लंबे समय तक देव प्रारंभिक समर्थन के लिए हुक पर है।

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

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

— बिल
स्रोत

2

वे कंपनी के लिए कितना पैसा कमाते हैं, यह बहस का मुद्दा है। यदि प्रश्न में कोड का पुनरीक्षण करने का स्तर है, तो रखरखाव की लागत बढ़ रही होगी और कोई व्यक्ति खुश नहीं होगा। उच्च दीर्घकालिक रखरखाव की लागत इसे ठीक से सामने करने की तुलना में अधिक महंगा है।

उन्हें कितना सम्मान मिलता है यह शायद मामला विशिष्ट है। किसी बिंदु पर, हालांकि, कोई नोटिस करेगा।

— temptar
स्रोत

2

इन चीजों की परवाह न करने से कंपनी को कम अवधि में अधिक पैसा मिल सकता है, लेकिन खर्च हो सकता है कंपनी को बग फिक्स और रखरखाव कोडिंग पर लंबी अवधि में अधिक पैसा करना ।

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

— FrustratedWithFormsDesigner
स्रोत

2

यह सब ग्राहक पर निर्भर करता है।

एक ग्राहक जो जल्दी और गंदे (और आमतौर पर सस्ता) पसंद करता है, उसे ध्यान नहीं है कि यह भविष्य में समस्याएं पेश करेगा।

सोचो कैबिनेट निर्माण।

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

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

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

केवल समय ही बताएगा। वही करें जो प्रबंधक चाहते हैं या दूसरी नौकरी पा सकते हैं।

— ElGringoGrande
स्रोत

1

बेशक सॉफ्टवेयर समर्थन के साथ आ सकता है इसलिए दोनों एक विकल्प हो सकता है। यानी हम ज्ञात मुद्दे के बावजूद v1 के साथ पहले बाजार में आएंगे, लेकिन हम जो पैसा कमाते हैं वह हमें भविष्य में मुद्दों को ठीक करने की अनुमति देगा आदि

— जेके।

1

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

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

— वेन मोलिना
स्रोत

1

एक अच्छा पढ़ा: http://www.joelonsoftware.com/items/2009/09/23.html

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

जो भी आप सोचते हैं, उसके बारे में झटका मत बनो।

संपादित करें: मैं किसी भी स्थिति का बचाव नहीं कर रहा हूं, इस कार्य के आधार पर मैं दोनों तरफ झुक सकता हूं।

— सांकेतिक शब्दों में बदलनेवाला
स्रोत

"सर्वोत्तम अभ्यास" पर निर्भर करता है IMO। परीक्षण (जरूरी नहीं कि टीडीडी लेकिन सामान्य रूप से स्वचालित परीक्षण) जैसी SOLIDचीजें, सिद्धांतों का पालन करते हुए, डिजाइन पैटर्न का उपयोग करते हुए, अमूर्त / इंटरफेस का उपयोग करते हुए आधारभूत हैं जो किसी भी सक्षम डेवलपर को करना चाहिए।

— वेन मोलिना

जितना मुझे परीक्षण पसंद है ... वे आधारभूत नहीं हैं।

— कैफीक

1

कंपनी के लिए बेहतर है? निर्भर करता है।

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

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

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

— timh
स्रोत

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

— वेन मोलिना

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

— 15

शायद, लेकिन छह साल के कॉर्पोरेट विकास में मुझे ठीक एक कंपनी मिली है जो समय के साथ कोड को रिफलेक्टर करने में सक्षम थी; प्रत्येक व्यक्ति के पास कभी भी संसाधन नहीं होते हैं जो कोड के असहनीय होने पर भी "जो ठीक नहीं है उसे ठीक करना" समर्पित करना।

— वेन मोलिना

0

डेवलपर और परियोजना / स्थिति पर निर्भर करता है।

असाधारण समय के लिए असाधारण उपायों की आवश्यकता होती है।

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

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

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

यह केस के आधार पर होता है। कोडिंग शैली को छोड़कर - वहाँ कोई बहाना नहीं है।

— डैनियल इवानकोव
स्रोत

0

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

सॉफ्टवेयर का प्राथमिक मूल्य यह है कि यह लचीला है।

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

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

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

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

लचीलेपन के मामले में कभी भी खराब गुणवत्ता का नहीं!

— प्रेस्टन
स्रोत

1

नेवर से नेवर। पूरे ऐप कूड़ेदान में फेंक दिए जाते हैं। एक सिस्टम से दूसरे सिस्टम में डेटा रूपांतरण एक बार उपयोग हो जाता है और सड़ जाता है।

— जेफ

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

— Ixrec