继续阅读程序员的修炼之道这篇文章，主要还是从那几个老生常淡的问题中得到一些启发，就比如说温水煮青蛙的例子让我们要持续不断地观察周围发生的事情，而不仅仅是自己在做的事，尤其是项目的管理者必须要实时的掌控项目的方向，因为大多数项目失去控制都不是一下子就发生的，而是慢慢地，不可改变的完全失去控制的。可能是系统一个特性一个特性的偏离了规范，项目进度一点一点的拖延。这种情况下如果是作为个人还是管理者都不应该容忍规范的违背，每天、每周都需要审视自己，审视团队，及时纠正问题，纠正团队的方向。我觉得我自己就缺乏对于周围事情及时的洞察，之后我在保障自己技术进步的同时，还要多和其他人作比较。
贯彻全书的一个原则是DRY(Don‘t Repeat Yourself)原则，这也是每个优秀的开发人员必须要遵循的规范，编码过程中任何地方都不要重复，因为重复暂时节省的时间将会给以后的维护使用带来巨大的麻烦，如果发现代码有重复或者违反正交性等原则的地方要立刻找机会重构。这样才能够拥有更快、更好、更强健、更优雅的代码。我在上学期编写代码的时候在删除的时候就先会查找，我这里通常会用一个getbyname的方法，搜索也是另写，这就是一个功能的冗余，我以后在编程的时候尽量提前将这个程序进行规划。
然后是关于文档和测试，看过一个段子这样说的，一个程序员最讨厌的事情有两件，一个是别人写代码不写文档，另一个是别人让自己写文档。从这可以看出文档和测试一直是程序员的最大的敌人之一，我个人在这方面习惯也不是很好，虽然会去写文档，但总是觉得编写文档和单元测试集成测试等会影响自己的产出，但在时间允许的情况下这才是对项目最大的负责，也希望每个团队的管理员都能更有先见之明，不要太过于压缩开发阶段的时间，这样才有助于编写更好的文档和单元测试，才会在后面的阶段更省时省力。所以我会在之后自己编程的时候多加入注释，这样才可以增加代码的可读性。
接着是耦合这个词基本在我的职业生涯中每天都能听到，一个好的程序一定是低耦合的，这本书提出了函数的德墨忒尔法则帮我们更好的界定耦合的边界，怎样编写低耦合的代码，更难能可贵的是这本书不仅仅描述了一般的代码耦合，还花了很大笔墨解释了时间耦合，很多时候一个业务的实现没有必要一定是线性的，它可以是并行的，这在适用的情形下往往能在提高用户体验的同时还能降低系统的并发压力。