关于软件开发的一些共识

价格对于中国市场还是有点贵了，不过考虑到是把这本书的收益都捐献给希望工程，倒也还能接受。

其实里面很多原则都已经被我们潜移默化地接受了，或者是已经作为工程师的基本准则了。

但重新读下来，还是有一些准则需要进一步的思考

这个时代其实是最好的时代，也是最坏的时代，一方面，我们能够获取到我们想了解的各行各业的信息，另一方面，各种奶头乐的信息也不断充斥着我们的神经。

原则 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%的代码消耗

有的规则还是常读常新，时常翻阅应该也会有自己一些不一样的感受。不过这方面的书如果只选一本的话，我应该会选择《代码大全》。