- David J. Agans की Debugging बग मिलने के बाद उसका कारण खोजकर उसे ठीक करने की डीबगिंग की बुनियाद पर बात करती है, और शुरुआती व मिड-लेवल डेवलपर्स के साथ-साथ अनुभवी लोगों के लिए भी ऐसे सिद्धांत देती है जिन पर बार-बार लौटकर देखा जा सकता है
- यह किताब 9 नियमों में व्यवस्थित है और सिस्टम की समझ, failure को reproduce करना, observation, divide and conquer, change control, audit trail, assumptions की जाँच, बाहरी नज़रिया, और fix की verification को व्यावहारिक उदाहरणों से जोड़ती है
- इसमें पुरानी तकनीक या कंप्यूटर के बाहर के उदाहरण भी आते हैं, लेकिन इसका सार किसी खास tool में नहीं बल्कि समस्या को संकीर्ण करने वाली सोच में है, इसलिए यह hardware और software debugging दोनों पर लागू होती है
- intermittent problems जैसे मुश्किल बग्स के लिए Make it Fail वाली सलाह खास तौर पर उपयोगी है, लेकिन Heisenbug शब्द पर सीधे चर्चा न होना थोड़ी कमी लगती है
- GDB का उपयोग या tests लिखने का तरीका समझाने वाली किताबों से अलग, यह डीबगिंग की बड़ी तस्वीर पर केंद्रित है, इसलिए tool usage और regression testing के लिए अलग सामग्री की ज़रूरत होगी
किताब किस समस्या को लक्ष्य करती है
- David J. Agans की Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems उस प्रक्रिया पर केंद्रित है जिसमें बग पकड़े जाने के बाद उसका कारण खोजकर वास्तव में उसे ठीक किया जाता है
- किसी खास तकनीक या tool से अधिक, यह software और computer hardware developers के लिए ज़रूरी debugging principles को व्यवस्थित करती है
- यह खास तौर पर शुरुआती और मिड-लेवल डेवलपर्स के लिए उपयुक्त है, और अनुभवी लोगों के लिए भी तनावपूर्ण स्थितियों में छूट जाने वाली बुनियादी बातों को फिर से जगाती है
- अनुभव से सीखी जाने वाली debugging को सिद्धांतों और उदाहरणों में संक्षेपित करके देना इसकी बड़ी ताकत है
डीबगिंग के 9 नियम
-
सिस्टम को समझो
- manual पढ़ो, पूरी संरचना समझो, और मूल सिद्धांतों के साथ बारीक व्यवहार को भी जानो
- यह भी देखो कि तुम जो tools इस्तेमाल कर रहे हो, वे क्या दिखाते हैं और क्या छिपा देते हैं
-
इसे fail कराओ
- समस्या को फिर से चलाओ और शुरुआत से failure conditions को सीधे उकसाओ
- failure की नकल करने के बजाय उसे वास्तव में होने दो, और उन uncontrolled conditions को खोजो जो intermittent bugs पैदा करती हैं
- सब कुछ दर्ज करो, statistics पर जरूरत से ज्यादा भरोसा मत करो, और मानो कि दुर्लभ घटनाएँ सच में हो सकती हैं
- debugging tools को मत छोड़ो; उन्हें समस्या को उजागर करने के लिए इस्तेमाल करो
-
सोचना रोककर देखो
- अनुमान के आधार पर जटिल मरम्मत शुरू करने से पहले observable data इकट्ठा करो
- failure और उसकी details को देखो, internal instrumentation बनाओ या external instrumentation जोड़ो
- गहराई में जाने से मत बचो, लेकिन इस बात से सावधान रहो कि observation खुद behavior बदल सकती है, यानी Heisenberg effect
- अनुमान निष्कर्ष नहीं है; वह सिर्फ खोज की सीमा घटाने का साधन है
-
divide and conquer अपनाओ
- successive approximation से खोज का दायरा घटाओ और तय करो कि बग किस तरफ है
- आसानी से दिखने वाले test patterns का उपयोग करो, और खराब state से शुरू करके कारण को संकीर्ण करो
- पहले से ज्ञात bugs और noise को हटाकर जाँच के लक्ष्य को सरल बनाओ
-
एक बार में सिर्फ एक चीज़ बदलो
- मुख्य factors को अलग करो, और fix करने से पहले समझो कि गलत क्या है
- tests भी एक बार में एक ही बदलो और उन्हें normal cases से compare करो
- आखिरी बार जब सब ठीक चल रहा था, उसके बाद क्या बदला यह भी जाँचो
-
audit trail बनाए रखो
- क्या किया, किस क्रम में किया, और उसका क्या नतीजा निकला — इसे audit trail के रूप में दर्ज करो
- मामूली लगने वाली details भी कारण हो सकती हैं, इसलिए घटनाओं को आपस में जोड़कर लिखो
- design process का audit trail भी testing में मदद करता है, इसलिए उसे भी ज़रूर लिखो
-
plug जाँचो
- जिन assumptions को तुम obvious मान रहे हो, उन पर शक करो और शुरुआत से फिर जाँचो
- समस्या खोजने में जिन tools का उपयोग कर रहे हो, उन्हें भी test target में शामिल करो
-
नया नज़रिया पाओ
- जब अकेले अटक जाओ, तो किसी दूसरे व्यक्ति या किसी अलग तरह की व्याख्या से नई insight मिल सकती है
- सिर्फ किसी mannequin को समस्या समझाने भर से भी विचार साफ हो सकते हैं
- expertise का उपयोग करो, अनुभवी लोगों की सुनो, और ego से पहले symptoms साझा करने व मदद माँगने को रखो
-
अगर ठीक नहीं किया, तो वह ठीक नहीं हुआ
- fix के बाद यह verify करो कि वह सच में ठीक हुआ है, और तुम्हारे बदलाव ने वास्तव में root cause हटाया है
- समस्याएँ अपने-आप गायब नहीं होतीं, इसलिए कारण और process दोनों को ठीक करना चाहिए
उदाहरण किस तरह सिद्धांतों को जीवंत बनाते हैं
- सिर्फ rules की list देखें तो चीज़ें सूखी लग सकती हैं, लेकिन विस्तृत व्याख्या और किस्से इन सिद्धांतों को वास्तविक स्थितियों में उतारते हैं
- कई उदाहरण तकनीकी details तक जाते हैं, इसलिए कुछ पाठकों को वे भारी लग सकते हैं
- कुछ उदाहरण पुरानी तकनीक से जुड़े हैं, लेकिन चूँकि केंद्र तकनीक नहीं बल्कि सिद्धांत हैं, इसलिए यह बड़ी समस्या नहीं बनती
- सारे उदाहरण computing से जुड़े नहीं हैं; घर की wiring से जुड़ा एक दिलचस्प उदाहरण भी है
- अगर computer hardware और software की बिल्कुल समझ नहीं है, तो कई examples का पीछा करना मुश्किल होगा
- rules की व्याख्या के बाद कई नियमों को साथ लागू करने वाली कहानियाँ, पाठकों के लिए आसान अभ्यास, help desk tips, और समापन टिप्पणियाँ भी आती हैं
खास तौर पर उभरने वाली बातें और सीमाएँ
- “सोचना रोककर देखो” वाला सिद्धांत खास महत्व रखता है
- क्योंकि बहुत से लोग किसी hypothesis को साबित या खारिज करने के लिए data इकट्ठा करने से पहले ही अनुमान के आधार पर समस्या ठीक करने लगते हैं
- “अगर ठीक नहीं किया, तो वह ठीक नहीं हुआ” भी बहुत असरदार सिद्धांत है
- क्योंकि सिर्फ यह देखना काफी नहीं कि बदलाव हुआ या नहीं; यह भी समझना चाहिए कि कारण क्या था और वह क्यों ठीक हुआ
- “failure को उकसाओ, उसकी नकल मत करो” वाली चर्चा किताब के बाकी हिस्सों जितनी स्पष्ट नहीं है, लेकिन फिर भी समझने लायक है
- intermittent problems आम तौर on सबसे कठिन होती हैं, और किताब Make it Fail में उन्हें संभालने के लिए सीधी सलाह देती है
- Heisenberg का ज़िक्र है, लेकिन software development में प्रचलित शब्द Heisenbug पर चर्चा नहीं है
- Heisenbug वह bug है जो उसे observe या isolate करने की कोशिश करने पर गायब हो जाता है या उसका behavior बदल जाता है
दूसरी सामग्रियों से अंतर
- यह किताब डीबगिंग के बुनियादी सिद्धांतों को केंद्र में रखती है, इसलिए यह tool manuals या testing books से अलग खड़ी होती है
- Richard Stallman आदि की Debugging with GDB: The GNU Source-Level Debugger मुख्य रूप से किसी खास तकनीक या tool commands को समझाती है
- Norman Matloff की Guide to Faster, Less Frustrating Debugging जैसी सामग्री सामान्य सलाह तो देती है, लेकिन Agans की किताब जितना व्यापक दायरा नहीं रखती
- Boris Beizer की Software Testing Techniques जैसी testing books bugs खोजने के लिए tests लिखने पर केंद्रित हैं, जबकि पाए गए bug को कैसे ठीक किया जाए, इस पर अपेक्षाकृत कम बात करती हैं
- bug मिलने के बाद उससे जुड़ा test regression test suite में जोड़ना चाहिए, लेकिन testing और regression testing इस किताब के दायरे से बाहर हैं
पूरक सामग्री और कमी
- किताब की companion website debuggingrules.com पर संबंधित जानकारी के links और डाउनलोड करके प्रिंट किए जा सकने वाले 9 rules के posters हैं
- नियमों को समझने के लिए महत्वपूर्ण sub-rules की पूरी सूची किताब या website के किसी एक पेज पर एक साथ नहीं मिलती, यह थोड़ी कमी लगती है
- symbolic debugger, digital logic probe, ddd on gdb जैसे आम tools और problem types पर अधिक ठोस सलाह व उदाहरण होते तो यह और उपयोगी होती
- computing के बाहर की सामान्य problem solving तक इन्हीं rules को फैलाने वाली एक अलग किताब की जरूरत महसूस होती है, लेकिन इस किताब के examples गैर-कंप्यूटर पाठकों के लिए बहुत तकनीकी हैं
- बुनियादी सिद्धांत ऊपर से भले obvious लगें, लेकिन शुरुआती लोगों को उन्हें सीखना पड़ता है और अनुभवी लोगों को भी बार-बार याद दिलाना पड़ता है; यह किताब उस सीख और याद दिलाने, दोनों के लिए उपयुक्त है
1 टिप्पणियां
Hacker News की राय
मुझे लगता है कि अभी मौजूद टूटे हुए code में “fix” जोड़कर उसे चलाने की कोशिश करने का लालच सबसे नुकसानदेह होता है
टूटे हुए code में बदलने की संभावित जगहें इतनी ज्यादा होती हैं कि उसे ठीक करना मुश्किल होता है, और चलते हुए code को तोड़ना कहीं आसान होता है
अगर Christmas lights की पूरी लड़ी नहीं जल रही है, तो एक-एक bulb बदलकर देखने वाला तरीका तब fail हो जाता है जब खराब bulb कई हों
इसके बजाय minimum working example से शुरू करके थोड़ा-थोड़ा जोड़ना चाहिए और वह बिंदु ढूंढना चाहिए जहां error आता है; असल में कई बार शुरुआत से फिर शुरू करना समय बचाता है
production की एक मुश्किल से पकड़ी जाने वाली समस्या में कुछ team members ने problematic routine फिर से लिखी थी, और बाकी लोग debugging कर रहे थे, तब rewrite वाला version पहले deploy हो गया
कम से कम एक बार, “ठीक हो चुकी” समस्या पर अनिश्चित समय तक नहीं लगाया जा सकता था, इसलिए original bug अंत तक मिल ही नहीं पाया
नियम 0 है: घबराएं नहीं
deadlines और नाराज customers साफ सोचने में बाधा डालते हैं, इसलिए एक भरोसेमंद अच्छा manager engineer को उस pressure से बचाए, तभी वे problem solving पर focus कर सकते हैं
एक अच्छे manager ने हमें दूसरी call पर move किया और कहा, “उन लोगों की बात ignore करो और focus करो, मैं संभाल लूंगा,” और उसके बाद उस manager के लिए मेरा सम्मान बहुत बढ़ गया
अगर आपके पास सही से करने का समय नहीं है, तो आपको क्यों लगता है कि दो बार करने का समय होगा
मतलब, ऊपर से गिरने वाली चीजों को रोकना ताकि engineers अपने असली काम पर focus कर सकें
working version पर वापस जाकर crisis-level pressure के बिना debugging कर सकें, तो यह कहीं बेहतर है
नंबर 4 “divide and conquer” में
git bisectबहुत मददगार हैअगर एक good commit है और उसके बाद के दर्जनों से सैकड़ों commits में कोई एक bad commit है, तो कुछ ही steps में problematic commit या code को narrow down किया जा सकता है
usage example https://nickjanetakis.com/blog/using-git-bisect-to-help-find... पर है
live consulting के दौरान एक अनजान बड़े codebase को इस तरीके से तेजी से narrow down किया, वरना टूटने की संभावित range बहुत बड़ी होती
git bisectकी वजह से “real” branch में जाने वाला हर commit individually build होना चाहिए, उस समय ज्ञात tests pass करने चाहिए, और जानकारी के हिसाब से deployable होना चाहिए—मैं इस discipline का पालन करता हूंहर keystroke को preserve करने या आखिरी “Fixes.” commit तक बचाए रखने वाले principles से मैं इसे ज्यादा important मानता हूं, क्योंकि वे principles binary search को बेकार बना देते हैं
इसे अक्सर इस्तेमाल नहीं करता, लेकिन सबसे बड़े और रहस्यमय bugs में एक बार भी सही hit हो जाए तो कई दिनों के clues एक साथ मिल जाते हैं, इसलिए इसकी कीमत पूरी निकल आती है
git bisectके पीछे का general principle बताया थायह तरीका है टूटे हुए system और काम कर रहे system की तुलना करना और differences को systematically eliminate करके defect ढूंढना
software या hardware के अलावा भी लागू किया जा सकता है; पहले जब मेरे पास एक जैसे दो jet skis थे, तो एक को ठीक करते हुए दूसरे से compare कर पाना अच्छा था
git bisectखुद नहीं, बल्कि ज्यादा general binary search principle हैइसका इस्तेमाल commit range के अलावा system space को divide करने में भी किया जा सकता है
उदाहरण के लिए, अगर 10-step workflow टूट गया है, तो जांच सकते हैं कि step 5 तक ठीक है या नहीं, या narrow down कर सकते हैं कि hardware issue है या नहीं
यह खासकर तब important है जब समस्या का कारण उस repository के code commit में न भी हो सकता हो जिसे आप अभी bisect कर रहे हैं
bisectबेहतरीन है, लेकिन इस किताब के philosophy और mindset यानी “rules” और practical advice यानी “tools” में फर्क करना चाहिएजो व्यक्ति “कौन सा tool इस्तेमाल करूं?” से शुरू करता है, वह “क्या यह पहले काम नहीं कर रहा था?” से शुरू करने वाले व्यक्ति की तुलना में नुकसान में होता है
दुनिया tools से भरी है, और अगर हर tool को दिमाग में store करने की कोशिश करेंगे तो पागल हो जाएंगे, इसलिए बेहतर है पहले philosophy अपनाएं
git bisect runपर लिखा एक लेख जोड़ रहा हूं। सचमुच कमाल का छोटा tool हैhttps://andrewrepp.com/git_bisect_run
यह पक्का करना चाहिए कि आप सही file को सही machine पर edit कर रहे हैं
आजकल मैं हमेशा temporarily एक line जोड़ता हूं जो fatal error कर दे, ताकि confirm हो सके कि अभी file सही है और situation के हिसाब से line भी सही है
ताकि confirm हो सके कि मेरा change सच में effect डाल रहा है
कुछ अतिरिक्त नियम भी हैं
“सब मेरी गलती है”: यह compiler bug या hardware error भी हो सकता है, लेकिन ऐसा बहुत दुर्लभ है, इसलिए सबसे पहले अपने code change पर शक करना चाहिए
“जब bug मिले, तो उसके परिवार और दोस्तों को भी खोजो”: सोचना और जांचना चाहिए कि इसी तरह की चीज़ और कहाँ हुई हो सकती है
“पहले users के लिए optimize करो, दूसरे नंबर पर maintenance programmers के लिए, और computer के लिए सबसे आखिर में”
सारांश https://blog.codinghorror.com/the-first-rule-of-programming-... पर है
आम तौर पर error देने वाले code को किसी और सरल case में घटाने की प्रक्रिया में अपनी logic का bug मिल जाता है
एक-दो बार सच में developer को report करने लायक नतीजा बचा, और अधिकतर वे ऐसी libraries थीं जिनके users कुछ सौ या उससे कम थे, इसलिए tests ज्यादा नहीं थे
आखिर में जब पता चला कि यह असंभव-सा दिखने वाला code error नहीं, बल्कि CPU issue है, तो बहुत राहत मिली
फिर भी cause-effect chain पर कुछ और बार binary search करके पक्का कर लेना सबसे अच्छा है
“System को समझो: manual पढ़ो, सब कुछ गहराई से पढ़ो, basics जानो, roadmap जानो, tools समझो, details खोजो” वाली सलाह कुछ अजीब लगती है
ऐसा लगता है मानो code में bug हो तो पहले इस्तेमाल की जा रही library का पूरा 700-page manual पढ़ो, संबंधित 7 किताबें पढ़ो, और एक-दो महीने बाद ही bug को देखो
उत्सुकता है कि क्या सच में कोई programmer इस सलाह का पालन करता है
Atwood और Spolsky ने Stack Overflow 2008 में बनाया था, और वह ऐसा दौर था जब लोग “Camel book” जैसे नामों से किताबों को जानते थे और बस ज्ञान रखते थे
0. https://stackoverflow.blog/2021/12/14/podcast-400-an-oral-hi...
“सब कुछ गहराई से पढ़ो” का मतलब जरूरी नहीं कि “पहले इस्तेमाल की जा रही library का पूरा 700-page manual पढ़ो” ही हो
अगर
git bisectमें समस्या है, तो Stack Overflow के कुछ टुकड़े जोड़ने के बजाय, https://git-scm.com/docs/git-bisect पर topic को थोड़ा और गहराई से समझा जा सकता हैलेकिन यह सोचना गलती है कि कई महीनों के काम का नतीजा सिर्फ एक bug को मोटे तौर पर ठीक करना है
लक्ष्य यह है कि उस तरह के जितने संभव हों उतने bugs सच में ठीक किए जाएं, और वे शुरू में लिखे ही न जाएं
विकल्प यह है कि किसी अज्ञात system में parachute की तरह उतरें, बिना समझे इधर-उधर छेड़छाड़ करें, tests green हो जाएं तो PR भेज दें और उम्मीद करें कि ज्यादा खराब नहीं किया—ऐसा काम रोज करना लगभग nightmare जैसा है
इसके अलावा, अगर इस्तेमाल की जा रही library का manual 700 pages का है, तो शायद गलत library इस्तेमाल करने की संभावना बड़ी है
10वें step के रूप में, bug को CI test में जोड़कर regression रोकना नहीं चाहिए क्या
fix से पहले CI fail हो और fix के बाद pass हो, यह verify करना चाहिए
खासकर इसलिए क्योंकि 5 साल से भी पुराने commits थे, और component/library होने के कारण IE के लिए काफी अजीब hacks भी थे
कुछ tests लिखने में समय लेते हैं या complex होते हैं और maintenance भी चाहिए होती है, और यह भी स्वीकार करना पड़ता है कि test suite सभी boundary conditions check नहीं कर सकता
इसका मतलब हो सकता है कि production तक गया bug फिर आ सकता है, लेकिन अगर यह simple mistake थी, तो शायद वह सैकड़ों अन्य संभावित mistakes से ज्यादा दोबारा होने की संभावना नहीं रखती
आखिरकार यह situation पर निर्भर करता है, और test लिखना free नहीं है
मैंने अनगिनत बार देखा है कि deeper cause फिर सक्रिय होकर वही समस्या दोबारा पैदा कर देता है, या किसी को पता ही नहीं होता कि मैंने fix कर दिया है और सभी लोग bug अभी भी मौजूद समझकर workaround इस्तेमाल करते रहते हैं
“ठीक हो गया!” तक पहुंचने के बाद भी एक छोटा record और root cause analysis छोड़ देने से दूसरों को मदद मिलती है
tests लंबे समय तक जमा होने के बाद CI कितनी तेजी से चल सकता है, और long term में उन्हें बनाए रखना क्या अब भी meaningful है
अगर आप बच्चों में, खुद में, या दूसरे लोगों में ऐसी सोच डालना चाहते हैं, तो कम से कम ये सुझाऊंगा
The Martian by Andy Weir https://en.wikipedia.org/wiki/The_Martian_(Weir_novel)
https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_...
https://en.wikipedia.org/wiki/The_Three-Body_Problem_(novel)
To Engineer Is Human - The Role of Failure in Successful Design By Henry Petroski
https://pressbooks.bccampus.ca/engineeringinsociety/front-ma...
https://en.wikipedia.org/wiki/Surely_You%27re_Joking,_Mr._Fe...!
खासकर “gumption traps” का concept अच्छा है
अगर आप value rigidity के trap में फंस गए हैं, तो वैसे भी आप धीमे पड़ेंगे ही, इसलिए जानबूझकर रफ्तार कम करनी चाहिए, जहां से गुजर चुके हैं उसे फिर से देखना चाहिए, और जांचना चाहिए कि जिन चीजों को आपने महत्वपूर्ण समझा था वे सचमुच महत्वपूर्ण थीं या नहीं
बस कुछ देर machine को देखना भी गलत नहीं है; और यह पंक्ति कि अगर आप उसे मछली पकड़ने की डोरी की तरह देखते रहें, तो कोई छोटा-सा तथ्य सावधानी से आपसे पूछने आएगा कि क्या आपकी दिलचस्पी है, जिंदगी के मार्गदर्शन जैसी लगती है
मुझे लगता है घटनाएं बस बड़े-बड़े logical leaps के साथ घटती चली जाती हैं, और असल में यह बहुत पतले science wordplay से ढकी fantasy के ज्यादा करीब है
कुछ साल पहले मैंने इसी तरह का एक लेख लिखा था। यहां जिस मूल किताब का जिक्र है, उसे मैंने तब नहीं पढ़ा था
https://explog.in/notes/debugging.html
Julia Evans की debugging zine भी बहुत अच्छी है: https://wizardzines.com/zines/debugging-guide/
सफलतापूर्वक debugging करने के बाद भी काम खत्म नहीं होता
“Three Questions About Each Bug You Find” <http://www.multicians.org/thvv/threeq.html> का सार तीन बातों में है
क्या यह गलती कहीं और भी है, इस bug के पीछे छिपा अगला bug क्या है, और ऐसे bugs रोकने के लिए क्या करना चाहिए