读《程序员应该知道的97件事》笔记

1技术债务和童子军规则

技术债务
当你发现必须在“干得好”和“干得快”之间做出抉择的时候，一般都会选择“干得快”，并提醒自己将来再来返工。下一轮迭代自有其新的问题，工作重点转移到新问题上，老问题还存在。
Martin Fowler把它分成：蓄意和无意
把技术 债务立即记录到任务卡上，在恶化前偿还。
无论你承诺了什么，都得小心处置，顾及后果，尽快偿还你的技术债务吧，否则你会被你的轻率而后悔。


童子军规则
要让离开时的营地比进入时更加干净
编码：让模块check in 的时候比check out的时候更加整洁

团队把系统当成一个整体来维护，不再“各人自扫门前雪”，团队互相帮助，互相清理代码。
变量可读性，长函数分割成更短，循环依赖，增加一个借口解耦策略和实现细节。。。。

2.重构前的建议

1.重构代码的最佳起点是清理已有的基础代码和基于这些代码写的测试用例
2.避开重写一切的诱惑
3.逐步增加的小改动胜过一次性的大改动
4.在每次开发迭代后，确保已有的测试用例都通过
5.个人好恶和利己主义不能掺杂到开发中来
6.新技术不是重构的理由
7.要记住人总是会犯错的

在你重构之前
1.理解当前代码的优缺点
2.原有的代码都是经多年的测试并实战过的代码，花费时间多
3.逐步反馈信息来评估改动的对系统的影响，做一些测试
4.不要看不爽就重构
5.如果新的技术框架在功能性，可维护性或生产力上会有显著提升，可以考虑
6.新的设计未必会比原来的好，多考虑

谨防共享
抽取公共的方法或类的时候，需要考虑清楚，是否是真正的公用，否则会适得其反，更加难以维护
通向高性能之路布满了脏代码炸弹
重构时，注重成本，理清结构

3.编码标准自动化和持续化

遵守编码规范
确保代码格式一样，自动运行
静态代码分析工具扫描代码
每个人都配置好工具
测试覆盖率过低，终止构建
代码注释：团队理解代码的含义,对待注释要对待代码一样来维护

代码审查
态度温和，有建设性建议
每个星期正式的代码审查日


编码标准的自动化
对注释的一个注释
代码说不清，注释来补充
代码审查
代码审查日：2个小时一次，循环制模式，让审查者轮流执掌每一次审查会议，可以让专家加入进来，可以作为一次团队的知识分享


自动化
自动化测试：每天和每周末，非工作时间执行（包括性能测试，稳定性测试）
充分利用代码分析工具:使用工具发现bug，规范代码

在睡觉的时候(或度周末的时候)进行测试
充分利用代码分析工具

4.设计

美在于简单
易用不是一种能力，为调用方考虑，为客户考虑
浏览代码，阅读代码的时间
易于检索
清晰的布局
紧凑格式（代码跟诗一样）
封装行为，而不仅仅是状态
额外的设计
好玩的额外功能，但并无用处
遵守YAGNI原则，现在不用就不要写
可能会有用，现在就写，“雪球”会越高越大
系统需求不是随便添加



柏拉图：风格之美，和谐、优雅及优美的节奏尽在于简单
不管系统有多复杂，但每个单独的组成部分都保持着它的简洁性，单一职责，方法的功能如同其名称描述的一样，
5~10行语句的短方法过于极端，这种是比较难，但我想这种间断正是我们希望达到的目标

领域语言里的代码
含义在代码中体现

易用不是一种能力
关于代码布局的麻烦事
编程时间中：花费浏览代码，阅读代码的时间是多少呢？
封装行为，而不仅仅是状态（看下书本中的例子）
代码 YAGNI(You aren’t gonna need it 你绝对不会需要它)

5.杂谈

用户需要什么， 而不是我们提供什么
责备先自责
不断学习
有针对性的勤加练习,提升自身的能力
不要在你的测试代码里装可爱
了解你的局限性，知己知彼
通晓两门以上编程语言


用户会怎么做
当你卡住的时候，你会四处张望，需求帮助；而用户卡住的时候，他们会缩小他们的注意力范围，做好用户体验
在责备别人之前先检查自己的代码
不断学习
阅读书籍，资料
找到一个号导师
利用虚拟世界，网络导师
了解你使用的框架和类库
分享解决一个比较通用的问题方法
分享所学的知识
加入学习小组
参加研讨会
学习业务知识
考虑回学校

有针对性的勤加练习,提升自身的能力
不要在你的测试代码里装可爱
在你的代码中，注释，日志，测试数据，想想一旦公开出去是否有问题，你会脸红吗？
了解你的局限性
通晓两门以上编程语言
每年学习一门新的语言