阅读笔记靠“巧合”编程？

本文主要是介绍阅读笔记靠“巧合”编程？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

你有没有看过老式的黑白战争片?一个疲惫的士兵警觉地从灌木丛里钻出来。前面有一片空旷地那里有地雷吗?还是可以安全通过?没有任何迹象表明那是雷区——没有标记、没有带刺的铁丝网、也没有弹坑。士兵用他的刺刀戳了戳前方的地面，又赶紧缩回来，以为会发生爆炸。没有。于是他紧张地向前走了一会儿，刺刺这里，戳戳那里。最后。他确信这个地方是安全的，于是直起身来。骄傲地正步向前走去，结果却被炸成了碎片。
士兵起初的探测没有发现地雷，们这不过是侥幸。他由此得出了错误的结论——结果是灾难性的。

传统智慧认为，项目一旦进入编码阶段，工作主要就是机械地把设计转换为可执行语句。我们认为，这种态度是许多程序丑陋、低效、结构糟糕、不可维护和完全错误的最大一个原因。

编码不是机械工作。如果它是，20世纪80年代初期人们寄下厚望的所有CASE工具早就取代了程序员。每一分钟都需要做出决策——如果要让所得的程序享有长久、无误和富有生产力的“一生”，就必须对这些决策进行仔细的思考和判断。

不主动思考他们的代码的开发者是在靠巧合编程——代码也许能工作，但却没有特别的理由说明它们为何能工作。我们提倡要更积极地参与编码过程。

尽管我们编写的大部分代码能够快速执行，我们偶尔也会开发出一些算法，可能会让最快的处理器都陷人困境。在”算法速率”中，我们将讨论估算代码的速度的方法，并且还给出一些提示，告诉你怎样在存在问题发生之前就发现它们。

注重实效的程序员批判地思考所有代码，包括我们自己的。我们不断地在我们的程序和设计中看到改进的余地。在“重构”中，我们将讨论一些即使我们还处在项目中期，也能帮助我们修正现有代码的技术。

只要你在制作代码，你就应当记住，有一天你必须对其进行测试。要让代码易于测试，这样你将増加它实际通过侧试的可能性。

最后我们建议你小心那些替你编写大量代码的工具。除非你理解它们在做什么。我们大多数人都能够近乎自动地驾驶汽车——我们不用明确地命令我们的脚踩踏板，或是命令我们的手臂转动方向盘——我们只是想“减速并右转”。但是，可靠的好司机会不断查看周围的情况、检查潜在的问题、并且让自己在万一发生意外时处在有利的位置上。编码也是这样——它也许在很大程度上只是例行公事，但保持警觉能够很好地防止灾难的发生。

作为开发者，我们也工作在雷区里。每天都有成百的陷阱在等着抓住我们。记住士兵的故事，我们应该警惕，不要得出错误的结论。我们应该避免靠巧合编程——依靠运气和偶然的成功——而要深思熟虑地编程。