#写好业务代码#1.平凡之路

0.562字数 994阅读 385

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

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

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

推荐阅读更多精彩内容