注重实效的哲学
我的源码让猫给吃了
在所有的弱点中，最大的弱点就是害怕暴露弱点。
对于缺点、无知、错误，必须诚实。
负责
承诺的事情正确完成，无法完成，超出控制的事情不去承诺。
为结果负责，出现问题时应提供其他解决方案，不是寻找借口。
软件的熵
低劣设计，糟糕代码需要发现一个就修一个，否则会加速任何一个整洁，良好系统的腐烂。
破窗理论:一辆轿车放一星期无人理睬，一旦有一扇窗户被打破，数小时之内车上设备就会被抢夺一空
石头汤煮青蛙
当大家都不愿意做一件事时，自己先做，让其余人看见未来，就能聚集在自己周围。
足够好的软件
欲求更好，常把好事更糟糕。-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.任何直接持有组件的对象
}
}
当你编码时
靠巧合编程
避免靠巧合编程，而要深思熟虑地编程。
怎样深思熟虑地编程
- 总是意识自己在做什么
- 不要盲目编程：不要构建不完全理解的系统，使用不熟悉的技术
- 按照计划行事
- 依靠可靠事务：如果有无法特定的情形，就假定是最坏的情况
- 需要其他人知道的内容最好文档化
- 为工作划分优先级
- 不做历史的奴隶：不让已有代码支配未来代码，不适用的代码都可被替换，是否重构取决于重构的影响小于不重构的影响
重构
何时重构
- 出现重复性代码
- 非正交设计
- 过时的知识
- 性能不好
重构就像外科手术取肿瘤，越早重构越安全
早重构，常重构
怎样重构
- 不要在重构的同时增加功能
- 开始重试之前，确保拥有良好的测试
结论
- 首先承认自己永远写不出完美的软件，也没人能写出
- 对于接手整洁的系统，要小心翼翼地维护，防止破窗效应
- 接手糟糕的系统，需要添加单测用例，然后排期逐渐重构
- 系统的设计与编码实践中，要注意正交性设计，尽最大可能地解耦
- 注意培养定期学习的习惯，哪怕学习的内容不多，习惯本身更加重要
