关于软件开发的一些共识
这篇书评可能有关键情节透露
价格对于中国市场还是有点贵了,不过考虑到是把这本书的收益都捐献给希望工程,倒也还能接受。
其实里面很多原则都已经被我们潜移默化地接受了,或者是已经作为工程师的基本准则了。
但重新读下来,还是有一些准则需要进一步的思考
这个时代其实是最好的时代,也是最坏的时代,一方面,我们能够获取到我们想了解的各行各业的信息,另一方面,各种奶头乐的信息也不断充斥着我们的神经。
原则 29 和组织荣辱与共
以前觉得日本的终身制雇佣不利于经济的发展和人才的流动,但有时候在想,终身制雇佣在某些方面其实更容易源源不断地培养人才,大家不需要担心失业、被解雇等各种问题。
原则 34 软件文档都要有索引
我们其实就是把这个世界非结构化的知识逐渐结构化,才适合检索以及建立自己的知识体系。
原则 47 使用正确的方法
没有任何一种需求分析方法适用于所有软件。跟人月神话中的“没有银弹”,有异曲同工之妙
原则50 给需求排列优先级
这个也是我们日常执行中,很容易会忘记的。需求总是很多,到底哪些需求才是
原则 64 没有文档的设计不是设计
这点是自己来百度前比较大的知识误区,有时候一些设计就是脑子里有一些想法,就认为 OK 了,但真正写下来发现还是有 diff 的。能够在更早的阶段发现问题,损失其实是最小的。
原则 67 保持简单
https://zh.m.wikipedia.org/zh-hans/KISS%E5%8E%9F%E5%88%99
原则 86 软件可靠性可以通过冗余来实现
其实就像我们现在的很多可靠性提升,其实是依赖于我们的各种容灾 cache,以及请求重试
原则 94 要先保证正确,再提升性能
原则 95 在写完代码之前写注释
现在一直都是这个习惯,但以前确实是写完代码之后可能才补注释的
原则 147 不要设定不切实际的截止时间
工作如此,生活也是,不切实际的截止时间,只会让大家放弃,而不是去努力达成。
原则 191 一个程序越老,维护起来越困难
目前平台的项目也是,10 年的项目,越往后维护,成本越高。也是第一次接触这种历史包袱这么重的项目,确实感触颇深。
原则 199 在优化前先进行性能分析
代码优化其实也充满着二八定律,80%的 cpu 周期被 20%的代码消耗
有的规则还是常读常新,时常翻阅应该也会有自己一些不一样的感受。不过这方面的书如果只选一本的话,我应该会选择《代码大全》。