Fix a bug as soon as you spot the problem?
Well, if you can fix a bug, yes.
But normally you'd like to think about the problem, whether you can generalize it,
find about the best place to fix, reason about it until you have a very good diagnosis,
so this is definitely not true.
Always keep all details in your head.
Well, the name of the last part was "Explicit Debugging,"
so you should not always try to keep all details in your head. This is wrong.
Explaining the problem can be helpful. Yes--plenty of anecdotal evidence for that.
And finally, up to 50% to 70% of software development effort
is spent on validation and debugging.
This is also true, and this is something we really, really, really must change.
Sistemare un bug appena individui il problema?
Beh, se puoi farcela a sistemarlo, si'.
Ma di norma e' preferibile che pensi al problema, a come generalizzarlo,
trovare il punto migliore da sistemare, ragionarci su finche' non trovi un'ottima diagnosi.
Quindi questa non e' assolutamente giusta.
Tenere sempre i dettagli a mente?
Beh, il titolo della parte precedente diceva "Debugging Esplicito",
quindi non dovresti mai tenere tutti i dettagli a mente. Questa e' sbagliata.
Spiegare il problema potrebbe essere utile? Si' -- c'e' un mucchio di aneddoti che lo provano.
E, infine, fino al 50-70% dello sviluppo software
e' impiegato in verifiche e debugging?
Pure questa e' vera e questo fatto deve davvero, davvero, davvero cambiare.
バグを見つけたらすぐに修正する
もしすぐにバグを修正できるのならそうしてください
しかし一般的には一体何が問題なのかを考えるでしょう
修正が必要な場所を見つけたいですし バグが特定できるまで試行錯誤します
そのためこれは違います
頭のなかで全部覚えておく
先ほど系統的デバッグを学びました
ですからすべてを記憶しておく必要はありません
問題を説明してみる 正解です これは実証されています
ソフトウェアの開発の50％から70％の労力を
妥当性の検証とデバッグに費やす
これも正解ですが 変えていかなければならない習慣ですね
能否在你出错时立刻就发现BUG呢？
如果你可以修正这个 BUG的话，就可以做到。
但是正常情况下，你还是要好好琢磨下，能否归纳下，
找出修正的最佳地方，不断推理直到你得到一个好的论断。
所以上面的那个问题就不能回答 可以。
总在你脑中保存所有细节。
上一节的名字是“笔记调试”
所以你不要去试着全用脑袋去记。这是错误的做法。
解释一遍问题会有用。会找到很多线索。
最后，50%到70%的开发工作
其实是花在了验证和调试上。
这是真的，这是我们一定要克服的问题。