今天给3个月前的项目拓展功能，尽管自认为自己在组织代码上进步了不少，
但改起3个月前的东西来，还是让我想起梁静茹的歌： 会呼吸的痛
这块代码动不了，那块代码也动不了，wtf，这个是干嘛用的？？
最后还是要靠全局搜索
1.承担太多逻辑的字段
item.link='/xxx/xxx'我有一个字段link，
对于不同的item，link里存的东西是不一样的，
所以每次都要判断item的类型，才能知道link是用来干什么的
而且对应规则还很复杂，令人抓狂
从命名的角度来说
link这个名字并不能描述这个属性所代表的含义，
link没有意义，
这个字段叫做 aa，bb，dog，cat 都可以，反正跟含义没关系
从逻辑设计来说
这个属性承载的信息太多，用了太多if判断，
一个字段只能走一个专一用途，
极端一点来说，你可以把所有信息写在一个字段里，
那就跟写秘密报文一样了，保证你自己都看不懂
2.遥远的呼应、隐藏的规则、晦涩的表达
无法，或者暂时无法在代码中表现的，
要写在组件的readme里面，
比如 和服务端达成的一些协议和规则，
某些因为权宜之计形成的、难以理解的晦涩的潜规则，比如那个link
另，
代码自己就会说话，
行内注释、readme一定要惜墨如金，
能不写的尽量别写，能用代码表达的就别写注释，
不然都是冗余信息，自己都懒得看
数据结构与逻辑
数据结构(这里指逻辑结构)和代码，是表达信息的关键，
信息的解码过程要相对简单，
1.检查数据结构
字段的命名
难以命名的时候，判断是否是因为这个字段承担的功能太过复杂
2.检查逻辑
确保每一个if、每一次赋值、每一次循环
都有一个对应的属性名、变量名或者函数名来说明为什么要这么做