读薄经典——《程序员修炼之道》
第一章
Provide Options,Don't Make Lame Excuses.
对自己承担的事情负责
麻烦别人之前先问自己是否能解决
Don't Live with Broken Windows
不要把发现的‘破窗’（低劣设计、错误决策、糟糕代码）留在软件中
Be a Catalyst for Change
做促使团队变得更好的催化剂，比如处理掉那些早就决定要做却一直拖延的事情。
这使我想起了《士兵突击》中许三多铺路的那段。
——2015-03-30
Make Quality a Requirements Issue
使软件质量成为需求问题，让用户觉得需求
Invest Regularly in Your Knowledge Portfolio
- 每年至少学校一门新的语言
- 每个季度阅读一本技术书籍
- 阅读非技术书籍
- 上课(可以是公开课)
- 尝试不同的操作系统
Critically Analyze What You Read and Hear
批判性分析和接受你所看到和听到的知识，促进对思考和对知识的理解
——2015-04-01
It's Both What You and the Way You Say It
- 知道自己要说什么
- 了解听众
- 选择时机
- 做倾听者
- 让听众参与
- 回复他人
第二章
DRY-Don't Repeat Yourself
系统中的每一项知识都必须具有单一、无歧义、权威的存在。
糟糕的代码才需要许多注释(一来是过多的注释会让代码变得不纯净，二来代码修改之后需要重复得去更新注释)
Make It Easy to Reuse
让复用变得更容易，避免开发者之间的重复
Eliminate Effects Between Unrelated Things
解耦合
- 不依赖其他模块也不要想其他模块暴露任何细节
- 避免使用全局数据
- 避免编写相似的函数
——2015-04-04
Use Tracer Bullets to Find the Target
就是做demo的意思
Prototype to Learn
为了学习或测试的单一功能，可以忽略以下细节：
- 正确性
- 完整性
- 健壮性
- 风格
Program Close to Problem domain
使用需求所在领域常用的语言去开发，如做网站就用php，jsp，asp等，嵌入式就用C或者汇编
——2015-04-06
Estimate to Avoid Surprises
通过以下方式，提高项目进度估算的准确度：
- 充分理解项目需求
- 建立响应系统框架
- 拆分具体系统
另外要持续追踪估算的准确性，找出影响估算准确性的因素
Iterate the Schedule with the code
通过编码不断调整时间预算
第三章
Keep Knowledge in Plain Text
使用纯文本记笔记
Use the Power of Command Shells
命令行可以实现自动化
——2015-04-21
Use a Single Editor Well
用好一种文本编辑器
Alway Use Source Code Control
使用版本控制，方便协作和查看代码修改记录
——2015-05-10
Fix the Problem, Not the Blame
重点去解决bug，而不是去指责造成bug的人。
项目组新来了一个程序，因为一个bug导致了一场争论，似乎就是因为这
Don't Panic
查找bug时要忘掉所有的压力，不要把脑细胞浪费在版本日或“那不可能”的想法上，要着眼现象，查找原因。
bug查找策略：
- 能很容易的重现bug
- 使数据可视化
- 跟踪程序执行过程
- “橡皮鸭”(解释你的bug)
- 二分法
"Select" Isn't Broken
问题出现之后的第一想法不应该是操作系统或第三方库
Don't Assume it-Prove It
在有数据证明之前，做任何假定
第四章
Design with Contracts
liskov原则：子类必须要能通过积累的接口使用，而使用者无须知道其区别
通过早崩溃、在问题现成找到和诊断问题要容易得多。
——2015-05-12
Crash Early
如果数据出错，尽早的让程序崩溃，避免进一步破坏后面的数据。
If It Can't Happen, Use Assertions to Ensure That It Won't
对不可能出现的参数，用断言进行判断。
——2015-05-18
Finish What You Start
资源分配管理有始有终，包括文件、socket、内存等
- 先分配的资源后释放，避免引用已释放的资源
- 以相同的顺序分配资源，避免多线程死锁
第五章
Minimize Coupling Between Modules
函数参数直接传递所需要数据，而非传递整个对象，然后通过对象去获取所需要数据。
得墨忒耳法则 规定,某个对象的任何方法都应该只调用属于以下情形的方法：
1 它自己(成员函数)
2 传入该方法的任何参数(参数的成员函数)
3 它创建的任何对象(局部对象的成员函数)
4 任何直接持有的组件对象(成员变量的成员函数)
The Law of Demeter for functions states that any method of an object should canll only methods belonging to:
1 itself
2 any parameters that were passed in to the method
3 any objects it created
4 any directly held component objects
——2015-05-26
——2015-06-01
Configure, Don't Integrate
让程序尽可能多的可配置
Put Abstractions in Code, Details in Metadata
让程序去实现各种规则，数据实现各种业务
Analyze Workflow to Improve Concurrency
找出工作流中可以并发的事情同事开展
Design Using Services
将整个流程分为多个段，每段内创建队列，并列进行，防止某一段瓶颈，影响整体速度
Always Design for Concurrency
设计接口时考虑多线程可能引起的bug
——2015-06-14
事件
- 推模式：供应者通知信道，信道把该事件派发给已登记的客户
- 拉模式：客户周期性轮询信道，信道轮询供应者
Separate Views from Models
MVC思想
Use Blackboards to Coordinate Workflow
这个不是太理解，回过头来想想，应该是组件式开发和增量式开发
——2015-07-05
第六章
Don't Program by Coincidence
考虑输入参数的所有情况，避免偶然的成功
Estimate the Order of Your Algorithms
估算算法复杂度
Refactor Early, Refactior Often
重构的一些建议：
- 不要再重构的同时添加新的功能
- 重构的步骤尽量西，每次重构的东西尽量少
- 每次重构完一小步都要测试
Design to Test
设计要易于测试
Don't Use Wizard Code You Don't Understand
不要使用你不理解得向导代码(如MFC自动生成的代码)
第七章
完美，不是在没有什么需要增加、而是在没有什么需要去掉时达到的
Work with a User to Think Like a User
设身处地的为用户着想
