tinyfool

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

这是我的详细解释：

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

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

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

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

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

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

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

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

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

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

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

http://tiny4cocoa.com/thread/show/1739/