第6章:当你编码时
本章主要讲在编码时应该注意的各类事项。传统智慧认为，项目一旦进入编码阶段，工作主要就是机械的把设计转换成可执行语句。我们认为，这种态度是许多程序丑陋、结构糟糕、不可维护的最大一个原因。编码不是机械工作，要想让程序长久无误的运行，每一分钟都需要做出决策，且需要对这些决策进行仔细的思考和判断。
1.靠巧合编程
靠巧合编程即代码正好是可运行的，至于为什么能够正常运行，却不清楚。这是我们应该极力避免的。如何深思熟虑的编程，有几条建议:总是意识到你在做什么。按照计划（设计）行事。依靠可靠的事物而非假设。不要只是测试你的代码，还要测试你的假定。不要让已经做完的事情限制你的下一步，做好重构的准备。
2.算法效率
注重实效的程序员几乎每天都要使用估算，估算的资源包括：时间、处理器、内存等等。不同的时间复杂度在达到一定数量级的时候将相差很多，所以某些情况我们要想方设法优化算法的效率。我们主要需要关注的是是复杂度的阶。在确认了算法之后，还需要对其进行测试。最好的并非总是最好的，是否使用最优算法，还需要根据我们遇到的实际情况。有时数据量很小的情况，算法的效率是可以忽略不的。
3.重构
重写、重做和重新架构代码合起来，称为重构。当代码出现以下特征，就应该考虑重构了：出现重复内容，违反DRY原则。非正交的设计。知识过时了，或者你对某部分的了解更深一步。对性能造成了影响。
重构的原则：早重构、常重构。重构面临的敌人通常都是时间，但这个借口并不成立，因为之后由此引发的时间额外消耗很可能更多。
如何重构：不要试图在重构的同时增加功能。重构之前，确保拥有良好的测试。采取短小，深思熟虑的步骤，不要一次改动太多内容。
4.易于测试的代码
软件 IC 是人们在讨论可复用性和基于组件的开发时喜欢使用的比喻。意思是集成电路芯片可以很容易的进行组合，我们希望软件开发也能达到这个效果。芯片的设计有完善的测试，同样的软件开发也可以做同样的事情。
针对合约进行测试及为测试而设计，即 TDD 测试驱动开发。
编写单元测试，对比较大的项目，将每个测试都放进一个子目录。
使用测试装备。构建一套完善的测试体系，它能够记录测试状态，分析输出结果是否符合预期，以及选择和运行测试。
推进测试文化，尽可能完善地测试你的软件，否则你的用户就得替你测试。
5.邪恶的向导
这里的向导指的是那些用于帮助我们构建程序自动生成的代码，通常他们还被称为脚手架。为什么称向导（wizard）是邪恶的呢，这是因为通过工具生成的代码，很容易被我们忽略，在这种情况下你编写的过程更倾向于靠巧合编程。
这里不是抵制向导代码，而是在强调，不要使用你不理解的向导代码。如果使用，一定要清楚它的机制。
开发每天都在使用不完全理解的事物，比如集成电路的工作原理，处理器的中断结构、用于调度的算法、各种系统库的工作机制等。需要注意的是，这些属于底层依赖，他们也是向导，但不是应用本身的一部分，我们可以对这部分有所了解，但他们不属于邪恶的向导。
标签：读后感,重构,小工,编程,向导,程序员,算法,测试,代码 From： https://www.cnblogs.com/ysk0904/p/16995564.html