मेरी रस्सी के अंत में [बंद]


17

मैं एक बड़ी कंपनी का ठेकेदार हूं। वर्तमान में, परियोजना पर तीन डेवलपर्स हैं, खुद को शामिल किया गया है।

समस्या यह है कि अन्य 2 डेवलपर्स वास्तव में नहीं मिलते हैं। "यह" से मेरा मतलब निम्नलिखित है:

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

मुझे लगता है कि मैं अपने आप को और अधिक कुंठित पा रहा हूं क्योंकि मैं दूसरों के कोड को प्रारूपित करता हूं, बग को ठीक करता हूं, कार्यक्षमता की खोज करता हूं जो टूट गया है, और स्पेगेटी को हटाने के लिए अमूर्त बनाता है।

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

क्या यह हमारे प्रबंधक से यह पूछने के लिए लाइन से बाहर होगा कि दूसरों को एसवीएन का उपयोग करने की समीक्षा करें; कमिट केवल किसी ऐसे व्यक्ति द्वारा समीक्षा के बाद किया जा सकता है जो हमारे द्वारा किए जा रहे ज्ञान का जानकार है? एक ठेकेदार के रूप में, मुझे यकीन नहीं है कि यह सबसे अच्छा कदम है।

क्या यह स्पष्ट करने का कोई सूक्ष्म / सूक्ष्म तरीका नहीं है कि मैं कितनी चीजों को ठीक कर रहा हूं?


1
मैंने इस के जवाब में एक सवाल खोला, जो मुझे लगता है कि आपकी टीम को होने वाली वास्तविक समस्या को सामान्य करता है: प्रोग्रामर.स्टैकएक्सचेंज . com/questions/ 127117/… । जहाँ तक स्वचालित परीक्षणों को शुरू करने की बात है, मैं मार्टिन ब्लोर की पोस्ट से बहुत हद तक सहमत हूँ: martinblore.wordpress.com/2010/06/02/… - अच्छे सिद्धांतों और नींव के बिना, TDD का प्रयास बहुत व्यर्थ होने वाला है। मैंने अपनी पोस्ट में उस नींव को शून्य करने की कोशिश की क्योंकि मैं भी उत्सुक हूं।
DXM

मेरे पास समस्या यह है कि परीक्षण केवल कार्यशीलता को सत्यापित करते हैं। वे मेरे द्वारा सूचीबद्ध अन्य 7 वस्तुओं को संबोधित नहीं करते हैं।
14

1
क्या आपने इन लोगों के साथ जोड़ी प्रोग्रामिंग की कोशिश की है? वे आपकी बात देखेंगे और यदि आप एक मशीन पर बैठते हैं और एक एकल कार्यक्षमता विकसित करते हैं, तो आप उन्हें देखेंगे। यह एक महीने के लिए करें, सप्ताह में 3 दिन, दिन में 3 बजे। यह मदद कर सकता है। इसके अलावा CI स्थापित करें और कोड कवरेज और टेस्ट केस पास दर मैट्रिक्स प्रकाशित करें। यदि कोई भी उल्लंघन किया जाता है, तो बिल्ड को विफल होने दें।

जवाबों:


7

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

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

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

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

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


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

dxm, हाँ यह एक मुद्दा है। मेरे सवाल का मुद्दा यह है कि इस समस्या को प्रबंधन में कैसे लाया जाए, हालांकि मैं मानता हूं कि शायद यह बहुत स्पष्ट नहीं था।
hvgotcodes

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

7

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

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

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

मुझे नहीं पता कि आपकी स्थिति क्या है क्योंकि आपने उल्लेख किया है कि आप केवल 6 महीने के लिए कंपनी के साथ हैं और आप एक ठेकेदार हैं। क्या इस कंपनी के साथ रहने के लिए आपके दीर्घकालिक लक्ष्य हैं या क्या अनुबंध समाप्त होने वाला है? मैं पूछ रहा हूं क्योंकि अगर आप कुछ करते हैं, तो वास्तव में परिणाम देखने में काफी समय लग सकता है।

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

इसलिए यह मानते हुए कि आपकी टीम का सम्मान और ध्यान है। अब क्या?

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

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

  1. एक बार आपके पास प्रबंधन का समर्थन है। आप मुख्य रूप से निर्धारित अभ्यास / प्रक्रिया शुरू कर सकते हैं जो मेनमा ने मेरे सवाल के जवाब में सुझाई थी । हमने उनमें से बहुत कुछ किया है (युग्मित प्रोग्रामिंग को छोड़कर) और आप निश्चित रूप से लाभ देखते हैं। विशेष रूप से स्टाइल, डॉक्यूमेंटेशन को मानकीकृत करने में कोड समीक्षाओं ने मदद की और हमें टीम के बीच साझा ज्ञान / तकनीकों की भी अनुमति दी। हालांकि, कोड समीक्षा तय की गई थी, टीम वास्तव में उन्हें पसंद करती है और हम कार्यक्षमता के प्रत्येक टुकड़े की समीक्षा करते हैं, जिसमें जांच की जाती है। हालांकि ...
  2. आप ध्यान दें कि आमतौर पर लिखा गया कोड अभी भी बहुत युग्मित है, डिजाइन खराब है या पूरी तरह से अभाव है। कोड समीक्षाएं इसमें से कुछ को पकड़ती हैं, लेकिन केवल इतना है कि आप फिर से लिख सकते हैं। पहली जगह में डिजाइन खराब क्यों है? - बहुत सारे डेवलपर्स को कभी भी अच्छी प्रथाओं के लिए पेश नहीं किया गया था और उन्हें औपचारिक रूप से पहली बार OOD नहीं सिखाया गया था। बहुत सारे लोग "बस कोडित" जो भी कार्य उन्हें दिया गया था।
  3. प्रबंधन के समर्थन से आप अधिक प्रक्रिया शुरू कर सकते हैं, जैसे किसी भी कोडिंग से पहले डिजाइन पर चर्चा करना। लेकिन आप केवल एक ही व्यक्ति हैं और ऐसा लगता है कि जैसे ही आप ध्यान नहीं देते हैं टीम वापस लौट जाती है जो उन्होंने हमेशा किया है। क्यों?
  4. क्या बेहतर प्रथाओं या आदतों को पेश किया जा सकता है और सिखाया जा सकता है ताकि आपको लगातार निगरानी न करनी पड़े? - यह हिस्सा इतना आसान नहीं है।
  5. अन्य टीम के सदस्य नई प्रथाओं को सीखने और लेने के लिए अनिच्छुक क्यों हैं और वे SOLID या DRY के लिए इतने प्रतिरोधी क्यों हैं जब इसे आधुनिक सॉफ्टवेयर पद्धति साहित्य में बहुत कुछ लिखा गया है? अपनी टीम में हमारे द्वारा किए गए सभी सकारात्मक परिवर्तनों के साथ, 2 सप्ताह पहले मेरे पास एक तर्क था कि मैं 2 कार्यों को रद्द कर दिया था जिसमें समान 15 लाइनें थीं और समीक्षक ने इसे वीर, अनावश्यक प्रयास कहा क्योंकि केवल कॉपी / पेस्ट के साथ कुछ भी गलत नहीं है 15 लाइनें। मैं इस तरह के विचारों से बहुत असहमत हूं, लेकिन अब हम असहमत होने के लिए सहमत हो गए हैं। -- तो अब क्या? अब हम अपने अन्य पोस्ट के विषय पर पहुँच गए हैं ।
  6. जैसा कि मेपल_शाफ्ट और निक्की ने अपने जवाबों में बताया (क्षमा करें, मेनमा , आपको सबसे अधिक वोट मिले, लेकिन आप :) से 5 कदम पीछे हैं), आप एक ऐसे चरण में पहुंच गए हैं जहां "प्रक्रिया" अब आपकी मदद नहीं कर सकती है और इस मंच पर कोई भी नहीं आपको बता सकता है कि "फिक्स" क्या है। अगला कदम व्यक्तियों से संपर्क करना है, शायद एक-पर-एक, एक टीम के रूप में, शायद एक समय या किसी अन्य पर और उनसे बात करना। उनसे पूछें, क्या काम करता है और क्या नहीं। उनके द्वारा चलाए जा रहे कार्यों के मूल कारणों की पहचान करने का एकमात्र तरीका अब व्यक्तिगत रूप से उनसे बात करना और यह पता लगाना है। इस कदम के हिस्से के रूप में, मैं हाल ही में एक पूरी तरह से अलग टीम समस्या पर आया था, लेकिन मुझे लगता है कि यहां जोएल का जवाब है, जो बहुत विस्तृत और व्यावहारिक है, इस मामले पर भी लागू होगा। संक्षेप में, "शॉर्ट लीश" के रूप में प्रबंधन का उपयोग करते हुए, किसी भी चीज़ के बारे में एक संभव दृष्टिकोण है, हमें यह याद रखना होगा कि हम मनुष्यों के साथ व्यवहार कर रहे हैं ताकि वास्तव में प्रेरणाओं को समझ सकें, हमें शुद्ध प्रबंधन या तकनीकी नेतृत्व की तुलना में मनोविश्लेषण में अधिक पार करना होगा।
  7. तो अब आप अपने साथियों से बात कर रहे हैं? आप उनसे क्या पूछते हैं? मैं इस अगले भाग के बारे में निश्चित नहीं हूँ क्योंकि मैं यहाँ कभी नहीं रहा हूँ। यहाँ एक संभावित परिदृश्य है: Q: कैसे कोई ठोस नहीं आता है? A: मुझे इसकी आवश्यकता नहीं है। क्यू: यह मदद कर सकता है। एक: मैं ठीक है के रूप में है। - किसी तरह आपको ध्वनियों की एक श्रृंखला उत्पन्न करने की आवश्यकता होती है जो आपके मुंह को छोड़ देगी और श्रोता को पहचानने का कारण बनेगी कि चीजें बेहतर हो सकती हैं यदि वे जो भी मौका दे रहे हैं, उसे दें। यदि आप यहां असफल होते हैं, तो उन्हें कभी भी यह विश्वास नहीं होगा कि जो भी "प्रक्रिया" उन्हें वास्तव में कोई मूल्य देती है। दूसरी ओर यदि आप इस बिंदु को पा लेते हैं, तो आप शायद पाएंगे कि आपको "प्रक्रिया" की भी आवश्यकता नहीं है।
  8. बहुत मूल पर IMO, आपके टीम के साथी नहीं सीखेंगे कि उन्हें अपनी मौजूदा आदतों / प्रथाओं में कुछ भी गलत नहीं दिखता है। तो हो सकता है कि इस सब में अगला कदम समस्याओं को उजागर करने, उन्हें स्पष्ट करने और उन्हें स्पष्ट करने का तरीका खोजना हो। आखिरकार, हम SOLID / DRY सिद्धांतों का उपयोग करते हुए या दस्तावेज़ीकरण बनाए रखने के लिए केवल पठनीय कोड नहीं लिख रहे हैं क्योंकि यह हमें एक गर्म और गूढ़ एहसास देता है। हम इसे करते हैं क्योंकि यह बेहतर गुणवत्ता कोड का उत्पादन करता है और स्पष्ट रूप से हमें कोड को तेज बनाता है। क्या इसे मापा जा सकता है? शायद यह वह जगह है जहाँ सॉफ्टवेयर मेट्रिक्स में आते हैं?
  9. यहां एक पागल विचार है और मुझे नहीं पता है कि क्या यह वास्तव में काम करेगा (यह एक मानक उद्योग अभ्यास हो सकता है, या यह शायद पूरी तरह से अमान्य है। मैंने इसे पिछले 24 घंटों में बनाया है), लेकिन मैं इसे लाने के लिए बहुत लुभावना हूं। अगले साल के शुरू होते ही टेबल पर:
    • कई अन्य लोगों की राय के खिलाफ , सभी स्रोत फ़ाइलों के लिए लेखक / स्वामी के विचार का परिचय दें। जैसा कि द प्रोगैमैटिक प्रोग्रामर सुझाव देता है कि यह एकल व्यक्ति को स्वामित्व और जिम्मेदारी की भावना देगा जो स्रोत कोड के एक टुकड़े के लिए जिम्मेदार होगा। इसका मतलब यह नहीं है कि अन्य लोग कोड को संशोधित नहीं कर सकते हैं, हम सभी एक टीम के रूप में काम कर रहे हैं, लेकिन दिन के अंत में, कोड का मालिक व्यक्ति उस बदलाव की समीक्षा करने के लिए जिम्मेदार है।
    • एक स्रोत रिपॉजिटरी ट्रिगर बनाएं जो सभी चेक-इन पर नज़र रखता है और विशेष रूप से उन लोगों के लिए दिखता है जो बग फिक्स हैं। इसे एक प्रक्रिया बनाएं ताकि प्रत्येक बग फिक्स में चेक-इन विवरण में एक संदर्भ पहचानकर्ता ठीक सामने हो। अब एक स्क्रिप्ट लिखें जो बदल गई फ़ाइलों की सूची को पार्स करेगी और फ़ाइल हेडर कमेंट ब्लॉक से "ऑथर" को हटा देगी। एक SQL डेटाबेस बनाएँ जो प्रत्येक फ़ाइल / प्रति प्रोजेक्ट / प्रति लेखक में जाँचे गए दोषों के # ट्रैक करेगा।
    • एक बार जब आपके पास पर्याप्त आंकड़े होंगे, तो उम्मीद है कि आप देखेंगे कि आपके कोड में कुछ अन्य कोड की तुलना में कम दोष / परिवर्तन हैं। यह कठिन डेटा है जिसका आप उपयोग कर सकते हैं। यदि किसी एकल परियोजना में औसत दोष दर से काफी ऊपर है, तो इसे कुछ तकनीकी ऋण का भुगतान करने के लिए अगले क्लीन-अप / रीफैक्टरिंग प्रयास के लिए एक उम्मीदवार के रूप में लाएं।
    • यदि कोई प्रोजेक्ट या फ़ाइल औसत दोष दर से काफी ऊपर है और इसका एक मालिक है, तो उस व्यक्ति के साथ एक-एक बात करें। उनसे पूछें, बहुत विनम्रता से, गैर-टकराव से कि वे इसे संबोधित करने के लिए क्या कर सकते हैं। चूँकि वे मालिक हैं, उन्हें परिवर्तन को चलाना चाहिए, लेकिन अपनी ओर से कोई भी और सभी मदद की पेशकश करें। उम्मीद है, मालिक अपने स्वयं के स्पेगेटी कोड के लिए बहुत सारे कारणों का पता लगाएगा और जैसे ही वे मदद मांगेंगे, वह तब होगा जब आप कार्रवाई में बहेंगे और कुछ ठोस उपाय करेंगे।

1
यह उत्कृष्ट है, धन्यवाद। मैंने इनमें से कुछ तकनीकों (जेन *) से पहले कोशिश की है, आप अपने कोड फॉर्मेटर को x, y, z में क्यों नहीं बदलते हैं, इससे पहले 2 मिनट लगते हैं), और मुझे हमेशा लिप सर्विस मिलती है और कुछ भी नहीं होता है। साथ ही, मेरा एक सहकर्मी दूसरे की तुलना में स्पष्ट रूप से मजबूत है; उस रेखा पर जहां वह बहुत अच्छी हो सकती है, लेकिन निष्पादित करने में विफल रहती है। मैं हर समय कोड की गुणवत्ता के बारे में उसकी बात सुनता हूं, लेकिन जब कार्रवाई करने का समय होता है, तो एक शेल में भी पलटवार करता है: "हमारे पास रिलीज करने के लिए केवल 5 सप्ताह हैं, मैं अब कुछ भी रिफ्लेक्टर नहीं करना चाहता हूं"। और मैं फेसपालम। * नाम बदल दिया गया
hvgotcodes

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

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

2

मेरा सुझाव है कि आप इस मुद्दे के बारे में अपने प्रबंधक से बात करें, लेकिन वह लगभग निश्चित रूप से हर एक चेक-इन की समीक्षा नहीं करना चाहते हैं।

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

यदि वह पूरी तरह से अप्रभावी हो जाता है, तो शायद आपको उसके सिर के ऊपर जाना चाहिए। यदि आप ऐसा करने का निर्णय लेते हैं, तो आपको अपना सर्वश्रेष्ठ खेल लाने की आवश्यकता होगी। यदि आप ऐसा करते हैं तो आप मूल रूप से उच्च स्तर पर काम पर रखने के लिए प्रबंधन को पिच कर रहे होंगे।


1
मैंने उल्लेख नहीं किया कि यह क्लाइंट साइड काम है। स्वचालित कार्यात्मक परीक्षण पाइपलाइन हैं, लेकिन वे इकाई परीक्षण नहीं हैं, इसलिए प्रतिक्रिया दैनिक होगी, तत्काल नहीं।
hvgotcodes

2
@hvgotcodes: मैं यह नहीं देखता कि क्यों आपको प्रत्येक चेकइन पर चलने के लिए इकाई परीक्षण बनाने से रोकता है।
मैरिन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.