注重实效的哲学

我的源码让猫给吃了

在所有的弱点中，最大的弱点就是害怕暴露弱点。

对于缺点、无知、错误，必须诚实。

负责

承诺的事情正确完成，无法完成，超出控制的事情不去承诺。

为结果负责，出现问题时应提供其他解决方案，不是寻找借口。

软件的熵

低劣设计，糟糕代码需要发现一个就修一个，否则会加速任何一个整洁，良好系统的腐烂。

破窗理论:一辆轿车放一星期无人理睬，一旦有一扇窗户被打破，数小时之内车上设备就会被抢夺一空

石头汤煮青蛙

当大家都不愿意做一件事时，自己先做，让其余人看见未来，就能聚集在自己周围。

足够好的软件

欲求更好，常把好事更糟糕。-The King Lear

系统的功能和质量可以让用户参与权衡，不一定要十全十美才进行交付。用户尽早使用而给出的反馈，能让系统引向更好的最终解决方案。

你的知识资产

知识会过期，价值会降低，自身价值也在降低

经营你的资产

定期投资：定期学习新知识，即使学的不多，因为习惯本身和知识总量同样重要
多元化：掌握的技术越多，就能更好的进行调整，拥抱变化
管理风险：技术也存在高风险高回报，低风险低回报的情况，不要把技术鸡蛋放一个篮子里（个人理解：风险：学习需要花费的时间，回报：学习后产生的收益。高风险高回报的例如：操作系统，算法之类的计算机基础。而低风险低回报的例如某个框架的使用，API的使用等）
低买高卖：在新技术流行之前学习它，但是这和找到被低估的股票一样困难
重新评估与平衡：上个月的热门技术可能下个月就非常冷门，要时常关注业内的新动向。

学习的机会

当发现自己不会的问题不要搁置，应该上网搜索，去图书馆，去找出能找到答案的人。寻找答案的过程不仅可以建立人际网络，也可以找到其他不相关问题的解决方案，都是很大的收获。

批判的思考

对于学习到的知识要加上自己的思考，不一定每一个热门技术都适合自己的项目，每个技术不一定都像宣传那么好。

交流

知道你想要说什么

写下想表达内容的大纲，并反复问自己，这些是否讲清了我要说的所有内容？并反复修改

了解你的听众

你想让他们学到什么
他们对你讲的什么内容感兴趣
他们有多少经验
他们想要多少细节
你想让谁知道这些信息
你如何让他们听你说话

注重实效的路径

重复的危害

如果你改变其中一处，你必须记得改变其他各处。这不是你是否能记住的问题，而是你何时忘记的问题。

正交性

不相依赖以及解耦，良好的系统中，改变数据库不会影响界面，改变界面不会影响数据库。

通过消除无关事务之间的影响来做到正交，可以带来两个好处提高生产率与降低风险

提高生产率

改动得以局部化，增加新代码不用改变已有代码
更好的复用
对正交的组件进行组合，生产率会微妙的提高。A组件能做M件事，B组件能做N件事，AB组合在一起就能做M*N件事。（这里有一点中台的感觉）

降低风险

隔离：某个模块出现问题不会扩散到其余模块，修复也更容易
更健壮：对某个模块进行改动，出现的问题只会出现在该模块
可替换性：不会和特定产品、平台绑定在一起，第三方组件都被隔离在各自模块

设计

如果显著改变某个功能的需求，有多少模块会受影响？正交系统中的答案是：一个。

编码

每次编写代码都有破坏正交性的风险，需要时刻监视自己做的事。

代码保持解耦
避免使用全局数据
避免编写相似的函数

测试

每个模块都应拥有自己的单元测试

可撤销性

不存在最终决策，要把决策视为写在沙滩上而不是刻在石头上，大浪随时可能把它抹去。

注重实效的偏执

计算机简短历史中，没人曾写出一个完美的软件，你也不大可能成为第一个

接受，拥抱并庆祝它

要崩溃，不要破坏

当错误发生时，应该尽快抛出异常终止程序，而不是把错误数据写进数据库里。

断言式编程

如果一个情况不可能发生，就用断言确保它不会发生

弯曲，或折断

解耦与德墨忒尔法则

好篱笆促成好邻居

间谍常会组成一个小组，小组内互相认识，但不认识小组外的人，如果某个小组被发现了，再多的审问也无法使其他小组的人暴露。

德墨忒尔法则

函数的德墨忒尔法则规定，任何方法调用都应该只调用属于以下情形的方法

public class Demeter {
    private void func(){}
    private Object selfObj;
    public void example(Object paramObj){
        Object methodObj = new Object();
        func();                              //1.类自身的方法
        paramObj.toString();                      //2.传入该方法的任何参数
           selfObj = new Object();
        selfObj.toString();           //3.该方法创建的任何对象
        methodObj.toString();          //4.任何直接持有组件的对象
    }
}

当你编码时

靠巧合编程

避免靠巧合编程，而要深思熟虑地编程。

怎样深思熟虑地编程

总是意识自己在做什么
不要盲目编程：不要构建不完全理解的系统，使用不熟悉的技术
按照计划行事
依靠可靠事务：如果有无法特定的情形，就假定是最坏的情况
需要其他人知道的内容最好文档化
为工作划分优先级
不做历史的奴隶：不让已有代码支配未来代码，不适用的代码都可被替换，是否重构取决于重构的影响小于不重构的影响

重构

何时重构

出现重复性代码
非正交设计
过时的知识
性能不好

重构就像外科手术取肿瘤，越早重构越安全

早重构，常重构

怎样重构

不要在重构的同时增加功能
开始重试之前，确保拥有良好的测试

结论

首先承认自己永远写不出完美的软件，也没人能写出
对于接手整洁的系统，要小心翼翼地维护，防止破窗效应
接手糟糕的系统，需要添加单测用例，然后排期逐渐重构
系统的设计与编码实践中，要注意正交性设计，尽最大可能地解耦
注意培养定期学习的习惯，哪怕学习的内容不多，习惯本身更加重要

2K字带你读完《程序员修炼之道》精华