《软件设计的哲学》读书总结

前几个月微博看到有人推荐这本书,翻了一下,觉得重点总结到位,对日常工作有很强的指导意义和实践参考。老外写书比较啰嗦,我做个简要的读书总结。网上有中文翻译,不过还是建议大家看原版的,这本书的英语阅读体验还是比较愉快的,不是那种语法晦涩,句子巨长,脑回路打结的高级英语。

《软件设计的哲学》读书总结_第1张图片

本书作者John Ousterhout是Tcl语言与Raft协议的发明人,有着丰富的学术界与工业界经验。所以这本书绝不是理论的说教,而是实践与理论的高度结合。

这本书的最核心内容就是告诉你复杂度才是软件系统设计最核心的问题,不好的设计会导致系统复杂度爆炸,导致维护成本上升,性能下降,运行不稳定等一系列问题。为了解决复杂性问题,你必须先知道如何识别会导致复杂度上升的因素,然后是有哪些手段可以借鉴参考来降低复杂度。

我个人阅读后有几点总结:

  1. 软件复杂度是日积月累的,如果只是打补丁总有一天会失控。可以容忍一开始不好的设计,但是之后每次都可以试着去优化一点。但也不要想动不动就整个大新闻,毕竟业务的稳定和投入产出也是要考虑的。你必须一直去思考这个问题,如果一切只会完成短期任务,那么复杂度一定会失控。
  2. 模块和类要有深度。我觉得这个问题在Java的框架里特别明显,一层套一层,理论上是面向对象,可复用可替换,但是对于99%的应用来说,这个需求根本不存在。一个模块或类,甚至是函数,要解决一个完整的问题。能原子化的就不要再为了拆分而拆分。
  3. 信息隐藏。在接口层面要暴露的是做什么,至于怎么做留到实现层面。复杂度尽可能下沉,接口的调用者不要去想,也不应该去操心底层实现的细节。
  4. 尽量为通用的场景提供默认的行为,不要让用户自己去理解。以下这段Java代码就让我挺抓狂的,这也是我不喜欢Java的原因。不管是C,C++还是Python,都没见过操作一个文件需要这么坑的写法。
    FileInputStream fileStream = new FileInputStream(fileName);
    BufferedInputStream bufferedStream = new BufferedInputStream(fileStream);
    ObjectInputStream objectStream = new ObjectInputStream(bufferedStream);
  5. 错误处理不要过度设计。Define Errors Out Of Existence我实在不知道该怎么翻译,排除不需要的错误?英语好的指出一下。程序能消化的错误就自己消化掉,不要扔给用户。比如自动重试重写,处理不了的极端情况就地躺倒,因为这时用户也不知道该怎么办。这里有举了Java的例子,subString就不是一个好的设计。如果索引范围不符合返回一个空字符串就能解决大部分问题,非得扔个IndexOutOfBoundsException异常出来。不要把错误扔给用户处理,很多时候用户也不知道该怎么处理。
  6. 写注释,注释一定要有用,要把那些不容易理解的东西解释清楚,而不是翻译代码。建议先写注释,这样你会更关注于你要做什么。不然等写完代码思路就固化了,变成围绕代码去写注释,变成尾巴摇狗了。代码尽可能集中注释,一件事尽量在一个地方写清楚。如果确实不行,建议使用design notes集中管理。比如写个wiki,或者别的什么地方,在注释里引用参考XXX。
  7. 一致性,命名,代码风格,处理逻辑尽可能统一。哪怕是低水平的统一也好过各自放飞。尽量不要改变一致性标准,除非有重大收益。不然统一已有系统的一致性就是很高的成本,如果新老一致性不兼容会导致更多麻烦。
  8. 测试驱动开发是伪命题。这点我非常赞同。大多数人根本没有先写用例,再写代码的能力。另外用例不可能一次写对,但用例摆在那里,开发的时候代码就会已通过测试为目标,很多时候容易导致拼凑补丁。但是有一种情况必须先写用例,就是处理历史遗留屎山。当前代码支持的业务场景,以及你对代码功能的所有猜测必须有用例作为支撑,这样在修改完成后可以快速检查有没有影响现有功能。
  9. 性能是设计时就要考虑的。优化性能时优先考虑关键路径,如何用最少最高效的代码实现关键路径。这里不是82法则,很多时候是95%(甚至更高)的关键路径对5%的异常路径。即使异常路径的成本提高100%,但是关键路径的成本只要降低20%,总成本就可以降低约15%。
  10. 最重要的原则,把自己的第一个想法毙掉。至少要想两个方案,有选择才有比较,

读完本书后有两个感觉:

  1. Java是面向咨询公司和外包公司的编程语言。生在了一个好时候赶上互联网大跃进卡住了重要生态位,写起来感觉就是我花半天PHP能撸个功能出来,Java还没把框架相关的基础代码写完。
  2. 如果你真是追求技术的程序员,避免以下两类场所:1)传统企业的信息化研发部门,那就是天天在屎山里折腾,口味万年不变;2)大厂业务部门,充分享受99.99到100的极致内卷,虽然也是天天在屎山里折腾,但是拥抱变化,偶尔能欢欢口味,偶尔还能蹲到一个新的坑位。去硬技术公司或是业务飞速增长的初创型公司会是一个比较好的选择,能让你有机会实践这本书里的大部分内容。

你可能感兴趣的:(职场,设计模式,软件架构)