一些软件设计原则
- 先设计，后编码
- 写”明显没有错误的“代码
- 学最激进的技术，用最简单的实现
- 把可变的东西隔离到配置数据中
- 多考虑意外情况，不要只实现 happy path
- 在设计阶段就开始考虑异常情况
- 复用的诀窍：只做一件事情
- 学习测试理论
先设计，后编码
需求和设计阶段应该在软件开发的 60% 时间，而实现占 40%。没有事先规划，想哪写哪；结果被层出不穷的状况（还美其名曰需求变更）牵着鼻子、面多了加水水多了加面：这就是绝大多数软件开发时间冗长、状况不断、无疾而终的根本原因。
写”明显没有错误的“代码
而不是”没有明显错误“的代码。
除非你真的做了设计，否则你的代码一定没有什么”设计感“。用心设计，才能找到达到目标的路径中最短最快的那一条。
做到这一点，才能把代码写的简单，让人一眼看出意图、明显没有缺陷。
把复杂的功能写简单、写的让人一眼看懂、且知道是不是有错误，需要深厚的功底。
学最激进的技术，用最简单的实现
把可变的东西隔离到配置数据中
换句话说，程序最好只写不变的部分，如果需要变化，用最抽象的实现（元编程）。
“开闭原则”说的其实就是，程序代码写出来就不用再动了，这叫对修改封闭；但随便你需要什么样的功能，都可以借助既有的代码完成，这叫“对扩展开放”。
真正做到了“对修改封闭”，表现是“不需要动”“不要去怀疑”“可以增加功能，但没必要触动已有代码”
多考虑意外情况，不要只实现 happy path
Happy path 就是完全不考虑出错、不考虑数据竞争、不考虑操作提交时条件不满足、假定世界是完美的、按顺序来一切都能解决的这么一个执行流。
当然，happy path也是必须先找出来的。
先把happy path找出来，再一点点添加——这里可能出现意外，出现意外怎么办……逐渐添加、丰富下去，正确的设计稿就出来了。
在设计阶段就开始考虑异常情况
首先，要把异常分为几类。
然后，对确定来源的异常应设计正常处理流程——它是正常流程的一部分，是设计之初就应该考虑好的，可不是什么异常。
之后，对未知来路的奇怪错误，不要姑息——见到了，就让程序崩掉。
最终，如果我们的程序的确有极高可靠性要求的话，我们需要设计一个机制，及早发现程序崩溃并自动拉起新的实例。
如此反复，最终就是：一出错就马上抛异常崩溃掉的程序，出错的机率越来越低、渐至于怎么折腾都不会崩溃、甚至单实例都能7x24小时可靠运行；而使劲容错、绝不崩溃的程序，它几乎每时每刻都在出错、逼得用户不得不“重启下说不定就好了”“这破系统用十分钟就得重启，不然丢数据……不是丢新数据，旧数据都会被破坏……”
复用的诀窍：只做一件事情
其实一点也不难：只做一件事，把一件事做好，这玩意儿就天然是方便复用的。
这很容易理解。玩过积木吧？什么样的积木摆什么造型都用得上？
方块，对吧。
为什么方块这么容易复用？因为它最简单。
这实际上也是我前面说过的：把可变的东西隔离到数据中，程序只提供一组元规则！程序越简洁，就越是可以随意的拼起来、拼出千变万化五彩缤纷的大千世界。
学习测试理论
嗯，不可否认，的确“总会有我们意想不到的状况”；但绝大多数情况，我们是可以预想到的。
作者：invalid s
链接：https://www.zhihu.com/question/32255673/answer/2325523343
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。