软件设计杂谈<二>

寻找（多个）解决方案
　　如果对问题已经有不错的把握，接下来就是解决方案的发现之旅。这是个考察big picture的活计。同样是满足孩子想要个汽车的愿望，你可以：

1.去玩具店里买一个现成的

2.买乐高积木，然后组装

3.用纸糊一个，或者找块木头，刻一个

　　这对应软件工程问题的几种解决之道：

1.购买现成软件（acuquire or licensing），二次开发之（如果需要）

 

3.自己开发（build from scratch, or DIY）

　　大部分时候，如果a或b的TCO [1] 合理，那就不要选择c。做一个产品的目的是为客户提供某种服务，而不是证明自己能一行行码出出来这个产品。

　　a是个很重要的点，可惜大部分工程师脑袋里没有钱的概念，或者出于job security的私心，而忽略了。工程师现在越来越贵，能用合理的价格搞定的功能，就不该雇人去打理（自己打脸）。一个产品，最核心的部分不超过整个系统的20%，把人力资源铺在核心的部分，才是软件设计之道。

　　b我们稍后再讲。

 

　　对工程师而言，DIY出一个功能是个极大的诱惑。一种DIY是源自工程师的不满。任何开源软件，在处理某种特定业务逻辑的时候总会有一些不足，眼里如果把这些不足放在，却忽略了人家的好处，是大大的不妥。前两天我听到有人说 "consul sucks, …, I’ll build our own service discovery framework…"，我就苦笑。我相信他能做出来一个简单的service discovery tool，这不是件特别困难的事情。问题是值不值得去做。如果连处于consul这个层次的基础组件都要自己去做，那要么是心太大，要么是没有定义好自己的软件系统的核心价值（除非系统的核心价值就在于此）。代码一旦写出来，无论是5000行还是50行，都是需要有人去维护的，在系统的生命周期里，每一行自己写的代码都是一笔债务，需要定期不定期地偿还利息。

　　另外一种DIY是出于工程师的无知。「无知者无畏」在某些场合的效果是正向的，有利于打破陈规。但在软件开发上，还是知识和眼界越丰富越开阔越好。一个无知的工程师在面对某个问题时（比如说service discovery），如果不知道这问题也许有现成的解决方案（consul），自己铆足了劲写一个，大半会有失偏颇（比如说没做上游服务的health check，或者自己本身的high availability），结果bug不断，辛辛苦苦一个个都啃下来，才发现，自己走了很多弯路，费了大半天劲，做了某个开源软件的功能的子集。当然，对工程师而言，这个练手的价值还是很大的，但对公司来说，这是一笔沉重的无意义的支出。

　　眼界定义了一个人的高度，如果你每天见同类的人，看同质的书籍/视频，（读）写隶属同一domain的代码，那多半眼界不够开阔。互联网的发展一日千里，变化太快，如果把自己禁锢在一方小天地里，很容易成为陶渊明笔下的桃花源中人：乃不知有汉，无论魏晋。