本文集说的都是些平凡的小事，但往往是这些小事区分了产品的伟大与平庸。

1.因为平凡，所以不受关注

我曾经像你像他像那野草野花...向前走，就这么走，就算你会错过什么...

“如何写好业务侧代码？”，这个问题出身不太好，注定是一个不讨巧的话题。在实战项目中，很少有项目经理愿意触及这个话题，如果他愿意重视并真正投入成本去重构、看护业务侧代码的架构，那么恭喜你，你遇到了一个比较有远见的项目经理。

图1

(1)为什么“业务侧代码”如此不受待见呢？

首先，"业务侧代码"属于项目的隐疾。相比让码农赶工多堆几个新需求带来直接收益，反正客户无法直接感知到业务侧代码是一朵花还是一坨屎。好像外表华丽的小姐姐她的宿舍很可能是无法直视的。邋遢又怎样，小哥哥的身体永远是诚实的！

图2

其次，"业务侧代码"生存在程序猿的鄙视链底端。如果说“人工智能、微服务、大数据、区块链”是当红花旦，那么“业务侧代码”简直是群众演员(连过气影星都算不上)。假如一个工作10年的程序猿，多年的工作经历仅仅是接触“业务侧代码”，那么他很容易被技术潮流淘汰掉。

图3

(2)“业务侧代码”的生存状态——看天吃饭

由于“业务侧代码”过于平凡，业界往往缺乏对“如何写好业务侧代码”的关注与指导，即便有几本软件架构的书籍，也不过蜻蜓点水般的点到即止。

因此，占据一个产品90%的“业务侧代码”往往看天吃饭——这个天就是项目组的码农，如果码农经验不够丰富、格局不够高，那么“业务侧代码”十之八九是野蛮生长、混乱无度。

图4

2.虽然平凡，但不可替代

我曾经失落失望失掉所有方向，直到看见平凡才是唯一的答案...

道理往往隐藏在平凡的事物中，“业务侧代码”也是如此。

在“地球某个角落的天才忽然冒出一个idea，一款产品的核心代码诞生”。这种核心代码大约占据产品代码的10%，此时产品大约就50分的水平吧——不能给客户直接使用的代码不叫产品。

剩下的时间就是枯燥的“业务代码”之夜了，迭代、开发、测试、修改问题单，周而复始，产品从50分到60分，从60分到70分，从70分到80分，从80分到81分、82分、83分。。。漫漫长夜，“业务侧代码”慢慢占据产品90%的比重。

产品越接近100分越接近“伟大”，当然难度、成本也会越来越高。“业务侧代码”的架构(低耦合性、扩展性、高可用性、易用性)深深的影响着产品能够达到的高度，也深深的决定着产品为了达到高度而支付的成本。

一款伟大的产品之所以伟大，往往不是因为那10%的核心代码，而是那90%平凡而普通的“业务侧代码”。

图5

这就是本文集诞生的初衷。