阅读 132

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

注重实效的哲学

我的源码让猫给吃了

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

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

负责

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

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

软件的熵

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

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

石头汤煮青蛙

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

足够好的软件

欲求更好,常把好事更糟糕。-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.任何直接持有组件的对象
    }
}
复制代码

当你编码时

靠巧合编程

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

怎样深思熟虑地编程

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

重构

何时重构

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

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

早重构,常重构

怎样重构

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

结论

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