मैं उच्च गुणवत्ता कोड को कैसे बढ़ावा और प्रोत्साहित कर सकता हूं?

Question

मैं 4 लोगों की टीम में एक छोटी आउटसोर्सिंग कंपनी में iOS डेवलपर के रूप में काम करता हूं। हम एक ऐसे प्रोजेक्ट पर काम करते हैं, जिसमें कुछ साल पहले मैंने और दो अन्य डेवलपर्स ने कंपनी को ज्वाइन किया था। इससे पहले परियोजना ज्यादातर एक व्यक्ति द्वारा की जा रही थी।

जब मैंने प्रोजेक्ट पर काम करना शुरू किया तो यह पूरी तरह गड़बड़ था। बहुत कोड पुनरावृत्ति हुई। मैंने समान 500 कोड को मामूली बदलावों के साथ 20 अलग-अलग फाइलों में कॉपी किया। इसके अतिरिक्त, यह बिल्कुल अच्छी तरह से व्यवस्थित नहीं था: सभी UI निर्माण कोड को तर्क के साथ व्यू कंट्रोलर्स में मिलाया गया था।

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

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

कभी-कभी मुझे लगता है कि अगर यह आईडीई के लिए नहीं था, तो मुझे लगता है कि वे सभी कोड को बिना किसी इंडेंटेशन या फॉर्मेटिंग के लिखेंगे।

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

यह अधिक से अधिक महसूस करता है कि उन्हें सीखने या परवाह नहीं करने के लिए परेशान नहीं किया जा सकता है: वे बस वही करते हैं जो उनसे आवश्यक है और घर जाते हैं। जब मैंने मौका दिया (मैंने उनके PR या GitHub पर टिप्पणी की) तो मैंने उन्हें कुछ सुझाव देने की कोशिश की। मैंने एक बार अच्छी तरह से कोडिंग शैली और मौजूदा कोड के बहुमत के प्रारूपण का पालन करने के लिए कहा (दुख की बात है कि हमारे पास औपचारिक कोडिंग दस्तावेज़ दस्तावेज़ नहीं है)। लेकिन यह काम नहीं किया ...

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

Comments

क्या, अगर कुछ भी हो, तो क्या आपके पास टीम के लीडर्स / सीनियर डेवलपर्स / मैनेजर हैं?

— फिलिप केंडल

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

— डॉक्टर ब्राउन

Answer 1

सिखाओ और अभ्यास करो जो तुम प्रचार करते हो।

आपको पता है कि यह सामान महत्वपूर्ण है। यह सही नहीं होने पर आप नकारात्मक पक्ष को जानते हैं।

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

इसकी जरूरत है:

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

शब्द में इसकी आवश्यकता है

नेतृत्व

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

Answer 2

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

लेकिन पहले, चलो एक महत्वपूर्ण पहलू के बारे में बात करते हैं: कंपनी में आपकी भूमिका।

आपकी भूमिका

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

दोनों ही मामलों में, पदानुक्रम में आपकी जगह क्या मायने रखती है, और अधिक:

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

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

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

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

अब, संकेत।

अंदाज

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

बेशक यह नहीं था, क्योंकि यह ऐसा नहीं होना चाहिए।

• शैली उबाऊ है ।

• निम्नलिखित शैली उबाऊ है ।

• कोडिंग स्टाइल डॉक्यूमेंट लिखना उबाऊ है ( और लानत मुश्किल है ; इसे तब तक करने की कोशिश भी न करें, जब तक कि आपने भाषा के साथ दस साल से ज्यादा काम न कर लिया हो)।

• पठन शैली दस्तावेज़ उबाऊ है ।

• स्टाइल गलतियों के लिए कोड की समीक्षा करना उबाऊ है ।

• Trolling कि मेरी शैली बेहतर है की तुलना में तुम्हारा है रोमांचक है, खासकर जब वहाँ दूसरे पर एक शैली के बिल्कुल कोई उद्देश्य लाभ। गंभीरता से, हर समझदार व्यक्ति जानता है कि लिखने if (x)का सही तरीका वह है जिसे मैंने लिखा था, if(x)या नहीं if ( x )!

इसलिए:

• शैली की समीक्षा न करें। यह स्टाइल चेकर्स का काम है। उन प्यारे एप्लिकेशन का आपके मस्तिष्क पर कुछ लाभ होता है: वे पूरे प्रोजेक्ट को मिलीसेकेंड के मामले में जांचते हैं, घंटों या दिनों में नहीं, और वे गलतियां नहीं करते हैं और शैली की त्रुटियों को याद नहीं करते हैं।

• अपनी खुद की शैली मानक न लिखें। आप इसे वैसे भी गलत करेंगे, और आपके सहकर्मी आपको ट्रोल करेंगे कि आपने बुरा विकल्प बनाया है।

• डेवलपर्स को 2 000 स्टाइल त्रुटियों को ठीक करने के लिए मजबूर न करें।

• शैली को स्वचालित रूप से लागू करें। कोड जिसमें शैली की गलतियाँ हैं, संस्करण नियंत्रण में कोई स्थान नहीं है।

• प्रोजेक्ट की शुरुआत से ही करें। एक अस्तित्व परियोजना में शैली नियंत्रण स्थापित करना असंभव से कठिन है।

उस पर अधिक के लिए, SE.SE पर इस अन्य उत्तर के पहले भाग को पढ़ें ।

इसके अलावा:

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

कोड समीक्षा

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

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

• निजी में कोड की समीक्षा करें, खासकर जब डेवलपर कनिष्ठ है और वास्तव में बुरा कोड लिखता है।

• यह दिखाएं कि कुछ भी व्यक्तिगत नहीं है: आप कोड की समीक्षा कर रहे हैं, व्यक्ति के कौशल की नहीं।

• कोड समीक्षा का वास्तविक लक्ष्य दिखाएं। लक्ष्य यह दिखाना नहीं है कि एक डेवलपर कितना बुरा है। लक्ष्य सुधार के अवसर प्रदान करना है।

• कभी बहस नहीं करते। आप यहाँ समझाने के लिए नहीं, बल्कि अपनी विशेषज्ञता प्रदान करने के लिए हैं।

• कभी न मानें कि समीक्षक केवल वही है जो समीक्षा से कुछ सीख सकता है। आप यहाँ भी हैं, कोड को पढ़कर और उन हिस्सों के बारे में स्पष्टीकरण पूछकर, जिन्हें आप नहीं समझते हैं।

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

ध्यान दें कि स्वतंत्र रूप से कंपनी में आपकी विशेष भूमिका और दूसरों की तुलना में आपकी विशेषज्ञता, आपके कोड के साथ-साथ समीक्षा के अधीन भी होनी चाहिए। आपको दूसरों के कोड की समीक्षा करने वाला केवल एक ही नहीं होना चाहिए।

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

प्रशिक्षण

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

यदि आप अपने सहकर्मियों को प्रशिक्षित करने में सक्षम हैं, तो ऐसा करें। यदि प्रशिक्षण के विचार में आपका प्रबंधन शत्रुतापूर्ण है, तो इसे अनौपचारिक रूप से करें। मैंने इस तरह के प्रशिक्षण सत्र अनौपचारिक बैठकों के रूप में, या कभी-कभी एक साधारण चर्चा के रूप में भी किए हैं, कभी-कभी प्रबंधन द्वारा बाधित किया जाता है और बाद में पीछा किया जाता है।

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

संदर्भ पर ध्यान दें, व्यक्तियों पर नहीं

मैं इस स्थिति को केवल 'खराब कंपनी संस्कृति', 'अनुभवहीन स्नातक' आदि पर ध्यान दिए बिना कैसे संबोधित कर सकता हूं।

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

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

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

अपने मेट्रिक्स को सही करें

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

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

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

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

उदाहरण के लिए, आइए विचार करें कि टीम के सदस्य कक्षाओं, कक्षा के सदस्यों और चर के नामों में बहुत अधिक वर्तनी की गलतियाँ करते हैं। यह कष्टप्रद है। आप इसे कैसे माप सकते हैं? एक पार्सर के साथ, आप कोड से सभी शब्दों को निकाल सकते हैं, और एक वर्तनी परीक्षक का उपयोग करके, गलतियों और टाइपो वाले शब्दों का अनुपात निर्धारित करते हैं, 16.7% कहते हैं।

आपका अगला कदम लक्ष्य अनुपात पर अपनी टीम से सहमत होना है। यह अगले स्प्रिंट के लिए 15%, अगले एक के लिए 10%, छह सप्ताह में 5% और दो महीनों में 0% हो सकता है। उन मैट्रिक्स को हर प्रतिबद्ध पर स्वचालित रूप से फिर से जोड़ा जाता है, और कार्यालय में एक बड़ी स्क्रीन पर प्रदर्शित किया जाता है।

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

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

निष्कर्ष

मेरा मानना ​​है कि आपके प्रश्न में वर्णित प्रत्येक पहलू को उन तकनीकों के माध्यम से हल किया जा सकता है जिन्हें मैंने अपने उत्तर में शामिल किया है:

• जब अन्य डेवलपर्स परियोजना में शामिल हुए, मैंने देखा कि वे एक अलग कोडिंग शैली का उपयोग करते हैं (कभी-कभी एक पूरी तरह से अलग शैली)

  आपको स्‍टाइल को स्‍वत: लागू करना था ।

• और अक्सर संपत्ति अभिगमकर्ताओं की तरह आधुनिक भाषा सुविधाओं का उपयोग नहीं करते हैं (यह उद्देश्य-सी में अपेक्षाकृत नया है)।

  दोनों कोड समीक्षाएं और प्रशिक्षण भाषा के आपके ज्ञान को स्थानांतरित करने के लिए यहां हैं।

• कभी-कभी वे फ्रेमवर्क की समान विशेषताओं का उपयोग करने के बजाय अपनी साइकिल का आविष्कार करेंगे

  दोनों कोड समीक्षाएं और प्रशिक्षण यहां आपके ढांचे के ज्ञान को स्थानांतरित करने के लिए हैं।

• या अन्य प्रोग्रामिंग भाषाओं या पेटेंट से अवधारणाओं को स्थानांतरित करना जो उन्होंने हमारे कोड बेस में सीखे।

  यह एक उत्कृष्ट बात है। आपके लिए उनसे सीखने का अवसर जैसा लगता है।

• खराब अंग्रेजी के कारण अक्सर वे तरीकों या चर का नाम ठीक से नहीं ले पाते हैं

  कोड समीक्षाओं को उचित नामकरण पर भी ध्यान देना चाहिए। कुछ IDE में वर्तनी परीक्षक भी होते हैं।

• कभी-कभी मुझे लगता है कि अगर यह आईडीई के लिए नहीं था, तो मुझे लगता है कि वे सभी कोड को बिना किसी इंडेंटेशन या फॉर्मेटिंग के लिखेंगे।

  बेशक वे करेंगे। शैली उबाऊ है और इसे स्वचालित होना चाहिए।

• असल में, मुझे उनके लिखे कोड से नफरत है।

  कोड समीक्षा भाग से याद रखें: “लक्ष्य यह दिखाना नहीं है कि एक डेवलपर कितना बुरा है। लक्ष्य सुधार के अवसर प्रदान करना है। ”

• यह बुरी तरह से स्वरूपित / संगठित है, और कभी-कभी परियोजना के बाकी हिस्सों से मौलिक रूप से भिन्न होता है।

  स्वचालित शैली की जाँच।

• मुझे बहुत तकलीफ होती है जब वे अपनी स्पेगेटी को मेरी कला के टुकड़े में शामिल करते हैं

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

• यह अधिक से अधिक महसूस करता है कि उन्हें सीखने या परवाह नहीं करने के लिए परेशान नहीं किया जा सकता है: वे बस वही करते हैं जो उनसे आवश्यक है और घर जाते हैं।

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

Comments

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

— टॉफ्रो 11

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

— आर्सेनी मूरज़ेंको

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

— आर्सेनी मूरज़ेंको

मैं मानता हूं कि जब टीम को सीआर के साथ जाने के लिए एक सामान्य रुचि है, तो आपको प्रबंधन के समर्थन की आवश्यकता नहीं है - जाहिर है, यह यहां मामला नहीं है, हालांकि।

— टॉफ्रो

Answer 3

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

कोडिंग मानक तय कर सकते हैं कि क्या रिक्त स्थान या टैब का उपयोग करना है, किस डिजाइन पैटर्न का उपयोग करना है और क्या नामकरण परंपराओं का उपयोग करना है, आदि। यह एक लंबा रास्ता तय करेगा भले ही हर कोई कोड अलग-अलग हो।

Answer 4

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

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

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

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

Answer 5

लक्षण जो आप दृढ़ता से वर्णन करते हैं, टीम सामंजस्य की कमी का सुझाव देते हैं ।

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

लक्षण:

• "वे बस वही करते हैं जो आवश्यक है और घर जाते हैं": ध्वनि वे ध्वस्त हैं। जब वे पहुंचे तो क्या वे अधिक उत्साही नहीं थे?
• "वे" "हम" / "मुझे" / "मैं" के खिलाफ: आपसी विश्वास की कमी?
• "मैंने कुछ सुझाव दिए: मैंने पीआर पर जीआईटी टिप्पणी की": लिखित आलोचना के स्वर को कभी-कभी रचनात्मक इरादे के बावजूद आक्रामक या अभिमानी समझा जाता है। आमने-सामने की चर्चा क्यों नहीं?

आप एक छोटी टीम हैं: इस लाभ का उपयोग करें! शुरू करने के लिए कुछ विचार:

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

आज का विचार:

यदि आप तेजी से जाना चाहते हैं, तो अकेले जाएं। अगर आप दूर तक जाना चाहते हैं, तो साथ जाएं

Answer 6

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

दूसरा भाग सबसे सरल है। आप एक ऐसी कंपनी को छोड़ते हैं और पाते हैं जो आपके द्वारा काम किए गए समान मूल्यों को साझा करती है। पहला ... लोगों के कारण इतना सरल नहीं है।

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

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

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

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

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

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

आइए एक पल के लिए परिप्रेक्ष्य बदलें।

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

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

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

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

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

और इसे छोटे चरणों में करें।

यदि आप एक बार में बहुत अधिक परिवर्तन लाते हैं तो लोग हतोत्साहित महसूस करेंगे और हार मान लेंगे। बदलाव में समय लगता है। अपनी कंपनी बदलें या अपनी कंपनी बदलें। सौभाग्य!