“一件事情如果过于复杂,那么一定是哪里出问题了,大部分情况下是对问题的理解出现偏差”
    Joe Armstrong

今天写了半天代码,在别人的代码基础上新增功能,算是站在别人肩膀上劳动吧,这个项目下周就交给其他组来做了,我算是收尾。

满打满算,我在这个项目上的时间,算是业余参与,并且是简单处理下业务需求。

进入之初就发现了问题,有一套很复杂的解析流程,虽然可以读懂,但是不好维护且凌乱。

顿时我就有合理的解决方案来做,这个思路,算是来自于rails/springboot的设计思路吧,约定一些事情,并且用类型/接口限制清楚。

理想情况下,这样新增频道的三处逻辑实现,会变成0开发,0成本处理。

想一想,现有的解决方案:

1,明显是复杂的

2,是可以跑起来。

所以,我觉得可能是之前面临了这个问题,现在改呢,还是以后再优化? 一般面临这个问题,基本上都是now / never 之间的选择了。

一个产品从外部看很光鲜,但是内部逻辑乱作一团的事情很多

甚至有设计之初,很合理,很简单,随着业务变更,代码的复杂度在不断提升,设计合理性在不断下降,也就是代码的腐败过程。 阴暗面持续出现。

这就需要在开发过程中,不断的回头对代码进行优化,甚至重构,其实这个过程可能会很累,很繁琐,需要搞懂之前的复杂逻辑,但是最后肯定会做成

因为如果你对问题的理解没什么偏差,你实现足够简单,那么这件事肯定可以做出来

所以别人跟我说我擦你做的东西很复杂

我只是把复杂的事情,拆成了一件件比较简单的小事来做,一个一个来嘛,有复杂的

绝大多数软件开发中,很多的框架啊,虽然说起来都是领域性的描述方案,但是核心还是在做一件事

"把复杂的问题,简单化"

我很信奉这句话,所以,解决一个问题,和怎么简单的解决一个问题,是完全两个风格

简单的力量是无穷的,一个复杂功能,要最大限度的拆解独立的简单功能。 这是业务拆解

后来我遇到了函数式处理手段,顿时感觉很亲切,所以,把复杂业务拆解成独立运行无上下关联的小零件,这对项目来讲,是一种变相解放。

做得好,后续接手人,会很舒适。

拆,费事,不拆,一把梭,简单。

这些在kpi上并不是最核心的,靠的还是责任心。

所以从技术人员的角度,clean code 是一种境界,是一种氛围。

我要在此自律,推进且用心。