《程序员修炼之道》笔记

 

• • 注重时效的哲学
    • “源代码被猫吃了”
    • 软件的熵
    • 石头汤、温水煮青蛙
    • 足够好
    • 投资自己
    • 交流
  • 注重实效的途径
    • DRY 不要重复自己
    • 正交性
    • 可撤销
    • 曳光弹
    • 原型
    • 估算
  • 基本工具
  • 注重时效的偏执
    • 按合约设计
    • 断言与异常
  • 解耦
    • Demeter法则
    • 元数据
    • 时间耦合
    • 视图
  • 当你编码时
    • 不要依靠巧合
    • 算法速率
    • 重构
      • 重构什么？
      • 如何重构
    • 测试
  • 在项目开始前
    • 需求之坑
    • 谜题
    • 形式
  • 注重实效的项目

 

注重时效的哲学

“源代码被猫吃了”

对风险太大的事，有权拒绝，但是一旦同意，就要切实负起责任。
对自己的职业生涯负责，不害怕承认无知和错误。
当错误发生时，设法提供各种处理办法而不是找借口。

软件的熵

不要容忍破窗
谁都不愿意做第一个弄脏地毯的人

石头汤、温水煮青蛙

总有人要站出来
做改变的催化剂
记住大图景，宏观，战略

足够好

质量是需求的一部分，要规定下来
不要因为过度最求完美而损坏完好的程序

投资自己

定期投资
多元化投资
保守和高风险的平衡
低买高卖
周期性的评估和平衡
批判性思考

交流

列大纲,知道自己要说什么
了解听众
时机和风格
美观的文档
让听众参与，倾听、回复听众

注重实效的途径

DRY 不要重复自己

重复的危害

重复使得维护难以进行
重复浪费大量时间编码和测试

重复的类型

强加的重复——自动工具、糟糕的注释
无意的重复——设计中的失误（所以，请总是使用访问器读写对象属性）
无奈的重复——紧迫的时间（因为复制粘贴总是更容易）
开发者之间的重复——糟糕的设计、糟糕的领导

正交性

消除无关的依赖
设计正交的模块
面向方面编程
避免使用全局数据
避免重复的函数，使用策略模式

可撤销

不存在最终决策，所有需求和设计都可能被更改，随时准备“中途换马”
使用抽象和接口

曳光弹

忽略细节，使用不健壮的代码达成目标，之后再慢慢完善
曳光弹（最终代码的一部分，检验一个功能能否实现）VS原型（用过就废弃，检验一个架构是否设计良好）

原型

　为了学习而使用原型
　忽略正确性、完整性、健壮性和编程风格
　使用原型检验架构问题（耦合性、责任分配、是否重复、接口定义）

估算

慎重选择单位
理解内容、建立模型、分解组件、参数定值
追踪估算情况

基本工具

纯文本
shell
编辑器
调试器
文本操纵
代码生成
源码控制

注重时效的偏执

按合约设计

合约即规定你的权利和责任，也规定对方的权利和责任
公务员式编程（“懒惰”的代码，接受的东西要严格，返回的东西要尽可能少）
里式代换——子类通过基类的接口使用，使用者无需知道其区别
早崩溃（错误要及时暴露，不要隐藏）

断言与异常

断言不会发生的事
断言不能代替错误处理，断言检查的是绝不应该发生的事

解耦

Demeter法则

不向别人暴露自己，不与太多人打交道
不为访问第三个对象而进入某个对象

    //只使用属于以下情形的方法
    class Demeter
    {
     private A a;
     private int func();
     public void example(B b) {
         C c;
        int f = func();//自身的方法
        b.invert();//参数的方法
        a = new A();
        a.setActive();//自身创建的对象的方法
        c.print()//直接持有的对象的方法
        //b.d.func()不能这样使用
     }
    }

适当反规范化以换取速度

元数据

将抽象放进代码，将细节放进数据
使程序可配置

时间耦合

分析工作流，以改善并发性
总是为并发进行设计

视图

视图和模型分类
使用观察者模式

当你编码时

批判的思考所有代码，包括自己的（批注：批判的思考所有观点，包括自己的——《学会提问》）

不要依靠巧合

知道自己在做什么，避免温水煮青蛙
避免盲目，不使用不熟悉的技术
按计划执行
依靠可靠的事务，不依靠巧合和假定，必要时假定最坏的情况
为假定建立文档，告诉别人
测试你的假定，将结果写进文档
为工作划分优先级
不要被历史代码掣肘，必要时替换他们。

算法速率

估算算法的阶
测试你的估算

重构

重构什么？

• 重复
• 非正交的设计
• 过时的知识
• 改善性能

如何重构

早重构，常重构
不要试图在重构的同时增加功能
确保良好的测试
采取短小，深思熟虑的步骤

测试

针对合约测试
从最简单的模块开始测试
为测试而设计
将单元测试放方便的地方
即兴测试、回归测试
测试工具

在项目开始前

需求之坑

需求是对要完成的某件事的陈述
不要收集需要，而要挖掘需求
与用户一同工作，像用户一样思考
建立需求文档
避免需求过度
看得远一点，抽象比细节更长久
维护项目词汇表

谜题

不要在盒子外面思考——要找到盒子
约束是真实存在的吗？有没有更好的方法？

形式

仔细考虑再开始
对有些事，“做”胜于“描述”
不做形式方法的奴隶
不迷信权威

注重实效的项目

无处不在的自动化
无情的测试
简明的注释
规范、完整的文档
温和的超过期望
这是我的代码，我为此负责