क्या डेवलपर्स को महत्वपूर्ण जानकारी देने के लिए प्रतिबद्ध इतिहास का उपयोग किया जाना चाहिए?


94

नवीनतम संस्करण से तीसरे पक्ष के एसडीके के रोलबैक के बारे में एक बैठक के दौरान यह ध्यान दिया गया था कि हमारे डेवलपर्स ने पहले ही प्रतिबद्ध किया था कि नवीनतम संस्करण का उपयोग नहीं किया जाना चाहिए।

कुछ डेवलपर्स ने तर्क दिया कि यह एक बुरा अभ्यास था और इसे इसके बजाय स्रोत फ़ाइल (यानी // Don't upgrade SDK Version x.y.z, see ticket 1234) या प्रोजेक्ट स्तर READMEफ़ाइल में नोट किया जाना चाहिए था । अन्य लोगों ने तर्क दिया कि चूंकि प्रतिबद्ध इतिहास परियोजना प्रलेखन का हिस्सा है, इसलिए यह इस तरह की जानकारी के लिए एक स्वीकार्य स्थान है क्योंकि हम सभी को इसे वैसे भी पढ़ना चाहिए।

क्या अन्य डेवलपर्स को महत्वपूर्ण जानकारी देने के लिए प्रतिबद्ध इतिहास का उपयोग किया जाना चाहिए या क्या इस तरह की जानकारी को किसी अन्य स्थान जैसे परियोजना READMEया प्रासंगिक स्रोत फ़ाइल में टिप्पणी के लिए दोहराया जाना चाहिए ?


60
ऐसा लगता है कि आपकी परियोजना में बहुत गंभीर संचार समस्याएं हैं।
छोड़े

82
क्या आपको पूरे प्रतिबद्ध इतिहास के माध्यम से जाने के लिए नए किराए की आवश्यकता है?
स्टीवन एवर्स

3
नया आधार कोड आधार के माध्यम से रोलिंग नहीं होना चाहिए और ऐसा करने के लिए विशिष्ट दिशा के बिना निर्भरता बदलना।
मध्याह्न

28
@ नोटबंदी नए रास्ते से मुख्य विकासकर्ता के रास्ते पर कहीं आपको पूरे प्रतिबद्ध इतिहास से गुजरने में समय लगता है? चित्त आकर्षण करनेवाला।
नाथन कूपर

6
यह अभी भी प्रतिबद्ध इतिहास में केवल महत्वपूर्ण जानकारी डालने के लिए एक अच्छा विचार नहीं है।
17 की 26

जवाबों:


143

अगर मैं किसी तीसरे पक्ष के एसडीके के नए संस्करण में अपग्रेड करने जा रहा हूं, तो मैं जो अंतिम स्थान देखूंगा वह स्रोत नियंत्रण प्रणाली के इतिहास में है।

यदि आपका उत्पाद SDK के संस्करण 2.0 का उपयोग कर रहा है और कोई 3.0 में अपग्रेड करने में रुचि रखता है, तो मुझे नहीं लगता कि यह सोचना उचित है कि उन्हें आपके स्रोत नियंत्रण प्रणाली में समय के साथ पीछे देखना चाहिए ताकि यह पता चल सके कि यह एक अच्छा विचार नहीं है।

यहां, हमारे पास एक टीम विकी है जिसमें कुछ रोचक जानकारी वाले पृष्ठ हैं जो प्रत्येक डेवलपर पढ़ता है (कॉन्वेंट कन्वेंशन, उत्पाद के निर्माण के लिए एक विकास वातावरण कैसे सेट करें, आपको कौन सी थर्ड पार्टी सामग्री स्थापित करने की आवश्यकता है, आदि)। यह उस तरह का स्थान है जो किसी तीसरे पक्ष के पुस्तकालय को अपग्रेड करने के खिलाफ चेतावनी के लिए उपयुक्त होगा।


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

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

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

18
@ मैं एक ही बात सोच रहा था, लेकिन मेरी राय में, यूनिट परीक्षण को v3 से अधिक v2 का उपयोग करने के कारण का प्रदर्शन करना चाहिए , इस तरह अगर यूनिट टेस्ट v4 के साथ गुजरता है, तो आपके पास एक यूनिट टेस्ट नहीं है जिसके लिए v2 की आवश्यकता है कारण।
मत्ती

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

69

यह प्रतिबद्ध इतिहास में ध्यान दिया जाना चाहिए, लेकिन नोटिस लगाने के लिए सबसे अच्छी जगह उसी जगह है जहां आप निर्भरता को परिभाषित करते हैं। यदि आपके पास उदाहरण के लिए एक मावेन .pom फाइल है जो आपकी कलाकृतियों पर निर्भरता की घोषणा करती है, तो मैं कुछ ऐसा करूंगा:

<!-- Do not change the SDK version because it causes Foo crashes. For more detail see Issue #123 -->

सीधे अपनी <dependency>लाइन के ऊपर ।

समस्या # 123 में यह क्रैश होने के बारे में विवरण शामिल होगा, जिस संस्करण को आपने अपडेट किया था, जो क्रैश का कारण बना, और यह संभवतः बाद में फिर से पुनः प्राप्त करने के लिए आपके बैकलॉग में जोड़ा जाना चाहिए - यह संभव है कि समस्या को हल करने वाला अभी तक फिर से नया संस्करण हो। या तो टिकट का संपादन करके, या स्वयं मैन्युअल रूप से, यह टीम को वर्तमान मुद्दे के बारे में बताने के लिए ईमेल करेगा, और ट्रैकर में होने से यह लोगों को बाद में इसे फिर से ढूंढने देता है।

निर्भरता की घोषणा के साथ इसे रखने का कारण यह है कि जो कोई भी संस्करण को बदलना चाहता है वह इसे उसी समय देखेगा जब वे इसे बदलना चाहते हैं और समझ सकते हैं कि उन्हें क्यों नहीं करना चाहिए।

मैं स्रोत कोड में टिप्पणी नहीं करूंगा क्योंकि मैं आसानी से एक ऐसी स्थिति को चित्रित कर सकता हूं जहां कोई आपके आश्रितों पर चेक चलाता है और उन्हें अपग्रेड करना शुरू कर देता है। ऐसा करने के लिए उन्हें TODO टिप्पणी के लिए कोडबेस को स्कैन करने की आवश्यकता नहीं होनी चाहिए।

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


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

35

सूचना के महत्वपूर्ण और गैर-सहज ज्ञान युक्त टुकड़ों का दस्तावेजीकरण किया जाना चाहिए, जहां लोग सूचनाओं पर विचार करते समय देख रहे होंगे।

मैंने जिन टीमों और परियोजनाओं पर काम किया है, उनके लिए मैं इस टिप्पणी के साथ रोल-बैक करूंगा कि नया संस्करण विफल क्यों हुआ। अगर नया संस्करण ठीक हो जाता है तो मैं नवीनीकरण के लिए एक बैकलॉग कहानी जोड़ूंगा। मैं निर्माण प्रणाली / स्क्रिप्ट बनाने के लिए टिप्पणी जोड़ूंगा जहाँ पुस्तकालय जुड़ा हुआ है।

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

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


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


7
हां, टिप्पणी को परिवर्तन के "पथ" में रखा जाना चाहिए। इसलिए चेतावनी को देखे बिना कार्रवाई करना तकनीकी रूप से असंभव है। यह सुरक्षा नियंत्रणों की तरह है।
dss539

अपने इश्यू ट्रैकर में अपग्रेड के लिए कहानी / टिकट बनाने के सुझाव के लिए +1, यह क्यों नहीं किया जा सकता है, इस स्पष्टीकरण के साथ "ऑन होल्ड" पर सेट करें। समस्या ट्रैकर एक ऐसी जगह है जिसे आप वास्तव में किसी चीज़ पर काम करने से पहले लोगों को देखने की आवश्यकता कर सकते हैं।
एंड्रयू स्पेंसर

+1 उद्धृत करते हुए जेफ अटवुड (हालांकि, वह यूजी, "उपयोगकर्ताओं" के बारे में बात करता है): "अगली बार जब आप [एक्स] डिजाइन कर रहे हों, तो [ग्राहक] मायोपिया पर विचार करें। आप आश्चर्यचकित हो सकते हैं कि आपके [ग्राहक] कैसे हो सकते हैं। चीजों को सीधे उनके सामने रखने के बारे में लंबे और कठिन सोचें, जहां वे सिर्फ दिखाई नहीं दे रहे हैं, लेकिन अपरिहार्य हैं। अन्यथा वे बिल्कुल भी दिखाई नहीं दे सकते हैं। " blog.codinghorror.com/treating-user-myopia
heltonbiker

17

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

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

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

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


1
यह एक सही जवाब है। यूनिट टेस्ट में फेल होने से खराब अपग्रेड होने से बच जाता है। अवधि।
डिर्क बेस्टर

15

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

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

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


4
+1 वास्तविक कीवर्ड केवल है । यह निश्चित रूप से नुकसान नहीं पहुंचाता है यदि जानकारी को अन्य, अधिक उपयुक्त स्थानों के अलावा एक प्रतिबद्ध संदेश में संग्रहीत किया जाता है । यह ओपी को हिट करता है, क्योंकि कमिट लॉग केवल दस्तावेज उपलब्ध था।
JensG

13

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

दूसरे कहते हैं कि स्थिति लेकिन कोड में बदलाव नहीं, क्या आप "प्रलेखन" बनाने जा रहे हैं ताकि आप "5432 से संशोधन संदेश" की तर्ज पर प्रतिबद्ध संदेश जोड़ सकें, अब गलत है, यहां वर्तमान स्थिति है। "


11

मुझे यकीन नहीं है कि आपकी टीम कैसे संचार करती है, लेकिन मेरा मानना ​​है कि यह कहने का सबसे प्रभावी तरीका है कि टीम के ईमेल समूह को पहले भेजें और ईमेल करें, जिसे "URGENT" के रूप में चिह्नित किया गया है।

दोस्तों, हम SDK v xyz का उपयोग नहीं कर सकते क्योंकि इससे फू बफर ओवरफ्लो होता है और बार सर्विस क्रैश हो जाएगी। संस्करण xyy के साथ छड़ी

यही हमने यहां किया है और यह संदेश को बाहर निकालने का सबसे विश्वसनीय तरीका है। यदि आप वास्तव में उधम मचाते हैं (और यदि आपका ईमेल सिस्टम इसे अनुमति देता है), तो ईमेल पर "रीड रसीद" का अनुरोध करें।

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

इस तरह की समस्या को दस्तावेज करने के लिए एक अतिरिक्त स्थान स्रोत कोड में ही हो सकता है, हालांकि यह हमेशा काम नहीं कर सकता है। यदि SDK version ...केवल एक या दो स्पष्ट स्थानों में संदर्भित किया जाता है, तो आप अपग्रेड न करने के बारे में एक नोट शामिल कर सकते हैं।

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


4
मुझे ईमेल ग्रुप आइडिया पसंद है। मैंने जिन कई स्थानों पर काम किया है, वे अलग-अलग पते पर निर्भर हैं और नए सदस्यों के पास चीजें नहीं हैं।
जेफ

20
अगर आपकी टीम में कोई नया आता है तो क्या होता है? इस तरह के छद्म संस्थागत ज्ञान देने के लिए कौन जिम्मेदार है?
ABMagil

3
@ABMagil: सूचना विकी में जाती है। डेवलपर्स जो टीम के लिए नए हैं, आमतौर पर कुछ परिचयात्मक पृष्ठों पर वहां शुरू किए जाते हैं। फिर वे विशिष्ट व्यक्तियों के पास आते हैं (जिन्होंने नए देव की मदद के लिए समय उपलब्ध कराया है) जब उनके पास विशिष्ट प्रश्न होते हैं (और वे हमेशा करते हैं)। हमारे लिए, यह संभवतः "डेवलपर सेटअप गाइड फॉर एप्लिकेशनएक्स" में समाप्त हो जाएगा, NOTE: Do not use SDK vers. x.y.z because...लेकिन प्रारंभिक संचार एक ईमेल होना चाहिए।
FrustratedWithFormsDesigner

16
-1 ईमेल प्रलेखन के रूप में अच्छी तरह से काम नहीं करते हैं
ब्लूराजा - डैनी पफ्लुगुएट

6
@ BlueRaja-DannyPflughoeft: ईमेल टीम को हर किसी को तुरंत यह बताने के लिए एक सरल और आसान उपयोग विधि प्रदान करता है कि एक विशिष्ट लाइब्रेरी के विशिष्ट संस्करण का उपयोग करने में एक समस्या का पता चला है और इस संस्करण का उपयोग नहीं किया जाना चाहिए। जैसा कि कहा गया है, दीर्घकालिक प्रलेखन एक टीम की विकी या किसी अन्य प्रकार के ज्ञान के आधार पर किया जाता है।
FrustratedWithFormsDesigner

5

कुछ इस तरह की टिप्पणियों में रखा जाना चाहिए था, लेकिन यह अन्य स्थानों में भी होने से लाभ होगा।

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

इस तृतीय-पक्ष SDK के बारे में कुछ प्रकार के दस्तावेज़ होने चाहिए।

  • यह किस समस्या का हल है?
  • इस विशेष को क्यों चुना गया?
  • जहाँ तक विचार करने की आवश्यकता है: संस्करण, उन्नयन, परीक्षण आदि।
  • यह निर्णय कौन करता है?

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


2

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

इतिहास अपेक्षाकृत अनसुलझे पाठ के बहुत बड़े निकाय हैं। वे आमतौर पर डेवलपर को विस्तृत जानकारी प्रदान करते हैं कि क्या बदला है, और इसे क्यों बदला गया है। यह जानकारी अधिभार हो सकती है जब तक कि कोई नहीं जानता कि वे क्या देख रहे हैं।

यदि कोई उपयोगकर्ता यह नहीं जानता है कि वे क्या ढूंढ रहे हैं, तो जानकारी जल्दी से सैकड़ों कमिट लॉग के नीचे दफन हो जाती है, और उनके पास सूचनाओं के ढेर को सामने झुकाने के लिए कोई उपकरण नहीं होता है।


यह उत्तर की तुलना में टिप्पणी की तरह अधिक पढ़ता है। देखें: कैसे जवाब दें
gnat

अच्छी बात है, मैंने इसका विस्तार किया। उम्मीद है कि यह StackExchange के मानदंडों को बेहतर तरीके से पूरा करता है।
कॉर्ट अमोन

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

1

मैं दो बुनियादी समस्याओं, संभवतः तीन के रूप में इस स्थिति की व्याख्या करता हूं।

  • एक अवांछित एसडीके अपग्रेड ने इसे स्रोत में बनाया, जहां यह उत्पाद को नकारात्मक रूप से प्रभावित कर सकता है।
  • इस सवाल से: अवांछित अपग्रेड करने वाले योगदानकर्ता को पिछले, विशिष्ट निर्णय के बारे में पता नहीं था जो अपग्रेड नहीं करना था।

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

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

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

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

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

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


जबकि एसडीके अपग्रेड, जो कि प्रमुख के विपरीत एक मामूली संस्करण संख्या थी, आखिरकार इस सवाल का क्या कारण था, तर्क की यह पंक्ति अब थोड़ी देर के लिए समूह में पॉप अप कर रही है।
rjzii

पुल अनुरोध को अस्वीकार क्यों किया जाएगा? संस्करण प्रतिबंध की खोज (या याद रखने) के लिए उस निर्णय के लिए जिम्मेदार व्यक्ति कैसे माना जाता है?
बेन वोइग्ट

@BenVoigt खैर, या तो टीम के नेतृत्व को प्रतिबंध के बारे में पता था, या किसी ने इसे याद नहीं किया और समस्याओं का सामना करने के बाद इसे फिर से खोज लिया गया। किसी भी तरह से, पुल अनुरोधों का उपयोग करते हुए, नीच नए किराया डेवलपर को दोष नहीं दिया जाता है, क्योंकि वरिष्ठ नागरिकों को इसमें बदलाव करने से पहले बदलाव को मंजूरी दे दी जाएगी,
wberry

@wberry: या एक अलग वरिष्ठ डेवलपर ने संस्करण प्रतिबंध के बारे में जानने वाले से अनुरोध को संसाधित किया। जब तक सभी पुल अनुरोधों को सभी डेवलपर्स द्वारा अनुमोदित नहीं किया जाना चाहिए , जो संसाधनों के संदिग्ध खर्च की तरह लगता है।
बेन वोइगट

0

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

कुछ अन्य उपकरण सदाबहार या Google डॉक्स में एक सार्वजनिक नोटबुक हो सकते हैं।


0

कार्ल के जवाब पर विस्तार करते हुए , मैं एक दृष्टिकोण के साथ जाऊंगा जो चेकइन प्रक्रिया के हिस्से के रूप में प्रतिबंध को स्वचालित रूप से लागू करता है। आपको कुछ ऐसा चाहिए जो डेवलपर की ओर से किसी सक्रिय कार्रवाई की आवश्यकता न हो, जैसे कि डॉक्टर / विकी / README को पढ़ना, और गुप्त रूप से ओवरराइड नहीं किया जा सकता है।

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

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

मैं इस जवाब की सराहना करता हूं कि यह बहुत ही TFS-केंद्रित है, लेकिन संभवतः समान विशेषताएं संस्करण नियंत्रण / CI सिस्टम में मौजूद हैं जो आपकी स्थिति में लागू होती हैं (यदि TFS नहीं)।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.