从代码行数是否可以评估一个人的工作成绩说起——谈抽象结构和开发流程

今天,在知乎看到一个问题,"4个月写了4万行iOS代码,算多还是少呢?",这是一个没办法回答的问题。我一直用代码行数衡量我自己的项目,但是在我对一个人不了解的时候,他的代码行数多少对我毫无意义。这是一个相对指标,自己衡量自己很好,衡量别人是完全不充分的。

这是我的详细解释:

如果你不是进行非常特殊的项目,或者说你技术非常牛的话,我会认为这可能说明你的代码质量太差。Objective-C是一种非常高级的语言,Cocoa是一个非常完善的框架,用这两者写代码,代码应该很简洁。

我们在做的一个项目,是非常复杂的交互排版系统,支持各种文字绕排效果、视频、Keynote、各种交互,等等等等,代码行数也才2万行。当然这需要了解你的具体情况才能准确评估你的代码是好是坏。如果你在做一个很复杂的项目,比如说,做App的话,各种不同的窗口很多,加入你有1000个不同的窗口,那么代码多点也可以理解。再或者你实现了某种复杂的通讯协议,代码多点也正常。

代码不是一个完美的评估项目的标准。以前有一个故事是说,项目经理用代码行数来衡量工作量。结果程序员就开始增加代码里面的空行,本来函数结果会有一个空行,现在放两个。再后来,有个程序员写了一个编译脚本,每次编译前在代码后面就自动加一个空行,这样有时候就算什么正事儿都不做,光是编译几次,自己的日工作量就可以达标。这些都还是简单的,真的要糊弄人的话,让代码变长的方法很多,比如,可以把一个资源文件,比如图片,转换成一个常量数组,那代码尺寸膨胀的可以想多快就有多快。

但是更多的时候,代码的无序膨胀就是代码编写习惯不好,也没有经过专业的训练。很多年前,我在某公司咨询的时候,见过这样的PHP代码。一个页面几千行,没有任何函数关系,一以贯之。我当时就跟客户的程序员询问他的写代码习惯,他就说按照逻辑一句一句写,遇到类似的逻辑就复制粘贴,这样代码当然就越来越多。我就问他有没有觉得这样写代码很累,他说一点都不累。然后我问他,当代码出了问题,改起来容易么。他就快哭了。然后,我就教他怎么,去把重复的代码凝结成函数,抽取结构和参数,提高复用级别。

这部分听起来很简单,但是实际上,这是一个极端的例子而已,大多数从业者可能知道怎么构成函数,但是在代码里面,仍旧是复用级别太低。也许你是用面向对象的方法去编程,但是基本的逻辑是一样的。

那就是重复的代码,一定要被合并成函数,或者是类的方法。这样首先是节约代码,但是更重要是,结构开始展现,从彻底的面条代码变成有条理,有结构的代码。人的认知能力是有限的,记忆能力是有限的,屏幕尺寸也是有限的。当你把几百行面条代码变成,几个函数以后,首先,你用来理解代码的单元变化了,从大逻辑上,你可以把每个函数当作黑盒子,总体结构就变成,调用几个函数了。然后当发现系统有问题,且你怀疑出在某个函数内的时候,你可以只分析这个函数的输入输出,就可以定位问题是否是在这个函数内。确定后,你修改和去理解的难度也大大降低。

以前有一个原则,叫做重复两次的代码块,必须函数化。一个函数尽量在几十行内。不见得非要100%的严格执行,但是建议认真体会,时刻反思。

写代码的过程应该是,先写厚,然后再写薄。写一段时间就反思一下,实现的结构是否合理,是不是太过冗余。当你的代码总是能保持一定的结构和复用程度以后,代码行数就会是项目规模的良好评估参数了。多一行,就说明逻辑确实复杂了一层。如果形成这样的习惯以后,随着代码量的增长,你的功力自然会加深。

其实写程序,就是一连串逻辑,你可以抽象他们,也可以具象他们,在看全局的时候抽象,可以帮你思考问题,看清big picture,可以理清头绪。当做具体实现的时候,你可以回到具体的细节上,但是,有了全局的抽象结构,你可以只关心一个局部的细节。

刚才我和我们公司主程在商量新产品的开发步骤,我跟他回忆我们之前开发这个2万多行交互排版系统。我说,如果我们一开始,一个模块一个模块的从头做起,一步一步做精,那么也许我们做几年才能做完。但是实际上我们是先把每个模块都定义好,实现了一个空架子,然后一点一点完善。这样有几个好处,第一,这东西是可以持续集成,边开发可以边测试整体效果,可以不段的改进,不需要瞎子摸象。然而,我们实际上,从始至终可以掌握进度,可以看清轻重缓急。这样,这个项目才可为,否则就完全不可控。

当你能顺畅的切换你的抽象层次,你其实就明白了什么是架构。