从业务到代码

目的

所以我写这篇文章的目的很简单，为了给各位写代码的新手带来一点不同的视角

前言

代码不过是业务的表示，当你把代码看作一门语言（这里语言不是指java/C这些编码语言的意思，而是普适意义上的language）的时候，我们，作为编码人员，更多的是像是陈述事实一样，将业务陈述，然后通过代码落地。

问题

在新手中，经常有这么几个疑问
1. 这么写有什么用
2. 明明我一个函数就可以把所有工作做完，为什么要拆开来
3. 这个工具屌不屌
4. 这个语言如何如何

看法

结论

如果不能跳出只是代码堆砌工的眼界，那么永远不知道有什么用
拆分是为了将函数目的单纯化
工具只是生产力工具的一部分，不能说锤子一定比机床好
同样，都是锤子，不能说A类型的锤子一定好与B类型锤子

理由

不知道各位呆过几个公司，每家公司给人的感觉都是不一样的。提几个点让大家想一想
1. 有问题能不能找到确定的一个人能解决确定的一类问题
2. 出了事情，背锅是平摊锅还是说加权锅，还是看老板心情分
3. 简单点，如果电脑坏了要换，上报后多久能搞定
4. 工作的成果是否能够量化
让我们来换到代码的视角来看这个问题
1. 出了bug能否容易精确定位在什么类
2. 出错了，整个系统的其他部分是否依旧稳定
3. 某个部件如果因为市场因素全部重做，重做的成本是低是高
可能换到编码视角，各位一定能够简单的提出一些熟悉的概念，比如鲁棒性，比如重构，etc。但是不知道各位有没有做过思考，亦即这些概念套用到非编码视角的时候也是通用的，更或者说，这概念都是从其他行业或者领域移植到软件开发领域，毕竟软件开发到今天真正普及也就四十年？

所以

向业务学习，好的代码应该是和业务一致的
因为你的代码就是业务时候，业务的快速变动就能变成了代码变动
而一个公司的业务变动不可能连根本逻辑都改变了
加班就会少了
与业务人员沟通也会顺畅了