周末应该用来看书和学习，而不能用来加班。如果周末也用来工作，那什么时候才能学习呢？正如章老师所言，不学习会导致平时的效率低下，效率低下又导致了没有学习的时间，然后进入了恶性循环。如何才能打破恶性循环？一是抓紧周末的时间赶紧学习，只有周末加油积累，才能厚积薄发，在平时工作中进行输出。二是提高平时的工作效率。总之这两条真是说的简单做着难，幸好第一条还是能做的。
工作中遇到了很多的痛点和困难，很多时候不理解为什么原有的系统要设计成那样，有些地方明明可以做的更好，分离抽象的层次，把一些共性的实体抽象出一个基类，会不会有个更好的扩展性？那些书上经常强调的设计原则，有时候我很奇怪是否在工作中还被提倡甚至是否被作为一种可以量化的考评指标呢？
痛点还有中台。系统对接了好多中台，但是中台提供的功能并不能让业务端满意。一些本该封装起来的操作，并没有由中台进行封装，业务端感知了太多不必须的信息，是否又破坏了封装性呢？经常会怀疑是否为了中台而中台，对接了一些本来不适合业务的中台。
这周还收获了一些很有意义的书籍。包括一些英文原版书。比如 章老师推荐的《如何阅读一本书》，以及《敏捷软件开发——原则模式与实践》，开卷有益，打开书之后我会感慨，嗯，这就是我想要看到的，这就是我在追寻的问题的答案。
好了，先逼逼到这里吧~ 下面是正式的内容，主要来自《代码整洁之道》的第十七章 味道与启发 的读书笔记
极限编程提倡尽量少的注释和文档。应该由尽量完善的单测补足注释和文档的作用。这一点我认为是很有道理的。首先为什么需要尽量少的注释和文档？因为注释和文档，都是代码的“影子”，代码的含义不仅要在代码中维护，也要在注释和文档中进行维护。当代码变更的时候，还要去更新注释和文档，这是额外的工作量。如果某个成员忘记更新注释和文档，那对于其他成员，尤其是项目的新成员来说，就是一个大坑。但是如果使用单测来补充注释和文档的作用，情况就会大不相同了。因为单测是必须随着代码更新的，每一次代码的更新和修改，都需要运行单测，使所有单测全部运行通过。所以单测总是最新的一份“文档”。另外，单测使用的是代码的方式，测试和调用开发代码，对于程序员来说，可能比文档中的信息更加具体和直接。
总体上说，注释应该解释的是代码的目的，而不应该关注代码的实现细节。所有跟细节相关的信息，应该由代码本身进行说明，也就是我们说的，代码应该是自解释的。如果觉得代码解释不清楚细节，那么就说明代码应该被重构了（很可能是代码中的命名不够合适）。
另外，注释也可以关注复杂的逻辑和算法，简单地说明一个复杂的算法是如何实现的。
这一部分可以参考《代码整洁之道》的第四章
对于代码的变化，请让源码控制系统（如git）等去追踪，而不是将代码注释起来。
注释只应该描述有关代码和设计的技术性信息
不要让注释成为孤岛，遇到废弃的注释应该立即更新或者删除。
注释应该描述代码没有提到的东西
写注释要字斟句酌，别闲扯，别画蛇添足，保持注释的简洁。
删除掉注释的代码
对于maven项目，只需要运行mvn test 命令，就可以执行全部的单元测试。
函数的参数应该尽量少
输出参数常常违反直觉
布尔值参数大声宣布了函数做了不止一件事，应该被消灭掉。
永远不会被调用的方法应该被丢弃。别害怕删除
这个实在是令人难受
违背了“最小惊异原则”，相当于给自己和同事挖坑，而且看到之后会让人费解。
如果明显的行为未被实现，读者和用户就不能再依靠他们对函数名称的直觉，他们不再信任原作者，不得不阅读代码细节。
别依赖直觉，追索每种边界条件并编写测试。
这种情况在我厂要么被扫出漏洞，要么要修复安全工单。
这是《代码整洁之道》中最重要的原则之一。这个原则也被称之为DRY原则（Dont Repeat Yourself）
每看到重复代码，都代表遗漏了抽象。将重复代码放入抽象中，其他程序员就可以用到你创建的抽象设施。编码会越来越快，错误也会越来越少，因为你提升了抽象的层级。
不断重复出现、检测同一组条件的switch/case或者if/else链，可以用多态来代替。注：模板模式，工厂模式 + 多态
更隐蔽的重复的形态是采用类似算法但是具体代码不同的模块，这也是一种重复，可以使用模板方法模式或者策略模式进行修正。
孤立抽象是软件开发者最难做到的事情之一，而且一旦做错了也没有快捷的修复手段。
创建分离较高层级的一般性概念与较低层级的细节概念的抽象模型是很重要的。有时候我们创建抽象类来容纳较高层级的概念，用派生类容纳较低层级。这种情况下，与细节实现有关的函数、变量和常量等，不可以出现在抽象类中，抽象类应该对此一无所知。
原文：https://www.cnblogs.com/dudu19939/p/12439598.html