क्या आपके विकास टीम के सदस्यों को "अच्छा" कोड लिखने और उनके कोड में टिप्पणियां जोड़ने के लिए प्रोत्साहित करने के लिए आपके पास कोई तरीका/सिस्टम है? मैं मानता हूं कि "अच्छा" एक व्यक्तिपरक शब्द है और यह measuring the maintainability of code के बारे में पहले के प्रश्न से संबंधित है जो अच्छे कोड के एक माप के रूप में है।आप अच्छे कोड को कैसे प्रोत्साहित करते हैं?
जबकि अधिकांश लोग जवाब देते हैं कि कोड समीक्षा उच्च गुणवत्ता वाले कोड को सुनिश्चित करने का एक अच्छा तरीका है, और सही तरीके से, वे मुझे वहां जाने के लिए प्रत्यक्ष प्रोत्साहन नहीं लगते हैं। हालांकि, अच्छे कोड के लिए सकारात्मक प्रोत्साहन के साथ आना मुश्किल है क्योंकि अच्छे कोड की अवधारणा में बड़े क्षेत्र हैं जो राय के दायरे में पड़ते हैं और लगभग किसी भी प्रणाली को गढ़ा जा सकता है।
मेरे पास जो भी नौकरियां थीं, अच्छे डेवलपर्स आंतरिक कोड को अच्छे कोड लिखने के लिए प्रेरित थे। चिकन और अंडा, फीडबैक, 22 पकड़ो, इसे आप जो कहते हैं उसे कॉल करें, अच्छे कोड प्राप्त करने का सबसे अच्छा तरीका प्रेरित डेवलपर्स को किराए पर रखना है। एक ऐसा वातावरण बनाना जहां अच्छे डेवलपर्स काम करना चाहते हैं, शायद सबसे अच्छा प्रोत्साहन है जिसे मैं सोच सकता हूं। मुझे यकीन नहीं है कि कौन सा कठिन है, पर्यावरण बना रहा है या डेवलपर्स को ढूंढ रहा है। न तो आसान है, लेकिन दोनों लंबी अवधि में इसके लायक हैं।
मुझे पता चला है कि एक ऐसा वातावरण बनाने का एक हिस्सा जहां अच्छे डेवलपर्स काम करना चाहते हैं, ऐसे परिस्थितियों को सुनिश्चित करना जहां डेवलपर्स कोड के बारे में बात करते हैं। मैं एक कुशल प्रोग्रामर नहीं जानता जो उसके कोड की अच्छी आलोचना की सराहना नहीं करता है। यह उन लोगों की सहायता करता है जो सर्वश्रेष्ठ बनना पसंद करते हैं। इस प्रयास के एक छोटे उप-भाग के रूप में, और इस प्रकार अच्छा कोड बनाने के लिए एक अप्रत्यक्ष प्रोत्साहन, मुझे लगता है कि कोड समीक्षा अद्भुत काम करती है। और हां, आपकी कोड गुणवत्ता को कुछ प्रत्यक्ष लाभ भी प्राप्त करना चाहिए।
एक और तकनीक सहकर्मी और मैंने अच्छी कोडिंग आदतों को संवाद करने के लिए उपयोग किया है कोड में समूह समीक्षा है। यह कम औपचारिक था और लोगों को नई तकनीक, उपकरण, विशेषताओं को दिखाने की अनुमति दी गई थी। आलोचकों को बनाया गया था, कुडो को सार्वजनिक रूप से दिया गया था, और अधिकांश डेवलपर्स को एक छोटे डेवलपर समूह के सामने बोलने में कोई दिक्कत नहीं हुई थी, जहां वे सभी को जानते थे। यदि प्रबंधन इस में लाभ नहीं देख सकता है, तो सैमिक के लिए वसंत और इसे ब्राउन बैग कहें। देव भी मुफ्त भोजन पसंद करेंगे।
हमने लोगों को कोड घटनाओं पर जाने के लिए भी प्रयास किया। यह माना जाता है कि इस विषय के साथ आप कितने परिचित हैं, आप शायद ज्यादा नहीं सीख सकते हैं, लेकिन यह लोगों को थोड़ी देर के लिए कोड के बारे में सोचता रहता है और लोगों को एक और अधिक आराम से वातावरण में बात करता है। यदि आप बाद में एक दौर या दो पेय लेने की पेशकश करते हैं तो अधिकांश देव भी दिखाए जाएंगे।
एक सेकंड प्रतीक्षा करें, मैंने एक और विषय देखा। मुफ्त भोजन! गंभीरता से हालांकि, बिंदु एक ऐसा वातावरण बनाना है जहां लोग पहले से ही अच्छे कोड लिखते हैं और जो सीखने के इच्छुक हैं, वे काम करना चाहते हैं।
मुझे लगता है कि औपचारिक कोड समीक्षा इस उद्देश्य को भरती है। मैं थोड़ा और सावधान हूं कि क्रैपी दिखने वाले कोड को न करने के लिए यह जानकर कि मेरी टीम के कम से कम दो अन्य डेवलपर इसकी समीक्षा करने जा रहे हैं।
कोड समीक्षा, अच्छी तरह से किया गया, एक बड़ा अंतर कर सकता है। कोई भी व्यक्ति उस कोड को प्रस्तुत करना चाहता है जो हर किसी की आंखों को खून बहने का कारण बनता है।
दुर्भाग्यवश, समीक्षा हमेशा अच्छी तरह से स्केल नहीं होती है (बहुत सारे कुक और इतने पर) या नीचे (हम कोड की समीक्षा करने के लिए बहुत व्यस्त कोडिंग कर रहे हैं)। शुक्र है, कुछ सुझाव on Stack Overflow हैं।
एचएम।
शायद विकास टीम को एक-दूसरे के कोड कोड-समीक्षा करना चाहिए। इससे उन्हें बेहतर लिखने के लिए प्रोत्साहित किया जा सकता है, टिप्पणी कोड।
जो कि जोड़ी-प्रोग्रामिंग के तहत अच्छी तरह से गिर जाएगा। मैंने कुछ भी हासिल करने के लिए "यहां" जाने की कोशिश की है। – hometoast
यह incentive pay is considered harmful के रूप में कठिन है। मेरा सबसे अच्छा सुझाव है कि कई लक्ष्यों को चुनना होगा जिन्हें सभी को एक साथ पूरा किया जाना चाहिए, जिसका इस्तेमाल शोषण किया जा सकता है।
कोड गुणवत्ता अश्लील साहित्य की तरह हो सकता है - के रूप में न्यायमूर्ति पॉटर स्टीवर्ट से प्रसिद्ध उद्धरण चला जाता है, "मैं यह पता है जब मैं देख रहा हूँ कि यह"
तो एक तरह से कोड गुणवत्ता के बारे में दूसरों को पूछने के लिए है। ऐसा करने के कुछ तरीके हैं ...
समीक्षा सहकर्मियों में से एक मानदंड में से एक होने की समझ के साथ उनके साथियों (और उनके द्वारा अन्य कोड की समीक्षा) द्वारा कोड समीक्षा (व्यक्तिगत रूप से, मुझे नहीं लगता कि जरूरी टिप्पणियों का मतलब है,? कभी कभी कोड उनके बिना पूरी तरह से स्पष्ट)
अनुरोध है कि कोड गुणवत्ता की वजह से मुद्दों (आप, सही पुनरावलोकन पकड़ कर)
ट्रैक कितनी बार करने के लिए अपने कोड पहले से काम करता है परिवर्तन पुनरावलोकन पर उठाया जाता है हो सकता है समय, या क्या यह कई प्रयास करता है?
annuak (या जो कुछ भी) समीक्षा समय पर सहकर्मी समीक्षाओं के लिए पूछें, और एक सवाल शामिल करें कि समीक्षाकर्ता के कोड के साथ प्रश्नों में से एक के रूप में काम करना कितना आसान है।
प्रोत्साहन के साथ बहुत सावधान रहें: "क्या मापा जाता है"। यदि आप कोड की लाइनों को पुरस्कृत करते हैं, तो आपको फूला हुआ कोड मिलता है। यदि आप टिप्पणी करने का इनाम देते हैं, तो आपको अनावश्यक टिप्पणियां मिलती हैं। यदि आप कोड में पाए गए बगों की कमी का इनाम देते हैं, तो आपके डेवलपर अपना स्वयं का क्यूए काम करेंगे जो कम वेतन वाले क्यूए विशेषज्ञों द्वारा किया जाना चाहिए। प्रक्रिया के कुछ हिस्सों को प्रोत्साहित करने के बजाय, पूरी टीम की सफलता, या पूरी कंपनी के लिए बोनस दें।
आईएमओ, एक अच्छी कोड समीक्षा प्रक्रिया उच्च कोड गुणवत्ता सुनिश्चित करने का सबसे अच्छा तरीका है। अच्छी प्रथाओं को फैलाने के तरीके के रूप में, टीम के आधार पर जोड़ी प्रोग्रामिंग भी काम कर सकती है।
यह सलाह है कि आप अपने मालिक के लिए न हों।
हमेशा इस तथ्य को याद दिलाएं कि यदि आप उस अतिरिक्त मील पर जाते हैं और अब आप जितना अच्छा कोड लिख सकते हैं, तो वह बाद में भुगतान करेगा जब आपने एक सप्ताह तक अपनी सामग्री को दोबारा नहीं किया है।
मुझे लगता है कि अच्छे कोड लिखने के लिए सबसे अच्छा प्रोत्साहन एक साथ अच्छा कोड लिखकर है। अधिक लोग परियोजना के उसी क्षेत्र में कोड लिखते हैं, उतना अधिक संभावना है कि कोड सम्मेलन, अपवाद हैंडलिंग, टिप्पणी, इंडेंटिंग और सामान्य विचार प्रक्रिया एक दूसरे के करीब होगी।
सभी कोड एक समान नहीं होने जा रहे हैं, लेकिन जब लोग शैलियों को चुन सकते हैं और टीम के रूप में सर्वोत्तम अभ्यास के साथ आते हैं तो लोगों को बहुत सारे काम मिलते हैं।
मानदंड सार्वजनिक बनाएं और किसी भी प्रकार के स्वचालन के साथ प्रोत्साहन कनेक्ट न करें। आप जो खोज रहे हैं उसके उदाहरणों को प्रचारित करें। अच्छे बनें और लोगों को अपने स्वयं के बुरे उदाहरणों को प्रचारित करने के लिए प्रोत्साहित करें (और उन्होंने उन्हें कैसे सही किया)।
टीम की संस्कृति का हिस्सा "अच्छा कोड" है; यह कई लोगों के लिए व्यक्तिपरक है, लेकिन एक कार्यकारी टीम के पास एक स्पष्ट उत्तर होना चाहिए कि टीम के हर कोई इस बात पर सहमत हो। कोई भी जो सहमत नहीं है वह टीम को नीचे लाएगा।
मुझे नहीं लगता कि पैसा एक अच्छा विचार है। कारण यह है कि यह एक बाहरी प्रेरक है। लोग नियमों का पालन करना शुरू कर देंगे, क्योंकि ऐसा करने के लिए वित्तीय प्रोत्साहन है, और यह हमेशा काम नहीं करता है। अध्ययनों से पता चला है कि जैसे लोग उम्र के वित्तीय प्रोत्साहन एक प्रेरक से कम हैं। ऐसा कहा जा रहा है कि, इस स्थिति में काम की गुणवत्ता केवल इनाम प्राप्त करने के लिए निर्धारित स्तर के बराबर होगी। यह एक अल्पकालिक जीत कुछ भी नहीं है।
लोगों को सही काम करने के लिए प्रोत्साहित करने का वास्तविक तरीका यह है कि उन्हें मनाने के लिए उनका काम अधिक फायदेमंद हो जाएगा। वे बेहतर होंगे कि वे क्या करते हैं और वे कितने कुशल हैं। लोगों को प्रोत्साहित करने का एकमात्र असली तरीका यह है कि वे इसे करना चाहते हैं।
आखिरी व्यक्ति जिसने तकनीकी समर्थन कॉल के कारण निर्माण या शिप कोड को तोड़ दिया है, तब तक चाय बनाना है जब तक कि कोई और इसे आगे न करे। मुसीबत यह है कि यह व्यक्ति शायद चाय को वास्तविक अच्छा कपपा बनाने के लिए आवश्यक ध्यान नहीं देगा।
आप उन लोगों से छुटकारा पाएं जो अच्छे कोड नहीं लिखते हैं।
मैं पूरी तरह गंभीर हूं।
कोई भी जो एक बड़ी समस्या हल करने वाला है, शायद सबसे अच्छा कोड नहीं लिख सकता है। यही कारण है कि कोड समीक्षा, सहकर्मी समीक्षा, अकादमी पाठ्यक्रम, आदि हमारे उद्योग के लिए महत्वपूर्ण हैं। एक बड़ी समस्या सॉल्वर को कोड लिखना सिखाया जा सकता है ... एक महान कोड लेखक को सिखाया नहीं जा सकता कि कैसे समस्या हल हो सकती है। – MaTT
@ एमएटीटी - अच्छी तरह से कहा। –
यह जूनियर स्तर के डेवलपर के लिए ठीक हो सकता है। लेकिन एक बड़ी समस्या-सॉल्वर जो खराब कोड लिखता है वह एक कार्यकर्ता मधुमक्खी से अधिक खतरनाक हो सकता है जो अच्छा कोड लिखता है। यदि कोई जूनियर स्तर के डेवलपर से अधिक होने जा रहा है, तो उसे एक बड़ी समस्या हल करने वाला होना चाहिए और अच्छा कोड लिखना चाहिए। – core
मैं आमतौर पर अपनी टीम मौद्रिक पुरस्कार नहीं देता, क्योंकि वे अधिक नहीं करते हैं और हम वास्तव में उन्हें बर्दाश्त नहीं कर सकते हैं, लेकिन मैं आमतौर पर प्रत्येक टीम के सदस्य के साथ बैठता हूं और व्यक्तिगत रूप से उनके साथ कोड पर जाता हूं क्या काम करता है ("अच्छा" कोड) और क्या नहीं ("खराब" कोड)। ऐसा लगता है कि यह बहुत अच्छी तरह से काम करता है, क्योंकि मुझे इस प्रक्रिया को शुरू करने से पहले लगभग उतना ही जंक कोड नहीं मिला है।
मैं बिल द लिज़र से सहमत हूं। लेकिन मैं इस बात को जोड़ना चाहता था कि बिल को क्या कहना है ...
कुछ ऐसा किया जा सकता है (संसाधनों को मानते हुए) कुछ अन्य डेवलपर्स (शायद 1 जो आपके काम के बारे में कुछ जानता है, 1 जो जानता है) आपका काम गहराई से, और शायद 1 जो इसके बारे में बहुत कम जानता है) एक साथ और आप उन्हें अपने कोड के माध्यम से चलते हैं। आप एक प्रोजेक्टर का उपयोग कर सकते हैं और उन्हें कमरे में बैठ सकते हैं और आप अपने सभी परिवर्तनों के माध्यम से ड्राइव कर सकते हैं। इस तरह, आपके पास एक मिश्रित भीड़ है जो इनपुट प्रदान कर सकती है, प्रश्न पूछ सकती है, और सब से ऊपर आपको एक बेहतर डेवलपर बना सकता है।
केवल नकारात्मक प्रतिक्रिया होने की आवश्यकता नहीं है; हालांकि, यह कई बार होगा। प्रतिक्रियात्मक के रूप में नकारात्मक लेना महत्वपूर्ण है, और शायद प्रतिक्रिया देने पर रचनात्मक तरीके से अपनी प्रतिक्रिया को सोखने का प्रयास करें।
यहां विचार यह है कि, यदि आपके पास अपने कार्यों के लिए टिप्पणी ब्लॉक हैं, या एक टिप्पणी ब्लॉक जो कुछ मुश्किल गणित परिचालनों को बताता है, या एक साधारण टिप्पणी वाली रेखा बताती है जो बताती है कि आपको भाषा के आधार पर दिनांक प्रारूप क्यों बदलना है चयनित ... तो आपको समूह कोड को निर्देशित करने की आवश्यकता नहीं होगी कि आपका कोड क्या कर रहा है। यह आपके द्वारा किए गए परिवर्तनों को एनोटेट करने का एक तरीका है और यह अन्य डेवलपर्स को आपके पिछले फ़ंक्शन में आपके द्वारा किए गए अस्पष्ट तर्क के बारे में सोचने की अनुमति देता है क्योंकि वे आपकी टिप्पणियां पढ़ सकते हैं और देख सकते हैं कि आपने और क्या किया।
यह सब वास्तविक जीवन अनुभव से आ रहा है और हम अपने काम पर इस दृष्टिकोण का उपयोग जारी रखते हैं।
आशा है कि इससे मदद मिलेगी, अच्छा सवाल!
मैं असहमत हूं। आप जो वर्णन करते हैं उसे नकारात्मक सुदृढ़ीकरण कहा जाता है। अल्प अवधि में प्रभावी, लेकिन एक टीम के निर्माण के लिए अच्छा नहीं है। एक तनावपूर्ण काम के माहौल का कारण बनता है। – kemiller2002
@ केविन: मुझे लगता है कि आपने "अच्छा किया" योग्यता प्राप्त किया है। ;-) –