Lesson 24 / الدرس 24

Debugging as a method / التنقيح منهجًا

Finding a bug is a search, and searches have techniques. The difference between two hours and ten minutes is almost never knowledge of the language — it is whether you halved the search space or guessed at it.

إيجاد الخلل بحث، وللبحث تقنيات. والفرق بين ساعتين وعشر دقائق ليس معرفة اللغة تقريبًا أبدًا — بل هل نصّفت فضاء البحث أم خمّنته.

Reproduce, halve, repeat

1. REPRODUCE   make it happen on demand. no reliable repro, no debugging.
2. NARROW      cut the input, the code or the history in half. test. repeat.
3. OBSERVE     print or breakpoint the value. do not reason about it — look.
4. HYPOTHESISE one sentence: "X is wrong because Y". then test THAT.
5. FIX & PROVE change one thing. show it works. show it failed before.

The demonstration is a broken function and a bug you have to find. Do it by guessing first if you like; then use the halving buttons and count how many steps it takes. Twelve candidate lines and four questions is not a coincidence.

Halving is the whole trick

A thousand lines, halved, is ten tests. The same idea works at every scale: comment out half the function, remove half the input, disable half the plugins, or — the most powerful version — halve the history. git bisect takes a commit where it worked and one where it does not, checks out the middle, and asks you to test; ten answers finds the exact commit among a thousand. That turns "when did this break?" from an argument into a mechanical procedure, and it works even in code you have never read.

وألف سطر، منصَّفة، عشرة اختبارات. والفكرة نفسها تعمل على كل مقياس: علّق نصف الدالة، أو احذف نصف المدخل، أو عطّل نصف الإضافات، أو — أقوى صورها — نصّف التاريخ. فـgit bisect يأخذ التزامًا كان يعمل وآخر لا يعمل، ويسحب الأوسط، ويطلب منك الاختبار؛ وعشرة أجوبة تجد الالتزام بالضبط بين ألف. وذلك يحوّل "متى انكسر هذا؟" من جدال إلى إجراء آلي، ويعمل حتى في شيفرة لم تقرأها قط.

Instead of	Do	Because
Reading the code again	Print the value	Reading shows what you meant; printing shows what is
Changing three things	Change one, test, repeat	Three changes and a fix teaches you nothing
"It should work"	"It does not, so one of my beliefs is wrong"	The bug is always in an assumption
Debugging on the full input	Shrink it until removing anything hides the bug	Small inputs make the cause obvious
Wondering when it broke	git bisect	Ten answers among a thousand commits
Fixing it and moving on	Write the failing test first	Otherwise it comes back in six months

The third row is the one that matters most. Every bug is a place where the program disagrees with something you believe about it, and the fastest way to find it is to hunt for the belief rather than for the bug. "This value is never null." "This runs before that." "That parameter is a number." One of those sentences is false.

Two tools worth the afternoon it takes to learn them. A debugger — Xdebug for PHP, the browser's own for JavaScript — lets you stop on a line and look at every variable at once, step forward, and walk back up the call stack; it replaces twenty print statements with one breakpoint and shows you things you did not think to print. And logging is the debugger for problems you cannot watch happen: a line written at the right moment, with the values in it, is how you debug something that only fails at three in the morning on somebody else's phone.

Try it live / جرّب بنفسك

<h1>Bug log</h1>

<h2>Reproduction</h2>
<p>Steps: …</p>
<p>Smallest input that still shows it: …</p>

<h2>Narrowing</h2>
<ol>
  <li>Tested … → eliminated …</li>
  <li>…</li>
</ol>

<h2>Hypotheses</h2>
<ol>
  <li>“…” → tested by … → wrong/right</li>
</ol>

<h2>The fix, and the test that proves it</h2>
<pre>…</pre>

<h2>Steps taken: method __ vs guessing __</h2>

Preview / المعاينة

Check yourself / اختبر نفسك

1. Why is reproduction the first step?

2. What does git bisect give you?

ماذا يعطيك git bisect؟

3. Where is a bug always found?

Your task / مهمتك

Take a bug from your own code — or plant one in a program of at least sixty lines and have somebody else run it — and keep a written log as you find it: the reproduction, every narrowing step with what it eliminated, each hypothesis and how you tested it, and the fix. Count the steps. Then do the same bug again from scratch by guessing, and compare the two counts. Finally, use git bisect on a real repository to find the commit that changed some behaviour, and write down how many tests it took.

خذ خللًا من شيفرتك — أو ازرع واحدًا في برنامج من ستين سطرًا على الأقل ودع غيرك يشغّله — واحتفظ بسجل مكتوب وأنت تجده: إعادة الإنتاج، وكل خطوة تضييق وما استبعدته، وكل فرضية وكيف اختبرتها، والإصلاح. وعُدّ الخطوات. ثم افعل الشيء نفسه من الصفر بالتخمين، وقارن العددين. وأخيرًا استخدم git bisect على مستودع حقيقي لإيجاد الالتزام الذي غيّر سلوكًا ما، واكتب كم اختبارًا لزم.

A reliable reproduction, written down إعادة إنتاج موثوقة مكتوبة
Every narrowing step and what it eliminated كل خطوة تضييق وما استبعدته
The method and the guessing compared by step count المنهج والتخمين مقارَنين بعدد الخطوات
A real git bisect run, with the number of tests تشغيل git bisect حقيقي بعدد الاختبارات