कोड की गुणवत्ता क्यों लोकप्रिय नहीं है?

Question

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

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

• शामिल हैं। मुझे पता है कि तकनीकी सीमाओं या समय सीमा दबाने के कारण यूनिट परीक्षण लिखना हमेशा संभव नहीं है, लेकिन मैंने देखा कि मामलों में यूनिट परीक्षण एक विकल्प होता। यदि कोई डेवलपर अपने नए कोड के लिए कुछ परीक्षण लिखना चाहता था, तो वह ऐसा कर सकता था। मेरा निष्कर्ष यह है कि डेवलपर्स परीक्षण लिखना नहीं चाहते हैं।

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

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

तो कोड गुणवत्ता इतनी अलोकप्रिय/उबाऊ क्यों माना जाता है?

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

Answer 1

• आलस्य/
• प्रबंधन बोरिंग माना महसूस कर रही यह अनावश्यक है - अज्ञानी रवैया "बस इसे सही करने के"।
• "यह छोटी परियोजना कोड गुणवत्ता प्रबंधन की जरूरत नहीं है" में बदल जाता है

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

Calculating vector flow control - PASSED 
Assigning flux capacitor variance level - PASSED 
Rerouting superconductors for faster dialing sequence - PASSED 
Running Firefly hull checks - PASSED 
Unit tests complete. 4/4 PASSED. 

कुछ भी तरह

यह उबाऊ हो सकता है अगर आप आप से रचनात्मक जीवन चूसना करने के लिए नहीं जा रहा है इसके बारे में बहुत ज्यादा लेकिन 10 या 20 मिनट कोडिंग के कई घंटे के बाद कुछ जटिल कार्यों के लिए कुछ यादृच्छिक परीक्षण लेखन खर्च करते हैं ।

Answer 2

यूनिट परीक्षण अतिरिक्त कार्य करता है। यदि कोई प्रोग्रामर देखता है कि उसका उत्पाद "काम करता है" (उदाहरण के लिए, कोई यूनिट परीक्षण नहीं), तो कोई भी क्यों? खासकर जब यह प्रोग्राम में अगली फीचर को लागू करने के रूप में लगभग दिलचस्प नहीं है, आदि। ज्यादातर लोग आलसी होते हैं जब यह नीचे आता है, जो काफी अच्छी बात नहीं है ...

Answer 3

कोड की गुणवत्ता संदर्भ विशिष्ट है और इसे सामान्य बनाने के लिए कठिन है इससे कोई फर्क नहीं पड़ता कि लोग इसे बनाने का कितना प्रयास करते हैं।

यह सिद्धांत और अनुप्रयोग के बीच के अंतर के समान है।

Answer 4

मुझे लगता है कि उत्तर प्रश्न के समान है 'कोड गुणवत्ता क्यों लोकप्रिय नहीं है?'

मेरा मानना ​​है कि शीर्ष कारण हैं:

डेवलपर्स की

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

Answer 5

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

वह रवैया आमतौर पर यूनिट परीक्षणों के रूप में पहनता है क्योंकि आप महसूस करते हैं कि उत्पादन वातावरण में पता लगाने के लिए आपको और अधिक से अधिक कीड़े गंभीर और कठिन लगती हैं।

Answer 6

यह मुझे इस Monty Python प्रहसन की याद दिलाता है:।।।।

"रोमांचक नहीं ऐसा नहीं है यह सुस्त है सुस्त सुस्त हे भगवान यह सुस्त है, यह इतना सख्त सुस्त और थकाऊ और उबाऊ और उबाऊ और है des-प्रति- एट-लाइ डुल। "

Answer 7

कोड समीक्षा एक सटीक विज्ञान नहीं है। Metrics किसी भी तरह से बहस योग्य हैं। उस पृष्ठ पर कहीं भी: "आप"

मान लें कि आपके पास 35 पैरामीटर वाले 5000 लाइनों का एक बड़ा कार्य है। आप इकाई को यह जांच सकते हैं कि आप कितना चाहते हैं, यह वही कर सकता है जो इसे करना है। जो भी इनपुट हैं। तो इकाई परीक्षण के आधार पर, यह कार्य "सही" है। शुद्धता के अलावा, कई अन्य quality attributes you might want to measure हैं। प्रदर्शन, मापनीयता, रखरखाव, उपयोगिता और ऐसे। क्या आपने कभी सोचा था कि सॉफ्टवेयर रखरखाव इतनी दुःस्वप्न क्यों है?

असली सॉफ्टवेयर प्रोजेक्ट गुणवत्ता नियंत्रण यह जांचने से कहीं अधिक है कि कोड सही है या नहीं। यदि आप V-Model of software development चेक करते हैं, तो आप देखेंगे कि कोडिंग पूरे समीकरण का केवल एक छोटा सा हिस्सा है।

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

• मापने के लिए क्या है?
• हम इसे कैसे माप सकते हैं?
• इसे मापने वाला कौन करेगा?
• मुझे इसे मापने से क्या लाभ/खोना होगा?

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

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

संपादित करें *

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

Answer 8

मैं कई कारणों से कहूंगा।

सबसे पहले, यदि एप्लिकेशन/प्रोजेक्ट छोटा है या बड़े पैमाने पर कोई वास्तव में महत्वपूर्ण डेटा नहीं है तो परीक्षण लिखने के लिए आवश्यक समय वास्तविक एप्लिकेशन लिखने के लिए बेहतर होता है।

एक सीमा है जहां गुणवत्ता की आवश्यकताएं इस स्तर के हैं कि इकाई परीक्षण की आवश्यकता है।

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

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

मैं सभी कोड निरीक्षण के पक्ष में हूं क्योंकि वे प्रोग्रामर अन्य प्रोग्रामर से अनुभव और कोड शैली साझा करते हैं।

Answer 9

"परीक्षण लिखने के लिए सामान्य बहाने हैं, लेकिन वे केवल बहाने हैं।"

क्या वे हैं? एक साथ कमरे में आठ प्रोग्रामर प्राप्त करें, उन्हें कोड गुणवत्ता को बनाए रखने के तरीके के बारे में एक प्रश्न पूछें, और आपको उनकी आयु, शिक्षा और वरीयताओं के आधार पर नौ अलग-अलग उत्तर मिलेंगे। 1 9 70 के युग कंप्यूटर वैज्ञानिक यूनिट परीक्षण की धारणा पर हँसे होंगे; मुझे यकीन नहीं है कि वे गलत होंगे।

Answer 10

यह दर्द का मूल मनोविज्ञान है। जब आप एक समय सीमा कोड गुणवत्ता को पूरा करने के लिए चल रहे हैं तो आखिरी सीट लेती है। हम इसे नफरत करते हैं क्योंकि यह सुस्त और उबाऊ है।

Answer 11

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

इसके अलावा, टिप्पणी "कूल" के रूप में नहीं है क्योंकि वास्तव में कोड का एक टुकड़ा टुकड़ा लिख ​​रहा है।

Answer 12

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

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

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

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

Answer 13

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

कोड गुणवत्ता के बारे में आप कितने अलग प्रश्न सोच सकते हैं? यही कारण है कि "कोड गुणवत्ता" के बारे में 50,000 प्रश्न नहीं हैं।

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

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

नहीं लेखन परीक्षण के लिए आम बहाने हैं, लेकिन वे केवल बहाने हैं। एक उसकी/उसके नए कोड के लिए कुछ परीक्षण लिखने के लिए चाहता है, तो यह संभव

ओह सच है? यहां तक ​​कि यदि आपका मालिक कहता है "मैं यूनिट परीक्षणों पर समय बर्बाद करने के लिए आपको भुगतान नहीं करूंगा"? भले ही आप कुछ एम्बेडेड प्लेटफार्म पर काम कर रहे हों, बिना यूनिट परीक्षण फ्रेमवर्क? भले ही आप एक कड़े समय सीमा के तहत काम कर रहे हों, कुछ दीर्घकालिक लक्ष्य को मारने की कोशिश कर रहे हैं, यहां तक ​​कि दीर्घकालिक कोड गुणवत्ता की लागत पर भी?

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

व्यक्तिगत रूप से, मैं "कोड गुणवत्ता" विचार-विमर्श से थक क्योंकि वे

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

मुझे निश्चित रूप से उच्च गुणवत्ता वाले कोड लिखने में रूचि है। मैं बस उन लोगों द्वारा बंद कर दिया जाता है जो आमतौर पर कोड गुणवत्ता के बारे में बात करते हैं।

Answer 14

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

शिक्षा और परामर्श उसमें सहायता कर सकता है, जैसा कि परीक्षण संचालित विकास कर सकता है। यदि आप पहले परीक्षण लिखते हैं, तो आप कम से कम परीक्षण करने की कोशिश करने के बजाय परीक्षण के बारे में सोच रहे हैं, इसलिए आप कोड कर सकते हैं ...

Answer 15

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

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

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

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

Answer 16

कोड की गुणवत्ता इतनी अलोकप्रिय क्यों है?

क्योंकि हमारा पेशा गैर-व्यावसायिक है।

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

Answer 17

कोड गुणवत्ता अलोकप्रिय है? मुझे उस तथ्य पर विवाद करने दो।

एजिल 200 9 जैसे सम्मेलन निरंतर एकीकरण, और परीक्षण तकनीकों और उपकरणों पर प्रस्तुतियों की एक बड़ी संख्या है। देवॉक्सक्स और जाजून जैसे तकनीकी सम्मेलन में भी उन विषयों का उचित हिस्सा है। निरंतर एकीकरण & परीक्षण (CITCON, जो 3 महाद्वीपों पर साल में 3 बार होता है) के लिए समर्पित एक संपूर्ण सम्मेलन भी है। असल में, मेरी व्यक्तिगत भावना यह है कि वे वार्ताएं इतनी आम हैं कि वे पूरी तरह से मेरे लिए उबाऊ होने के कगार पर हैं।

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

उसने कहा, हालांकि मुझे लगता है कि कोड गुणवत्ता चर्चा के लिए एक लोकप्रिय विषय है, मैं इस तथ्य से सहमत हूं कि डेवलपर्स (सामान्य रूप से) अच्छे, या पर्याप्त परीक्षण नहीं करते हैं। मेरे पास उस तथ्य के लिए एक उचित सरल व्याख्या है।

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

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

Answer 18

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

वहां देखा गया - देखा गया।

Answer 19

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

लंबा उत्तर: यह संक्षिप्त दृष्टि वाला दृष्टिकोण सॉफ्टवेयर विकास तक ही सीमित नहीं है। अमेरिकी मोटर वाहन उद्योग (या इसके बारे में क्या छोड़ा गया है) शायद इसका सबसे अच्छा उदाहरण है।

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

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

संपादित करें: बेशक, इन बुरी आदतों और कई अन्य असली कारण परामर्श फर्म जैसे थॉट वर्क्स के साथ-साथ वे भी बढ़ते रह सकते हैं।

Answer 20

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

Answer 21

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

Answer 22

कॉलेज छात्र या आउटसोर्स कर्मचारी से सस्ता ताजा स्थानांतरित होने की संभावना आपके कोड की पठनीयता के लिए सीधे आनुपातिक है।

Answer 23

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

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

Answer 24

प्रबंधन को सड़क के समय बचाने के लिए और अधिक समय बिताने के मूल्य पर बेचा जाना चाहिए। चूंकि वे वास्तव में "बग तय नहीं किए गए" को माप नहीं सकते हैं, इसलिए वे अक्सर परियोजना की लंबी अवधि की तुलना में अपनी तत्काल समय सीमा & शिप तिथि को पूरा करने के बारे में अधिक चिंतित हैं।

Answer 25

शायद हर जावा डेवलपर जानता है JUnit ...

मेरा मानना ​​है कि हालांकि अधिकांश या कई डेवलपर्स JUnit/NUnit/अन्य परीक्षण चौखटे के बारे में सुना है, कम पता है कि कैसे एक परीक्षण इस तरह के एक ढांचे का उपयोग कर लिखने के लिए । और उन लोगों से, बहुत कम लोगों को समाधान के एक हिस्से का परीक्षण करने के बारे में अच्छी समझ है।

मुझे कम से कम 7 वर्षों के लिए यूनिट परीक्षण और इकाई परीक्षण ढांचे के बारे में पता चला है। मैंने 5-6 साल पहले एक छोटी परियोजना में इसका इस्तेमाल करने की कोशिश की, लेकिन पिछले कुछ सालों में मैंने यह सीखा है कि इसे सही तरीके से कैसे किया जाए। मेरे लिए (। यानी एक तरह से है कि मुझे और मेरी टीम के लिए काम करता पाया ...)

उन चीजों में से कुछ इस प्रकार थे:

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

तो सही रास्ता खोजने तक; हाँ, यह सुस्त, गैर पुरस्कृत, ऐसा करने के लिए कड़ी मेहनत, समय लेने, आदि है

संपादित करें: इस blogpost मैं इकाई परीक्षण के खिलाफ यहां दिए गए कारणों में से कुछ पर गहराई में जाना है।

Answer 26

'कोड गुणवत्ता' की कमी उपयोगकर्ता, विक्रेता, वास्तुकार और न ही कोड के डेवलपर की लागत नहीं है; यह अगले पुनरावृत्ति को धीमा कर देता है, लेकिन मैं कई सफल उत्पादों के बारे में सोच सकता हूं जो बाल और मिट्टी से बने होते हैं।

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

मेरा निष्कर्ष यह है कि डेवलपर्स परीक्षण लिखना नहीं चाहते हैं।

मुझे यकीन नहीं है। आंशिक रूप से, सॉफ़्टवेयर में पूरी शिक्षा प्रक्रिया परीक्षण संचालित नहीं होती है, और शायद यह होना चाहिए - व्यायाम करने के लिए कहने के बजाय, छात्रों को यूनिट परीक्षण दें। चेक चलाने के लिए गणित के प्रश्नों में सामान्य बात है, सॉफ्टवेयर इंजीनियरिंग में क्यों नहीं?

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

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

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

कोडिंग सम्मेलनों मैंने देखा है जो स्वचालित नहीं किया गया है तार्किक असंगत किया गया है, कभी कभी व्यर्थ जा रहा है की बात करने का हर सेट - यहां तक ​​कि लोगों ने दावा किया है कई परियोजनाओं में 'सफलतापूर्वक' इस्तेमाल किया गया है करने के लिए। गैर-स्वचालित कोडिंग मानक तकनीकी दस्तावेजों के बजाय राजनीतिक प्रतीत होते हैं।

आमतौर पर संभावित नल पॉइंटर एक्सेस जैसे कंपाइलर चेतावनियों को अनदेखा कर दिया जाता है।

मैंने कभी ऐसी दुकान में काम नहीं किया है जहां कंपाइलर चेतावनियां बर्दाश्त की गई थीं।

Answer 27

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

स्टेटिक विश्लेषण वास्तव में अच्छा है, हालांकि यह केवल चेतावनियां है। उदाहरण के लिए FindBugs में कास्टिंग के साथ समस्या है और आपको चेतावनी देने के लिए instaceof का उपयोग करना चाहिए। मैं सिर्फ FindBugs को खुश करने के लिए ऐसा नहीं करता हूं।

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

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

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

Answer 28

कोड गुणवत्ता व्यक्तिपरक है। विषयपरक विषय हमेशा थकाऊ होते हैं।

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

99% समय, खराब कोड गुणवत्ता के लिए कोई तीसरा पक्ष नहीं है (जब तक आप स्पेसशटल या ट्रेन स्विचिंग सॉफ्टवेयर नहीं बना रहे हों) ।

• क्या यह काम करता है? = कंक्रीट।
• क्या यह सुंदर है? = दर्शक की नजर में।

फ्रेड ब्रूक्स 'द मिथिकल मैन महीने पढ़ें। कोई रजत बुलेट नहीं है।

Answer 29

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

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

Answer 30

लोगों के पास कोड के "अच्छे" साधनों का सामान्य ज्ञान नहीं है। बहुत से लोग "मैंने इसे चलाया" या यहां तक ​​कि "मैंने इसे लिखा" के स्तर पर छोड़ दिया।"

हम क्या अच्छा कोड है का एक साझा भावना के कुछ प्रकार की आवश्यकता है, और क्या यह मायने रखता है कि के पहले भाग के लिए, मैं कुछ विचार ऊपर लिखा है:।

http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html

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

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

Answer 31

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

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

कोई आपके परीक्षण तोड़ सकता है और कह सकता है कि उसे यह नहीं पता कि उसे कैसे ठीक किया जाए या टिप्पणी करें (यदि आप मेवेन का उपयोग करते हैं)।

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

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

Answer 32

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

अतिरिक्त कारक, जैसे खराब विश्लेषण और ग्राहक जो अंतिम मिनट के परिवर्तन के साथ आते हैं, "गुणवत्ता" कोड का उत्पादन भी कठिन बनाते हैं।

Answer 33

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

मैं एक बार कोड भर गया कि टेक्स्ट की छपाई के बजाय डेटाबेस के प्रत्येक प्रविष्टि के माध्यम से भाग गया, इसके बजाय उस पाठ को एक चर में जोड़ दिया गया, और लूप के बाद इसे मुद्रित किया गया।

कोड मेरे लिए विफल रहा। यह स्मृति सीमा से अधिक है।

Answer 34

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

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

जब तक नए आईटी बिजनेस मॉडल बिलिंग के टी & एम से आगे नहीं उभरे, हम उम्मीद नहीं कर सकते कि कोड गुणवत्ता की जगह होगी।

मेरे विचार से कुछ पर

कैसे आईटी ऑफ शोरिंग व्यापार मॉडल बदलना चाहिए

http://communities.nasscom.in/discussion/topics/531869/messages

संक्षेप में समय और शरीर (टी & एम) से स्थानांतरित करने पर विचार व्यापार में समय के लिए और परिणाम की जवाबदेही हैं (टी & ए)