बुनियादी नियमों का पालन करने के लिए प्रोग्रामर को कैसे राजी करना है

Question

कई नियम हैं जो मुझे प्रोग्रामर को बहुत बार पालन करने के लिए कहते रहना चाहिए। वे कोड लिखते हैं और, अगर यह काम करता है, तो नौकरी सिर्फ उनके लिए की जाती है। सबसे बुनियादी नियम हो सकते हैं:

• परिवर्तन का संचार
• दृश्य या नियंत्रकों में मॉडल मुद्दे नहीं लिखना
• हार्डकोडिंग से बचें

क्या आप मुझे अपने अनुभव के बारे में बता सकते हैं? आप इसे कैसे प्रबंधित करते हैं?

Comments

आपको programmers.stackexchange.com पर पूछना चाहिए। क्या आप कोड की समीक्षा करते हैं? क्या आपके पास क्रूसिबल की तरह एक कोड समीक्षा उपकरण है? मैं पूरी तरह से कोड समीक्षा करने की सलाह दूंगा और किसी भी अन्य कार्य को करने से पहले सभी मुद्दों को हल करने पर जोर दूंगा ।

आप उनके बिस्तर पर घोड़े के सिर को छोड़ने की कोशिश कर सकते हैं जो गॉडफादर में काम करते थे।

— गौरव

मुझे उच्च वोल्टेज के साथ बड़ी सफलता मिली है। आपकी माइलेज भिन्न हो सकती है।

— टिम पोस्ट

@ टिम: एक लुढ़का हुआ अखबार अधिक पर्यावरण के अनुकूल है

— स्टीवन ए। लोव

@ सच, ​​मुझे लगता है कि यह होगा। सबसे पहले आप अखबार को फिर से प्रयोजन करते हैं, फिर उसे पुन: चक्रित करते हैं। मुझे लगता है कि डराने-धमकाने की कला है।

— टिम पोस्ट

Answer 1

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

शिकायतों की आपकी सूची एक कंपनी के लक्षण हैं जो केवल अल्पकालिक उद्देश्यों को पूरा करने का पुरस्कार देती है और उच्च गुणवत्ता पर जोर देने की कोई इच्छा नहीं है। क्या आप पांच सितारा होटल या ट्रक स्टॉप चला रहे हैं?

Comments

यह इंगित करने के लिए +1 एक सांस्कृतिक मुद्दा है और इसे एक प्रेरणा के दृष्टिकोण से संबोधित करने की आवश्यकता है।

— एलेक्स Feinman

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

— रॉबर्ट ब्रिस्टो-जॉनसन

@ रोबर्टब्रिस्टो-जॉनसन - अच्छी बात है।

— 21

Answer 2

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

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

इसलिए टीम को एक साथ लें और अपने मूल नियमों की एक आम परिभाषा पर काम करना शुरू करें!

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

जब भी टीम को लगता है कि इन दिशानिर्देशों को बदल दिया जाना चाहिए, कुछ ऐसा है जिसे जोड़ा या स्पष्ट किया जाना चाहिए।

Comments

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

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

Answer 3

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

यह एक जादू स्विच नहीं है जिसे आप चालू कर सकते हैं; यह एक धीमी प्रक्रिया होगी और कभी भी 100% नहीं होगी। वैसे भी मेरा अनुभव यही रहा है।

Comments

इस बात से सहमत। यह एक राजनीतिक मुद्दा है, न कि तकनीकी।

और किसी भी कोड मानकों को समूह द्वारा कम से कम आंशिक रूप से सहमत होना होगा। स्टाइलकॉप जैसे उपकरण काफी हद तक मदद करते हैं।

— जॉब

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

— 17

@ 0101 बहुत सही। शक्ति संदेश को आगे बढ़ाने में मदद करती है। संदेश को तैयार करना होगा ताकि इसे स्वीकार किया जा सके।

— RationalGeek

Answer 4

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

यहाँ मेरी कुछ रणनीति है:

कमिटिंग परिवर्तन:

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

अधिकांश डेवलपर्स जिन्हें मैं जानता हूं कि कोड IF में जांच करने से ज्यादा खुशी है:

• प्रक्रिया में जाँच आसान है
• सिंक्रनाइज़ेशन प्रक्रिया आसान है (अन्य डेवलपर्स से परिवर्तन में फैक्टरिंग)
• परिवर्तनों को देखना और संस्करणों के बीच बढ़ना आसान है

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

डेवलपर्स को सीएम दर्द को खत्म करने के प्रभारी होने के कारण आम तौर पर उस में चेकिन की मात्रा बढ़ जाती है।

वास्तुकला का पालन करना - दृश्य और नियंत्रकों में मॉडल मुद्दों को लिखना नहीं

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

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

हार्डकोडिंग से बचें

मैं स्पष्ट कोडिंग मानकों के साथ शुरू करूंगा और सहकर्मी समीक्षाओं में एक कोडिंग मानक समीक्षा को एकीकृत करूंगा। हार्ड कोडिंग उन चीजों में से एक है जो आसानी से सहकर्मी समीक्षा एजेंडा पर एक चेकबॉक्स हो सकता है।

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

सामान्य रूप में

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

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

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

Comments

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

— jmort253

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

— २०:०५ पर betlakshmi

Answer 5

को़ड समीक्षा। केवल वही लिखित कोड स्वीकार करें जिसमें कोई त्रुटि न हो।

Comments

यह अंतर्निहित समस्या का समाधान नहीं है। कोड समीक्षाओं के साथ समय बर्बाद न करें, जब आप इसके बजाय मूल-कारण समस्या को ठीक कर सकते हैं।

— मार्टिन विकमैन 15

यदि आप उन्हें बार-बार सामान को फिर से काम करने के लिए मजबूर कर सकते हैं, तो उनका अंतर्निहित आलस्य उन्हें समय के साथ शुरू करने के लिए मिलेगा।

— डेविड थॉर्नले

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

— jmort253

Answer 6

कम से कम :

• कोडलाइन का पालन करना उनके लिए आसान बनाएं (टूल जैसे कि रीशर, स्टाइलकॉप) यदि यह आसान है तो उन्हें अपनाने की अधिक संभावना है।

इसके अलावा चुनें कि आपके संगठन, डेवलपर्स और टीम के भीतर आपकी भूमिका के आधार पर क्या काम करता है।

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

Answer 7

मेरी भूमिका प्रबंधक की है, लेकिन एक छोटी टीम के रूप में मैं विकास करता हूं और मैं एक कोच के रूप में प्रबंधन करना पसंद करता हूं।

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

मैं उन सभी साधनों पर एक नज़र डालूँगा और आप मुझे बताने वाले किसी अन्य के लिए खुले रहेंगे।

Comments

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

— 22

मेरा प्रश्न यह है कि मेरे पास जो कुछ है, उसे सुधारने के बारे में, जो खोज और प्रतिस्थापन की तुलना में अधिक कठिन, लेकिन प्रभावी है

— लिल्टेस सुगरा

उन लोगों को फायर करना जो कोडिंग नियमों का पालन नहीं करेंगे, अच्छी संपत्ति नहीं खो रहे हैं, यह डेडवुड से छुटकारा पा रहा है।

— HLGEM

@HLGEM - जब तक नियमों का पालन नहीं करने वाला व्यक्ति कोड निंजा होता है जो संगठन की किसी भी समस्या का समाधान कर सकता है। डॉ। हाउस नियमों का पालन नहीं करता है, लेकिन अगर अस्पताल ने उसे निकाल दिया, तो बहुत से काल्पनिक लोग मर जाएंगे। en.wikipedia.org/wiki/Gregory_House

— jmort253

Answer 8

इस मुद्दे को संबोधित करने के 3 तरीके हैं:

1. कोडिंग कन्वेंशन के साथ मुद्दों की जांच करने के लिए स्रोत कोड का स्थैतिक विश्लेषण। Cppcheck और व्याकरण से उन जैसे उपकरणों का उपयोग करें । विकिपीडिया की एक अच्छी सूची है: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis । आमतौर पर अधिकांश स्रोत नियंत्रण प्रणालियों में हुक होते हैं जिसके द्वारा आप चेक-इन के दौरान सीधे ऐसे मुद्दों की जांच कर सकते हैं। : सीवीएस के लिए हुक के लिए इस लिंक पर गौर http://goo.gl/F1gd2 । पालन ​​करने में विफलता का मतलब है एक विफल चेक-इन, और 3 से अधिक विफलताओं का मतलब है कि डेवलपर को खुद को / टीम को समझाना है।

2. कोडिंग प्रक्रिया के दौरान ही डेवलपर को ध्वजांकित करता है। अपनी पसंद की IDE के साथ एकीकृत होने वाली कस्टम स्क्रिप्ट ऐसा करने का एक अच्छा तरीका है। इस लिंक को देखें: http://goo.gl/MM6c4

3. चुस्त प्रक्रियाओं का पालन करें और सुनिश्चित करें कि कोड समीक्षा स्प्रिंट का हिस्सा है

Comments

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

— टिम पोस्ट

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

— रॉबर्ट हार्वे

Answer 9

यहाँ मेरी 3-चरणीय योजना है:

1. प्रोग्रामरों को आग लगाओ
2. कुछ सॉफ्टवेयर इंजीनियरों को किराए पर लें
3. ...
4. फायदा!

: डी

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

Answer 10

1. उन्हें इंगित करें, जब वे बुनियादी नियमों का उल्लंघन करते हैं।
2. उनके लिए उन बगों का उत्पादन करने की प्रतीक्षा करें जिन्हें वे केवल ट्रैक नहीं कर सकते हैं या फीचर अनुरोध के साथ सामना नहीं कर सकते हैं जो वे अपने अनम्य कोड के कारण लागू नहीं कर सकते हैं।
3. उन्हें याद दिलाएं जो आपने पहले कहा था।
4. उन्हें थोड़ी देर के लिए अपने आप में डूबने दो।
5. प्रश्न में कोड को रीफ़ैक्टर करने के लिए समय निकालें, बग को अलग करें / नई कार्यक्षमता में प्लग करने के लिए infrasturcutre प्रदान करें। आपने जो किया, उसे समझाने के लिए कुछ समय लें।

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

आम तौर पर, कुछ मानकों को अनुकूलित करने की अनिच्छा का मतलब टीम के काम में अनुभव की कमी है।

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

Comments

मुझे यह पसंद है। किसी से नफरत करने के लिए बढ़िया नुस्खा ;)

— रोमन ज़ेनका

@ रोमान ज़ेन्का: संभवतः, हाँ। लेकिन अगर पसंद नफरत और निराश होने के बीच है, क्योंकि आप टीम पर एक NNPP कर रहे हैं, तो मैं पहला विकल्प;)

— back2dos

इस बिंदु पर, उन्हें पेरोल को बंद करने की आवश्यकता है।

— 21

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

— सुग्रीव

Answer 11

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

Answer 12

एक पेशेवर सॉफ्टवेयर इंजीनियर किराया। और फिर सबसे कमजोर आग। फिर धीरे-धीरे उन लोगों को बदलें जो गोद नहीं ले सकते। ऐसे लोग होने से कभी-कभी दीर्घकालिक रूप से लाभ की तुलना में अधिक नुकसान होता है।

यहां मुख्य विचार यह है कि पेशेवर ज्यादातर काम करना शुरू कर देंगे, और दूसरों को फायर करना मूल्यवान मानव संसाधन को कम नहीं करेगा।

Comments

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

— jmort253

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

— कॉन्स्टेंटिन पेट्रूख्नोव

Answer 13

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

Answer 14

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

या सबसे खराब अपराधी को आग दें और बाकी को इसे बाहर पसीना दें।

Comments

Eeep! आपके पास VCS का एकमात्र-चेकआउट प्रकार है? सदी के साथ जाओ, यार!

— डेविड थॉर्नले

Answer 15

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

Answer 16

यदि इस चालक दल को वास्तव में बदलावों की जाँच करने में परेशानी हो रही है, चिंताओं को अलग करने का पालन करना और जादू-टोना नहीं करना है तो मैं पूरे चालक दल को आग लगा दूंगा और उन्हें असली प्रोग्रामर ^{1 से} बदल दूंगा जो वास्तव में जितनी जल्दी हो सके अपने शिल्प की परवाह करता है। एक समय में है कि एक हो या सामूहिक रूप से मैं यह नहीं कर सकता है, लेकिन इन जोकर जाना मिल गई है।

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

---

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

Comments

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

— jmort253

Answer 17

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

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

यदि नीति कोड नहीं आने से संबंधित है, तो यह लिखित चेतावनी के लिए कहता है यदि वे ऐसा करने के लिए नहीं कहते हैं तो वे ऐसा नहीं कर सकते हैं। यदि वे कोड नहीं कर रहे हैं, तो जहां तक ​​आप चिंतित हैं, उन्होंने कोई भी लिखा नहीं है।

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