सुधार और संस्करण नियंत्रण

Question

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

SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;

के रूप में बेहतर लिखा जा सकता है / से बेहतर लिखा गया है

SELECT persons.id,
       persons.name,
       addresses.address
  FROM persons
  JOIN addresses ON persons.id = addresses.person_id;

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

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

• सभी में समान शैली है
• न्यूनतम मर्ज का काम

?

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

Comments

आप इतिहास को फिर से क्यों लिखना चाहेंगे? यह संस्करण नियंत्रण के उद्देश्य को पराजित करता है। आप यह सुनिश्चित करना चाहते हैं कि आपके द्वारा 3 महीने पहले अपलोड किया गया आवेदन थोड़ा सा संदेह के बिना संशोधन xxxxxx से मेल खाता है। यहां तक ​​कि तुच्छ सुधार भी अस्वीकार्य है।

— साइमन बर्गोट

मैं टिप्पणी करना पसंद करता हूं कि मैं इसे "रिफॉर्मैट। कोई कार्यात्मक परिवर्तन" के साथ टैग नहीं करता हूं

— रिग

एक असंबंधित विषय पर, ऐसा लगता है कि आप सभी कोड को सुधार कर गिट इतिहास को फिर से लिखने का सुझाव दे रहे थे। लोगों को विचार न दें, 99.9% मामलों के लिए गिट इतिहास को फिर से लिखना बुरा है। रिफॉर्मेटिंग .1% एज केस नहीं है।

— एंड्रयू टी फिनेल

कुछ भाषाओं में (मैं आपको देख रहा हूँ, पायथन) पुन: स्वरूपण कोड की तार्किक कार्यप्रणाली को बदल सकता है। आपको अपने VCS में संग्रहीत सभी भाषाओं को पार्स करने और सुधारों को सुरक्षित रूप से अनदेखा करने में सक्षम होना होगा।

— जोरिस टिम्मरमन्स

सुधार कोड परिवर्तन हैं और इस तरह से प्रतिबद्ध होना चाहिए।

— डेविड काउडन

Answer 1

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

Comments

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

— जॉनट्रॉन

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

— १

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

— जॉनट्रॉन

प्रोग्रामिंग में, कुछ भी उतना सरल नहीं है जितना कि यह लगता है :)

— harald

Answer 2

VCS इतिहास को फिर से न लिखें: यह VCS सिद्धांतों के विरुद्ध है।

स्वरूपण को ठीक करने का प्रयास करने की कोशिश न करें: यह लक्षणों का इलाज कर रहा है, वास्तविक समस्या नहीं (= डेवलपर्स कोडिंग मानकों का पालन नहीं कर रहा है)।

एक सामान्य दस्तावेज़ में कोडिंग मानक और स्वरूपण सर्वोत्तम प्रथाओं को परिभाषित करें और सभी डेवलपर्स को सहमत होने के लिए प्राप्त करें।

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

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

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

Comments

डाउनवोटेड, क्योंकि लेखक स्पष्ट रूप से बताता है कि यह उन परियोजनाओं के संदर्भ में है जो "... एक स्पष्ट, पूर्ण, सत्यापन योग्य और लागू स्टाइल गाइड 1 दिन से" शुरू नहीं हुए थे। वह वास्तविक समस्या का इलाज नहीं कर सकता, क्योंकि यह पहले ही हो चुका है। मैं आपसे सहमत हूँ हालांकि :)

— Johntron

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

— 18446744073709551615

Answer 3

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

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

इसलिए, इसे स्थापित करने के लिए STRICTLY स्थापित कोड में परिवर्तन करने के लिए इसके लायक नहीं है। परिवर्तनशील नामों को बदलना, लंबे कार्यों को तोड़ना, सामग्री को बदलने वाले सभी अच्छे रीफैक्टरिंग सामान, हां, लेकिन सिर्फ सुधार नहीं।

1) - मैं एक बार थोड़ी देर के लिए विंडोज क्लिपबोर्ड व्यूअर का मालिक था। पूरी बात एक, 150k, C मॉड्यूल थी। मुझे एक ऐसा स्थान मिला जहां विभिन्न लोगों ने उपयोग किया था, मुझे लगता है, एक दूसरे की तीस लाइनों के भीतर पांच अलग-अलग ब्रेस स्टाइल। लेकिन चीजों की वह धारा काम करती है। मैंने दस साल तक उस कोड के एक प्रिंटआउट को इधर-उधर किया, लेकिन मैंने इसे इसलिए नहीं टटकाया क्योंकि उस इतिहास में कोई फर्क नहीं पड़ा था, और यह कोड कम से कम तीन स्रोत पेड़ों (विंडोज 3.x, NT, भविष्य के 95) में था, जो सभी रहते थे विभिन्न भवनों में।

Comments

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

— मार्क जूथ

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

— जॉनट्रॉन

Answer 4

लेकिन आप प्रमुख स्वरूपण परिवर्तनों में कोड परिवर्तनों को कैसे ट्रैक करते हैं?

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

लेकिन यह बहुत काम है, और बाकी सभी को काम करना होगा (या सभी मर्जों की माँ के लिए तैयार रहना होगा) जबकि यह चल रहा है।

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

Answer 5

दो व्यवहार्य दृष्टिकोण हैं जो मैंने इसके लिए देखे हैं।

1. प्रतिबद्ध हुक पर सुधार कोड

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

2. सभी कोड का एकमुश्त सुधार

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

Comments

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

— हस्ताक्षर करें

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

— l0b0

अगर IDE का समर्थन है तो वहाँ भी 3) IDE ऑटोफ़ॉर्मेट सेव में है। फिर बस हर जगह एक ही सेटिंग का उपयोग करें - यह आसान है अगर आप आईडीई के साथ डिफ़ॉल्ट का उपयोग करते हैं।

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

— Druska