मैनेजर रीडिंग वर्जन कंट्रोल कमिट करता है

Question

हमारे प्रबंधक हमारे सभी परियोजनाओं पर Git के आने की निगरानी कर रहे हैं; आमतौर पर यह कोई समस्या नहीं है, और मुझे इस तथ्य से प्यार है कि संस्करण नियंत्रण सभी कार्यों का लॉग प्रदान करता है, जो विशेष रूप से बाद में ऑडिटिंग और विश्लेषण के लिए होता है (यदि कुछ भी गलत होता है)।

हालाँकि, प्रबंधक ने कुछ टिप्पणियां करते हुए पूछा है कि जब लोग "स्टाइल फ़िक्स" या किसी भी प्रतिबद्ध संदेश को पढ़ते हैं, जो हमारे कार्य प्रबंधन प्रणाली में टिकट नंबर का संदर्भ नहीं देता है, तो उसे देखते हुए लोग क्या काम कर रहे हैं।

क्या इसका कोई सामाजिक या तकनीकी समाधान है?

अधिक जानकारी: यह एक रखरखाव परियोजना है, इसलिए "ए ए बी बी सी फिर सी और फिर डी करना था और फिर एक्स" कार्यों को लागू करने के लिए मिला।

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

Comments

संभव संदेश के बग में बग / मुद्दे के संदर्भ में

— gnat

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

— रोबोट

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

— Gort the Robot

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

— gnat

यह पूरी तरह से स्थिति पर निर्भर करता है। क्या प्रबंधक उस टीम के एक सदस्य को प्रतिक्रिया दे रहा है जो अपना 50% समय रिफैक्टरिंग पर या बिना टिकट संदर्भ के एक ही प्रतिबद्ध पर खर्च कर रहा है?

— winkbrace

Answer 1

क्या इसका कोई सामाजिक या तकनीकी समाधान है?

मुझे लगता है, लेकिन यह कोई समस्या नहीं है ।

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

यह केवल एक समस्या बन जाती है यदि आपका प्रबंधक सोचता है कि केवल टिकट का काम किया जाना चाहिए, और टिकट होने से तकनीकी सफाई कार्य को रोकता है। वहाँ हमेशा साफ करने के लिए तकनीकी ऋण है। हमेशा चीजों को ट्विस्ट करें क्योंकि आपको चाहिए, भले ही वे कोई स्पष्ट, तत्काल व्यावसायिक लाभ प्रदान न करें।

Answer 2

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

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

अपनी योजना के दौरान आप तकनीकी ऋण से संबंधित टिकटों के माध्यम से जा सकते हैं और उन्हें वास्तविक रखरखाव टिकटों के साथ संलग्न कर सकते हैं जो आप इस तरह से काम कर रहे हैं जो इसे अधिक भरोसेमंद बनाते हैं।

यह आपको "कहीं से भी बाहर" फ़िक्सेस को खत्म करने में मदद करेगा और उन सभी चीज़ों को विशिष्ट समस्याओं / टिकटों की श्रेणी में रखेगा जो आप काम कर रहे हैं।

Comments

ठीक है लेकिन अगर यह एक तुच्छ निर्धारण है तो यह पूरी तरह से बेवकूफी है।

— मोनिका

टेक ऋण 99.99% समय तुच्छ परिवर्तन नहीं है। यही कारण है कि मैं कहता हूं कि एक और संदर्भ में स्विच करने के बजाय एक टिकट बनाओ जो एक बड़ा संदर्भ स्विच है। यदि यह कुछ तुच्छ और असंबंधित है, जिस पर आप काम कर रहे हैं, तो आप अभी भी टिकट नाम के तहत इसकी जांच कर सकते हैं कि आप एक अलग टिप्पणी के साथ काम कर रहे हैं। या बेहतर अभी तक एक संकेतन के लिए QFIX जैसे एक संकेतन के बारे में सोचें, ताकि बाद में आपके पास कोई संगठन न होने वाले यादृच्छिक तुच्छ परिवर्तन न हों।

— ऐविटिसगैस

क्या होगा अगर प्रबंधक नए टिकटों के लिए JIRA देख रहा है और फिर उन लोगों से पूछताछ कर रहा है? जब कोई टिकट भविष्य के स्प्रिंट से वर्तमान में ले जाया जाता है, तो वह सवाल नहीं करता है, लेकिन जैसे ही कोई व्यक्ति तकनीकी ऋण से संबंधित एक नया टिकट बनाता है, तो यह सवाल किया जाता है।

— रुडोल्फ ओलह

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

— एवेटिसगैस

@omouse यह अच्छी तरह से हो सकता है कि आपका प्रबंधक micromanaging कर रहा है, या वह ठीक से तकनीकी ऋण के साथ काम नहीं कर रहा है। हालाँकि, प्रबंधक अंततः एक पूरे के रूप में परियोजना के लिए ज़िम्मेदार होता है, और स्वयं कोड के लिए ज़िम्मेदार होता है, और इसलिए आदर्श रूप से हर स्तर पर हर काम के बारे में पता होना चाहिए जो आगे बढ़ता है और क्यों।

— रोबर्ट

Answer 3

यह मुझे भी परेशान करता है (कोई सज़ा का इरादा नहीं :)।

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

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