接上一篇。
注重时效的程序员应该不断学习，我们都应该不断的学习下去。
能不能让正确的原则指导正确的行动本身，其实就是区分是否是高手的一个显著标志。而这些原则通常都是以“秘籍”的形式存在于各大论坛、博客等之中，当我们看到前辈们的经验之时，受限于自身的眼界、所处的环境等，得到的知识可能并没有提出之人印象那么深刻，教训那么惨烈。正如你并不知道双11,淘宝交易1207亿系统所承受的到底有多少事件，或许我们在惊叹国人义无反顾剁手的同时，真的该思考思考如何做到的呢。
如何将前辈们的“秘籍”吸收，少走弯路，提升自身的能力，关键是要内化。我们常常会“忘了”（理论上接触个这个，但是没有场景）应该怎么正确地做一件事。这个时候，如果突然有个小声音跳出来说：嘿，你是不是该遵循这个原则，用这个方法？当然，我们更加感兴趣的是，自己发出这样的小声音。
正如鲁迅当年书桌上那个“早”字，我们应当学会抽象出简单的词句和规则，靠记忆和不断的重复、提醒，原子化的内化这些小声音。让自己处于知识的敏感阶段。能够时刻跳到耳边，提醒自己。当然还需要必要的实践，如果没有实践，没有见这些小声音转化为自己的东西，即使你把它写在了100元的笔记本上也是没有用的。前人经验往往并不能告诉我们什么一定是对的，但是可以告诉我们什么一定是不对的。这本书中提到：我们要有这样的意识：你不可能写出完美的代码。只要随手翻翻自己的写的代码，就会发现我们内嵌了好多“假设”，假设用户使用了windows系统，假设用户看得懂......这些假设都会导致问题。因此，完美是相对的，仅适应于某个场景、某个具体的时间段。
我们需要尽一切努力编写尽可能宽松--灵活--的代码。一切关于时间的假设都需要注意。
生活不会停止不前，我们编写的代码也不会。保持灵活的代码是少写代码。这里面提到了一个新的概念--时间耦合，挺新鲜的。它是关于时间的。两个方面：并发（事情在同一时间发生）和次序（事件在时间中的相对位置）。我们在编写程序的时候，往往是线性的。先编写这个，再处理那个。这样就会导致时间上的依赖。事件B在事件A之后才执行；同时只能运行一个报告；在接收到按钮点击之前，你必须等待。为了减少时间上的依赖，我们要分析工作流，改善并发性。我们在接受任务时，可以尝试着考虑哪些是可以并行的，哪些必须依赖前一个事件。做设计时在画UML图的时候，都可以尝试着在时间上解耦，让效率提高。写到这里突然想到一句话:好多规则都是人为制定的，时间也不例外。
注释是代码表述的最后选择。
注释是帮助我们理解代码逻辑的助手，好的注解可以帮助我们理解代码里的逻辑构造，帮助维护的人更快速的定位到问题。但是注释一定要写吗？ 其实但在大多数情况下是可以避免的，我们可以选择用更好的命名方式来取代它。只有在用命名方式都无法清楚的描述某个方法或者变量的时候，注释才是最后的选择。也难怪sonar中会要求把注销的部分去掉。虽然一般情况下，注释是非常有用的，但是也存在着误导的风险。当代码更新或者相关逻辑更新时，与更新相关的注释常常会得到不同样的更新，这就导致了这些注释变得非常危险。
最后，写代码应该成为一种乐趣。
