तोड़फोड़: सही कामों के लिए चेकलिस्ट

हम मानते हैं कि पाठक: क) एक टीम में काम करता है; और बी) संस्करण नियंत्रण प्रणालियों के साथ सही ढंग से काम करने की आवश्यकता का एहसास हुआ, या कम से कम एक का उपयोग करने की आवश्यकता के साथ सामना किया गया था।



तोड़फोड़ का उपयोग उदाहरणों में किया जाएगा, हालांकि सभी सिफारिशें पूरी तरह से किसी भी अन्य संस्करण नियंत्रण प्रणाली पर लागू होती हैं।



मोटे तौर पर परियोजना के विकास के चरणों को तीन में विभाजित करें - डेब्यू, मिडगेम और एंडगेम।



पदार्पण में, नए कोड को विशाल मात्रा में लिखा जाता है, अक्सर सिस्टम के पूरे हिस्से को एक स्थान से दूसरे स्थान पर स्थानांतरित किया जाता है। रिलीज दूर है, सिस्टम की सामान्य स्थिति के लिए कोई विशेष आवश्यकताएं नहीं हैं। यहां तक ​​कि कुछ सीमा तक प्रणाली को तोड़ने की भी अनुमति है।



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



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







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



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



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



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



सामान्य तौर पर, हमारी राय में, जिस परियोजना पर वह काम कर रहा है उसकी गुणवत्ता के साथ उस परियोजना के प्रोग्रामर द्वारा समझ की गहराई को दृढ़ता से सहसंबद्ध किया जाता है।



कमिट तार्किक होना चाहिए। एक प्रतिबद्ध को एक संरचनात्मक इकाई के अनुरूप होना चाहिए - एक नई फ़ाइल, एक नया ब्लॉक, एक नया सम्‍मिलक, एक नया वर्ग, एक नया संबंध, एक नई सुविधा, एक बंद बग, एकल पुन: निर्माण, प्रलेखन का प्रमुख, प्रलेखन का सुधार आदि।



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



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



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



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



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



कमिट करने से पहले, आपको अलग-अलग देखने की ज़रूरत है, साथ ही रिपॉजिटरी में नहीं जोड़ी गई नई फ़ाइलों की निगरानी करें और उन्हें जोड़ें। यदि आप TortoiseSVN का उपयोग करते हैं, तो इसमें एक विशेष मेनू आइटम है, जिसे "संशोधनों के लिए चेक" कहा जाता है। कमांड-लाइन क्लाइंट में, svn सेंट (ढीली फ़ाइलों के लिए) और svn diff | अधिक (करने से पहले परिवर्तनों की समीक्षा करने के लिए)।



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



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



इसके अलावा छोटे नियम:



- किसी फ़ाइल का नाम बदलने और उसमें परिवर्तन करने के दौरान, आपको अलग से नाम बदलना चाहिए, और अलग से बदलना चाहिए;



- प्रोजेक्ट कोड में थर्ड-पार्टी कंपोनेंट (रेल्स प्लगइन, प्रोटोटाइप.जेएस फाइल) जोड़ते समय, उन्हें अलग से प्रतिबद्ध होना चाहिए;



- आपको कोड की टिप्पणी वाली लाइनें नहीं छोड़नी चाहिए - पुराने संस्करणों को संग्रहीत करने के लिए, स्वाभाविक रूप से, एक संस्करण नियंत्रण प्रणाली है (कुछ मामलों में, यह नियम एक-दो-पंक्ति सुधार के साथ उल्लंघन हो सकता है)।



प्रश्न, इच्छाएं, सुझाव?



पुनश्च हमारे पास रिक्तियों का एक पूरा गुच्छा है: undev.ru