कोडिंग मानकों को 'दिमाग की धड़कन' अवधि और नए कर्मचारियों के प्रयास को कम करना

Question

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

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

मैं टीम के मानकों को कोड करने के लिए नए कर्मचारियों को प्राप्त करने के लिए समय और प्रयास को कम करने के सुझावों की तलाश में हूं।

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

हमने 'सुधार' की एक घर में विकी बनाए रखने की कोशिश की है, लेकिन यह निराशाजनक रूप से विफल रहा है। प्रवर्तन की कमी और यह भी कि 'किसी को अपनी गलतियों को सही करने' के बजाय 'गलतियों को पढ़ना और कोशिश करना और रोकना' आसान है।

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

बहुत धन्यवाद।

संपादित करें: सभी उत्तरों के लिए धन्यवाद। सुनिश्चित नहीं है कि इस प्रश्न के लिए सही उत्तर है, लेकिन मैं निश्चित रूप से उस चिह्न को चिह्नित करने जा रहा हूं जिसे मैं निश्चित रूप से कोशिश कर रहा हूं।

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

यदि आप अपने कोडिंग मानकों के बारे में सख्त हैं और आप यह सब काम मैन्युअल रूप से कर रहे हैं तो आप कई स्वचालित उपकरणों को नियोजित करके समय को महत्वपूर्ण रूप से बचा सकते हैं। वे आपके वरिष्ठ डेवलपर्स का लाइव इतना आसान बना देंगे (मुझे लगता है कि आप इसका उपयोग करते हैं।नेट के रूप में आप FxCop) का उल्लेख:

1. ग्राहक पक्ष पर - आप टेम्पलेट्स कार्यक्षमता के साथ ReSharper R# जैसी चीजों का इस्तेमाल कर सकते लगता है कि कोड अपने दिशा-निर्देशों
2. सर्वर साइड पर के साथ पालन करने के लिए - आप सेटअप एक करने की जरूरत है निरंतर एकीकरण प्रणाली और FxCop जैसे उपकरणों को एकीकृत करें। हम FxCop का उपयोग करते हैं और पीबीए नामक हमारी कंपनी से उत्पाद के साथ इसकी तारीफ करते हैं जो समान कार्यक्षमता की अनुमति देता है।

Answer 4

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

एक बार मेरी एल्गोरिथ्म शिक्षक ने देखा कि कोई उस पर एक टी-शर्ट लेखन पहनता है: "कोई बग, अच्छा प्रोग्रामर! " फिर उसने कहा, "मुझे ऐसा नहीं लगता। आपके पास एक अच्छा प्रोग्रामर होने के लिए बग होना चाहिए।" यह एक दिलचस्प बिंदु था।

तो, आप लेखन कीड़े क्यों नहीं सिखाते? मैं लोगों को एक अच्छा प्रोग्रामर बनाने के लिए एक विपरीत तरीका का उपयोग करने के बारे में बात कर रहा हूं।

Answer 5

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

Answer 6

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

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