最近在看《A Philosophy of Software Design》，总结和记录一下读后感。顺便长期维护一下这个文章，将自己在编码过程中常出现的一些错误总结起来。

本书主要是在讲解一些开发中不好的coding习惯或者方法，以及如何去避免和解决这些问题。书中主要提及了两个概念：dependency 和 obscurity。dependency回导致change amplification和cognitive load。而obscurity会导致cognitive load和unknown unknowns。所以开发中都是在避免这两个特性出现，而他们的具体表现则是下面列举的一些场景。

  1. Tactical Programing

    在开发过程中，很多时候我们会急于去完成需求，从而忽略了如何写出更好的设计的代码，但是如果是一个长期需求维护的需求，越到后面，前期因为tactiacl programming带来的副作用就会越来越明显，甚至到最后不得不重写或者花很大的力气重构代码。

  2. 过度封装（shallow module）

    封装的原则是高内聚、低耦合。对外的接口要尽可能的少，同时不要对一些简单功能去封装一层函数或者类，这样会导致在看代码的时候返回查看封装的代码，看代码的流畅感会被阻断。但是对一些复用性很高的方法和类的封装还是很有必要的。

  3. 不写注释或者注释复述代码

    不写注释的都是坏蛋。注释是去阐述一段代码是做什么的，而不是怎么做的。所以，注释不要去解释代码是怎么执行的，读代码的人会自己去看代码是如何运行的。注释只需要给需要用到这段代码讲清楚这段代码是干嘛的就好了。

    代码不动，注释先行。先写注释，可以整理开发思路，给后续写代码提供一个整体的思路。而且在开始的时候就把重要的方法和变量的命名给定下来。

  4. 命名模糊

    命名要满足这些：

    能够让自己和其他人对这个命名能够清晰的概念在。知道这个变量或者方法是干什么的。

    命名不要含糊不清，要表达的精确。如何你不知道如何去命名，那么可能你还没有弄清楚这个变量或者方法需要完成的是什么。这个时候，你可能需要去将这个模糊的概念再去细分，直到能够细分出来的东西都有一个精确的命名。

    同时，命名要坚持从一而终。不要一会用这样的名字，一会儿用一个名字。比如标签，不要一会儿起tag，一会又叫label，这样会很混乱。或着弹窗的展示都叫popupVisible，就不要再用什么shouldShowPopup。要有统一的命名规范。