读薄经典——《程序员修炼之道》

第一章

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查找策略：

1. 能很容易的重现bug

2. 使数据可视化

3. 跟踪程序执行过程

4. “橡皮鸭”(解释你的bug)

5. 二分法

“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

设身处地的为用户着想