कोडिंग त्रुटियों पर समय बर्बाद करना बंद करें। अब ठीक करें।

मुझे अब भी वह अहसास याद है. जब एक छोटी सी कोडिंग त्रुटि पूरे प्रवाह को तोड़ देती है तो एक साफ़ प्रोजेक्ट कुछ ही सेकंड में गड़बड़ में बदल सकता है। पेज लोड होना बंद हो जाता है. ऐप क्रैश हो जाता है. एक बटन कुछ नहीं करता. बग छोटा लग सकता है, फिर भी यह फोकस चुरा लेता है और सब कुछ धीमा कर देता है। जब ऐसा होता है तो मैं अनुमान लगाने की कोशिश नहीं करता. मैं गति धीमी करता हूं, कोड को स्पष्ट नजर से देखता हूं और एक बार में एक चरण में स्रोत को ठीक करता हूं। 1. कोड को छूने से पहले मैं त्रुटि संदेश पढ़ता हूं। कई लोग संदेश को छोड़ देते हैं और सीधे संपादन में चले जाते हैं। मैं भी ऐसा करता था. इससे आम तौर पर चीज़ें और ख़राब हो जाती थीं। एक अच्छा त्रुटि संदेश पहले से ही एक संकेत देता है। यह किसी फ़ाइल नाम, पंक्ति संख्या या ख़राब मान की ओर संकेत कर सकता है। यदि संदेश कहता है कि एक वेरिएबल अपरिभाषित है, तो मैं किसी भी अन्य चीज़ से पहले उस नाम की जाँच करता हूँ। यदि यह कहता है कि कोई फ़ंक्शन नहीं मिला है, तो मैं वर्तनी की गलती या गुम आयात की तलाश करता हूं। एक छोटा सा उदाहरण: मैंने एक बार जावास्क्रिप्ट में एक बग का पीछा करते हुए बीस मिनट बिताए थे। पेज विफल होता रहा, और मुझे लगा कि समस्या मेरे एपीआई कॉल के अंदर है। असली मुद्दा एक साधारण टाइपो था. मैंने userName के स्थान पर userNmae लिखा। त्रुटि संदेश ने पहले ही समस्या का संकेत दे दिया था। मैंने शुरुआत में इसे नज़रअंदाज़ कर दिया। उस गलती ने मुझे एक सरल नियम सिखाया: संदेश पढ़ें, फिर कार्य करें। 2. मैं अपने द्वारा किए गए अंतिम परिवर्तन की जाँच करता हूँ अधिकांश बग परिवर्तन के तुरंत बाद दिखाई देते हैं। कोड की एक नई पंक्ति. एक पुनर्नामित फ़ाइल. ऐसी स्थिति जो हानिरहित दिखती है. मैं अपने आप से पूछता हूं, "इसके टूटने से पहले मैंने क्या छुआ था?" वह प्रश्न मेरा बहुत समय बचाता है। यदि कोड पहले काम करता था, तो मैं पुराने संस्करण की तुलना नए संस्करण से करता हूँ। मैं ढूंढता हूं: - बदले गए चर नाम - गायब कोष्ठक - टूटे हुए उद्धरण - गलत फ़ाइल पथ - तर्क जो अब लक्ष्य से मेल नहीं खाता है यह चरण अच्छी तरह से काम करता है क्योंकि यह खोज को सीमित करता है। मुझे प्रोजेक्ट की प्रत्येक पंक्ति का निरीक्षण करने की आवश्यकता नहीं है। मुझे केवल उस हिस्से पर ध्यान केंद्रित करने की ज़रूरत है जो बदल गया है। 3. मैं छोटे टुकड़ों का परीक्षण करता हूं, पूरे सिस्टम का नहीं, बड़े कोड ब्लॉक वास्तविक समस्या को छिपा सकते हैं। जब मैं किसी समस्या को छोटे भागों में विभाजित करता हूं, तो मैं देख सकता हूं कि त्रुटि कहां से शुरू होती है। मैं एक फ़ंक्शन का परीक्षण करता हूं। मैं एक मान लॉग करता हूं। मैं एक अनुरोध की जाँच करता हूँ। इससे मुझे एक साफ़-सुथरा दृश्य मिलता है। उदाहरण के लिए, यदि कोई फॉर्म सबमिट नहीं होता है, तो मैं यह नहीं मानता कि पूरा फॉर्म टूटा हुआ है। मैं पहले इनपुट मान का परीक्षण करता हूं। फिर मैं सबमिट हैंडलर की जांच करता हूं। फिर मैं नेटवर्क अनुरोध को देखता हूं। बहुत बार, कीट एक छोटी सी जगह पर बैठता है। यह दृष्टिकोण शुरू में धीमा लगता है, फिर भी यह आमतौर पर अधिक समय बचाता है। मैं छाया का पीछा करना बंद कर देता हूं। 4. मैं लॉग का उपयोग फ्लैशलाइट की तरह करता हूं कंसोल लॉग सरल हैं, लेकिन वे बहुत मदद करते हैं। मैं मुख्य बिंदुओं पर मान प्रिंट करता हूं ताकि मैं देख सकूं कि कोड क्या कर रहा है। मैं उनका उपयोग यह जांचने के लिए करता हूं: - क्या डेटा आता है - फ़ंक्शन चलने के बाद क्या बदलता है - घटक या एंडपॉइंट क्या छोड़ता है - जहां मूल्य मेरी योजना से मेल खाना बंद कर देता है मेरे काम से एक वास्तविक मामला: मैं एक रिएक्ट ऐप के साथ मदद कर रहा था जो खाली उपयोगकर्ता कार्ड दिखाता था। डेटा कॉल सफल रही, इसलिए टीम को लगा कि समस्या एपीआई में है। मैंने कुछ लॉग जोड़े और पाया कि प्रतिक्रिया का आकार यूआई की अपेक्षा से भिन्न था। ऐप data.user.name चाहता था, लेकिन एपीआई ने data.profile.name भेजा। एक छोटा सा बेमेल, एक खाली स्क्रीन। लॉग्स ने एक अस्पष्ट बग को स्पष्ट समाधान में बदल दिया। 5. मैं अपेक्षित आउटपुट की तुलना वास्तविक आउटपुट से करता हूं। यह आदत मुझे जमीन से जोड़े रखती है। मैं वह लिखता हूं जो मैं कोड से करने की अपेक्षा करता हूं, फिर मैं जांचता हूं कि यह वास्तव में क्या करता है। वह अंतर अक्सर गलती उजागर कर देता है। यदि मैं एक बटन क्लिक से मोडल खोलने की उम्मीद करता हूं, तो मैं तीन चीजों की जांच करता हूं: - क्या क्लिक इवेंट सक्रिय होता है - क्या स्थिति अपडेट होती है - क्या मोडल को नई स्थिति प्राप्त होती है यदि एक टुकड़ा विफल हो जाता है, तो मुझे पता है कि आगे कहां देखना है। मैं बग को एक रहस्यमय उपन्यास की तरह नहीं मानता। मैं इसे एक अनुक्रम की तरह मानता हूं। 6. मैं आसान चीजों की भी जांच करता हूं कुछ बग सादे दृश्य में छिप जाते हैं। एक लुप्त अल्पविराम. फ़ाइल पथ के अंदर एक स्थान. स्थानीय सेटअप में गलत एपीआई कुंजी। ब्राउज़र कैश समस्या. ये समस्याएँ बहुत सारी ऊर्जा बर्बाद कर सकती हैं क्योंकि इनका कारण बनना बहुत आसान लगता है। मैंने एक बार एक फ़ोल्डर पथ को बदलकर एक टूटी हुई छवि अपलोड को ठीक किया था। कोड स्वयं ठीक था. परिनियोजन के बाद पथ गलत निर्देशिका की ओर इंगित करता है। मैंने तर्क की दो बार जाँच की थी, फिर भी उत्तर फ़ाइल नाम में ही रहा। साधारण जाँचें छोटी जाँचें नहीं होतीं। वे नौकरी का हिस्सा हैं. 7. मैं सामान्य कारणों की एक छोटी सूची रखता हूं। समय के साथ, मैंने देखा कि एक ही प्रकार की त्रुटियां बार-बार सामने आती हैं। यहां वे हैं जिन्हें मैं सबसे ज्यादा देखता हूं: - वेरिएबल या फ़ंक्शन नामों में वर्तनी की गलतियां - गायब आयात - गलत डेटा प्रकार - ऑफ-बाय-वन लूप लॉजिक - खराब फ़ाइल पथ - बेमेल एपीआई प्रतिक्रिया - अपेक्षित होने पर अपडेट नहीं होने वाली स्थिति - गलत तरीके से लिखी गई स्थिति मैं केवल मेमोरी पर भरोसा नहीं करता। मैं इस सूची को अपने कार्यक्षेत्र के पास रखता हूं। जब कोड सक्रिय होने लगता है तो इससे मुझे शांत रहने में मदद मिलती है। 8. मैं बुनियादी बातों की जांच करने के बाद मदद मांगता हूं, मैं मदद को अंतिम उपाय नहीं मानता हूं। सामान्य कारणों को खारिज करने के बाद मैं इसे एक स्मार्ट कदम मानता हूं। यदि मैं बहुत देर तक अटका रहता हूं, तो मैं टीम के किसी साथी को कोड दिखाता हूं या विश्वसनीय दस्तावेज़ों से इसकी तुलना करता हूं। आँखों की एक ताज़ा जोड़ी मिनटों में वह चीज़ देख सकती है जो मैं भूल गया था। उन्होंने कहा, मैं एक स्पष्ट प्रश्न लाने का प्रयास करता हूं। मैं समझाता हूँ कि मुझे क्या उम्मीद थी, मैंने क्या देखा और मैंने पहले ही क्या जाँच कर ली है। इससे बातचीत उपयोगी हो जाती है. यह सभी के समय का भी सम्मान करता है। मेरा मानना ​​है कि अच्छी डिबगिंग एक कौशल है, अनुमान नहीं। सबसे तेज़ समाधान हमेशा सबसे चतुर समाधान नहीं होता है. यह आमतौर पर शांत कदमों, स्पष्ट जांच और कोड को ईमानदारी से पढ़ने पर बनाया जाता है। जब मैं इस तरह से काम करता हूं, तो मैं कम ऊर्जा बर्बाद करता हूं, कम गलतियां दोहराता हूं, और प्रत्येक बग से अधिक सीखता हूं। यदि आज आपका कोड ख़राब हो रहा है, तो छोटी शुरुआत करें। संदेश पढ़ें. अंतिम परिवर्तन की जाँच करें. एक समय में एक टुकड़े का परीक्षण करें. उत्तर प्रायः जितना दिखता है उससे अधिक निकट होता है।

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

मैं सोचता था कि क्लीन कोड एक स्टाइल विकल्प है। मैं अब इसे उस तरह नहीं देखता. जब कोड गड़बड़ हो जाता है, तो हर छोटा परिवर्तन गायब ब्रैकेट, छिपे हुए तर्क और पुराने सुधारों की खोज में बदल जाता है जो किसी को याद नहीं रहते। दर्द दैनिक कार्यों में दिखाई देता है। एक टीम का साथी एक साधारण अपडेट के लिए पूछता है, और कार्य धीरे-धीरे मरम्मत कार्य में बदल जाता है। एक बग आ जाता है। समीक्षा में बहुत लंबा समय लगता है क्योंकि पाठक को इरादे का अनुमान लगाना होता है। मुझे स्वच्छ कोड की परवाह है क्योंकि यह समय और विश्वास की रक्षा करता है। मुझे ऐसा कोड चाहिए जिसे कोई अन्य व्यक्ति बिना अनुमान लगाए पढ़ सके। मुझे ऐसा कोड चाहिए जो फीचर की कहानी ऊपर से नीचे तक बताए। जब उत्पाद बदलता है तो मैं भी कम आश्चर्य चाहता हूँ। मैं इसे इस तरह से संभालता हूं: - मैं चीजों को ऐसे नाम देता हूं जैसे मैं किसी टीम के साथी से बात कर रहा हूं। यदि कोई वैरिएबल कार्ट में आइटमों की संख्या रखता है, तो मैं इसे cartItemCount कहता हूं। मैं उन शॉर्टकट तरीकों के पीछे अर्थ नहीं छिपाता जो केवल मेरे लिए मायने रखते हैं। - मैं एक कार्य पर एक कार्य रखता हूं। एक लंबा फ़ंक्शन जो भुगतान की जाँच करता है, कर की गणना करता है, मेल भेजता है, और लॉग लिखता है उस पर भरोसा करना कठिन है। मैंने इसे विभाजित कर दिया. प्रत्येक भाग को एक स्पष्ट उद्देश्य मिलता है। - मैं वह कोड हटा देता हूं जो अब उत्पाद में फिट नहीं बैठता। पुराना तर्क हानिरहित लग सकता है. यह अक्सर संदेह पैदा करता है. यदि कोई नियम समाप्त हो गया है, तो मैं पुरानी शाखा को हटा देता हूं ताकि बाद में किसी को भूत पथ का परीक्षण न करना पड़े। - मैं कारणों से टिप्पणियाँ लिखता हूँ, स्पष्ट कोड के लिए नहीं। मैं यह नहीं समझाता कि एक पंक्ति पहले से ही क्या कहती है। मैं समझाता हूं कि विकल्प क्यों मौजूद है। जब व्यावसायिक नियम बदलते हैं तो इससे मदद मिलती है। - मैं उन हिस्सों का परीक्षण करता हूं जो टूट सकते हैं। मैंने एक चेकआउट पृष्ठ को विफल होते देखा है क्योंकि एक कूपन नियम और एक शिपिंग नियम में एक ही फ़ील्ड का अलग-अलग तरीकों से उपयोग किया गया था। अधिक उपयोगकर्ताओं के संपर्क में आने से पहले एक छोटे परीक्षण सूट ने समस्या का खुलासा कर दिया। उसके बाद, टीम कम डर के साथ कोड बदल सकती थी। मैं भी अपना कोड किसी अजनबी की तरह पढ़ता हूं। उस आदत ने मेरा काम बदल दिया. यदि मुझे किसी ब्लॉक को रोकने और डिकोड करने की आवश्यकता है, तो मुझे पता है कि कोड एक साफ़ आकार की मांग कर रहा है। इससे पहले कि अगला व्यक्ति इसकी कीमत चुकाए, मैं इसे दोबारा लिखता हूं। क्लीन कोड का मतलब हर फ़ाइल को परफेक्ट बनाना नहीं है। मैं पॉलिश से ज़्यादा स्पष्टता की परवाह करता हूँ। एक साधारण संरचना मुझे बाद में तेजी से आगे बढ़ने में मदद करती है। एक अव्यवस्थित शॉर्टकट अभी दस मिनट बचा सकता है, फिर अगले परिवर्तन में एक घंटा लग सकता है। मैंने उस व्यापार को कई बार महसूस किया है। मेरा नियम सरल है. यदि कोई टीम-साथी मेरी फ़ाइल खोलता है, तो मैं चाहता हूँ कि अगला कदम बिना किसी अनुमान के स्वाभाविक लगे। वह मानसिकता कार्य को स्थिर रखती है। यह कोड समीक्षा को आसान बनाता है, बग फिक्सिंग को आसान बनाता है, और नई सुविधा कम काम करती है। क्लीन कोड अभी प्रारंभ होता है, अगली रिलीज़ के बाद नहीं, और अगले क्लीनअप स्प्रिंट के बाद नहीं। मैं एक फ़ंक्शन, एक नाम, एक परीक्षण, एक छोटे सुधार के साथ शुरुआत करता हूं। यह कोडबेस का आकार बदलने के लिए पर्याप्त है। क्या आप उद्योग के रुझानों और समाधानों के बारे में अधिक जानने में रुचि रखते हैं? wzsanying से संपर्क करें: 780877550@qq.com/WhatsApp 13858841904।

रॉबर्ट सी मार्टिन 2008 क्लीन कोड ए हैंडबुक ऑफ एजाइल सॉफ्टवेयर क्राफ्ट्समैनशिप एंड्रयू हंट और डेविड थॉमस 1999 द प्रैग्मैटिक प्रोग्रामर फ्रॉम जर्नीमैन टू मास्टर मार्टिन फाउलर 2018 रिफैक्टरिंग इम्प्रूविंग द डिजाइन ऑफ मौजूदा कोड जॉन सोनमेज़ 2015 द कम्प्लीट सॉफ्टवेयर डेवलपर करियर गाइड केंट बेक 2002 टेस्ट ड्रिवेन डेवलपमेंट बाय उदाहरण स्टीव मैककोनेल 2004 कोड कम्प्लीट ए प्रैक्टिकल सॉफ्टवेयर निर्माण की पुस्तिका