《程序员修炼之道:从小工到专家》前三章读后感

   注重时效的哲学

在本章节中，放在首位的就是教导一个具有实效性的程序员应该做到负责，能为自己的成功自豪，就该为自己的失败而诚实坦率地负责。不要在失败后寻找借口，而应该在失败前寻找方法。条条大路通罗马，我们应该在事先考虑到可能出现的意外状况，设计应急方案或者主动寻求帮助。程序员要做的是积极主动发散性地面对，而不是单一的推脱。在开发过程中，软件工程是一个相当庞大繁复的工程，为了保证项目的完成，我们要时刻保持着让软件接近完美的心，这样才更能够避免“破罐子破摔”的现象。与此同时，时刻保证代码的整洁完美，也会让团队保持高昂的士气，也更愿意为项目添砖加瓦。而完美并非自己定义的，不要时刻追求自认为的完美，而让工期无限延长，“今天的了不起比明天的完美更好”，我们应该做到尽力完成客户的基础需要即可，绘画过程中过度的涂改会导致画布作废，编程也是一样。最后两个章节介绍的是对知识财产的管理和交流。IT行业是迭代快速的行业，我们应该时刻注意知识的迭代，要永于学习那些新知识，因为这就像投资一样，谁也不知道你学习的下一项新兴技术会不会成为下一个潮流。而交流对程序员是不可或缺的，而程序员也往往缺乏的方面。交流对于我们理解客户需求等方面都非常重要。书中也介绍了交流几个技巧，比如注意交流时机，善于倾听和适当提出自己的观点等。
注意实效的途径
在该章节中，提到了避免重复性，和保证正交性。这两个方面都是程序员常常面临的问题。在我看来这两个都对应着编码的规范化，便于软件的区块化，维护和更新，bug的修复。 未来像一个装满无限可能性的盒子，你永远不知道，你的最终需求从这个盒子出来时是什么鬼样子，所以，代码就更加需要区块化和独立化，以防止需求变更导致的前功尽弃。再之后，提到了曳光代码和原型，在面对不熟悉的业务场景时，我们可以先完成曳光代码或者构建原型，以此来展示给客户一定内容，并为项目开发找到方向。然后提到了领域语言。每个语言有自己的逻辑，而使用这些语言的人，也会不可避免地接近这种逻辑的方式去思考。对于项目中的问题来说，不同的问题可能需要不同的逻辑来解决更高效。所以，要为项目寻找合适的语言。最后一个小节讲述的是估算的问题。一个程序员要善于估算，一个在项目中使用曳光代码和原型的程序员要更习惯于并善于使用估算，而本章节讲述的很多东西，也都是在促进估算的完成。估算也有技巧：对于不同的业务场景，使用合适精度范围的估算。
基本工具
本章节第一个小节就在教导程序员工具相关的问题。一个优秀的程序员应该保持自己的进步。而这种进步不应该只是个人意义上的进步，也包含工具的进步。工具应该成为我们的延伸，放大我们的才干，帮我们更高效地完成自己的工作。第二个小节则是提到了纯文本的优缺点，当然，更侧重优点。纯文本固然会让程序更大和更慢，但与此同时，带来了更大的优点，比如：保证不过时，杠杆作用和易于维护的特点。它可能会影响单个程序运行的效率等，但从程序员的职业生涯上看，可读性的优点，会给程序员带来大得多的收益。再之后介绍了shell命令窗口，作为一个立志实效的程序员，我们有必要学习shell命令，因为它能帮助我们最大限度地调用我们的工具，而如果单单依赖IDE，一些不常用的操作会让我们相当头疼。下一个介绍的工具是源码控制，幸运的是，现在的IDE中很多有操作日志的功能，这让我们得以回到程序还能运行，尚未被改的面目全非的状态。善用操作日志，就像有了后悔药一样，可以更加勇敢的尝试。下一小节则是讲述调试，几乎所有程序员，至少我自己讨厌调试，bug往往出现在那些不可能出现的地方，以至于我们常常惊叹“这也能报错”。文章提到我们应该尽量保证心平气和地进行调试，并且时刻跟踪bug，而不是bug日志。因为bug日志可能有缺漏，但bug就是bug，我们要看到bug和它的范围扩展，进一步去完全解决它。最后两个小节介绍的是文本控制器和代码生成器，这两者我只接触过IDE上的代码自动生成功能，也没什么好讲述的，正如标题，在我理解，他们只是一些好用的工具