让我们给业务做减法,给代码做减法。

最重要的写在开头:道术合一,知行合一

现在是讯息爆炸的时代,搜索引擎降低了学习的门槛,凡是都能从百度谷歌了解个一二。正因为这随手就来的一二,带来了想要的“结果”,让大家只掌握了术,但忽视了道。我认为“道术合一,知行合一”,术是千变万化的,但是道确实永远的,做减法就是我自己的代码之道。

可怕的观点:执行效率是第一

我经常听到一种观点,代码需要的是更快的执行效率。以及由这个观点产生的衍生观点,例如:设计模式并不重要等等,因为我们可以绕过框架或者现有的方法,用更“原生”的方式实现一样的结果,这样会运行的“更快”。这是一个可怕的观点,可怕就可怕在看上去没错。软件行业发展到现在已相当成熟,我们绝不能用单一指标衡量代码,如同我们不能用百公里加速来衡量一个车,如果这样想,无疑要选比亚迪,实际情况真的是这样么?

代码是一种业务的体现:全方位的评估才合理

代码是一种业务能力的体现,举个例子:小轿车是个人出行业务的体现,全方位评估软件工程带来的结果才更合理。尤其在国内,人天的成本大幅度的提高,技术团队每天的开支相比其他传统行业近乎天文数字,我们对于迭代周期要求非常的高,单个sprint产出的价值太重要,甚至于正版软件相较于人力成本也已经变得是一个合理的支出范围。所有,我更倾向于,在初期掌握一支小型化技术团队,把握住业务的核心,最大程度整合资源,打通外部内部数据,且团队要能不停的适应业务的变化。而且不光是技术团队,所有业务团队其实都应该如此。

业务好等于代码好:好业务是不停迭代出来的

很多人都告诉我,自己的代码写的多么多么的好,一次写完永久运行。但这样好么,我可以负责的说,这样的代码不值钱。互联网业务是不停的试错出来的,业务好不好对公司来说就是赚钱不赚钱,也就常常带来一个问题,需求肯定不停的变化。我以为业务的打磨是好事,因为没有人能一下找到赚钱的模式,再牛X的业务都是不停的迭代变化出来的。所以,要做到能快速的迭代,我们必须让代码能够快速的变化。可能有些负责通知或者工具类的运维小脚本,写完之后可以静静的躺着运行若干年,但不代表这个代码是好的,只是代表业务是死的。但唯有赚钱的业务才需要不停的修改不停的改变,所以我的观点就是代码是不停的在迭代改变的,同样的我很悲观,盖房子的还能看到楼房屹立100年,作为软件从业者,你的作品可能只能在世界上存活3个月,这是一个非常残酷的事实。

代码变化的本质:反应业务的变化

业务随着时间的推移,往往公司从一开始一个人管全部到后来的运营分工精细化,这背后涉及的是人员和部门的变化。所以当设计系统的时候必然会参考业务部分的划分,使用者划分,和场景的划分等来做设计。如果能在动手写代码之前闭上眼睛看到使用者工作的状态,线下业务转线上的整个过程,思考出每个节点,那就是一种正确的模式,因为你看到了业务,看到了代码的真正价值体现!

语言的进化:都是为了业务

面向过程编程之所以进化到了面向对象,是因为我们发现所有的业务都是存在现实世界中事物对照的,以及他们的关系。有了面向对象,抽象让我们可以更好概括真实世界,多态让代码中事物拥有同时对应多个现实世界事物的能力,继承让我们能够复用大量的代码。进化到了面向切面,我们发现业务不停的在做微调,所谓的微调无非是一些业务逻辑在场景中顺序的改变,有了AOP这样棒的工具,代码的组织变得更合理,当然阅读性会差点。所有的代码特性进化其实本质都是为了更好的表达业务,包括可以用trait来实现一些非通用的多继承,用生成器让函数的返回变得“动态”起来。

最后

业务是一组代码的集成,如同你开了一个面馆,没有必要非自己磨出面粉做出的面条才是最好的。站在一个更高的格局看系统,你需要的是有限的资源下,包装面馆,整合所有。把握最核心,例如浇头做核心,抓大放小。夸张的说,即使只开了一个小店,但是想着一个跨国企业规模。还是那句话,尽可能的在年轻的学习阶段过度设计自己的系统,然后不停的做减法,就能真正的感悟系统,最后你会特别理解罗斯科的作品,真的不用太复杂。

最最后

谨以此文,把自己的小小感悟献给刘锦,一个任劳任怨,每天认真工作学习的安庆少年,未来的安庆马克·罗斯科。

Show Comments