今天一朋友问我这边一个项目大概有多少行代码，我一脸茫然毫无概念，后来在百度上搜索了一下代码行数统计一行命令就查询出来大概4W行，紧接着一个新的问题出现了，4W行代码对于一个项目是多还是少，我该如何回答他，于是我又百度了一次。
我这边的项目的IOS项目，开发方式（SB + XIB + 代码）混搭，以开发效率为主。主要是SB为项目主体架构，XIB实现公用自定义视图，代码写简单UI及逻辑代码。这也是我个人开发几年总结下来最有效率的开发方式，虽然可能被很多纯代码开发者耻笑，认为SB或XIB难维护还影响运行效率，但我觉得适合自己的才是最好的。
好了不扯远了进入正题，首先查询代码量的命令是
find . -name "*.m" -or -name "*.h" -or -name "*.xib" -or -name "*.c" |xargs grep -v "^$"|wc -l
我查询到了4.8W行代码，然后我又在Pod目录下面运行了一次得到了2.2W行，也就是实际代码量差不多有2.6W行代码。我带着这几个数据和模糊的概念又百度了一次。
我搜到了知乎上的一个话题4个月写了4万行iOS代码，算多还是少呢？这是一个过去很久的话题，但我觉得点赞数最多的这个评论说的很有借鉴意义。
代码不是一个完美的评估项目的标准。以前有一个故事是说，项目经理用代码行数来衡量工作量。结果程序员就开始增加代码里面的空行，本来函数结果会有一个空行，现在放两个。再后来，有个程序员写了一个编译脚本，每次编译前在代码后面就自动加一个空行，这样有时候就算什么正事儿都不做，光是编译几次，自己的日工作量就可以达标。这些都还是简单的，真的要糊弄人的话，让代码变长的方法很多，比如，可以把一个资源文件，比如图片，转换成一个常量数组，那代码尺寸膨胀的可以想多快就有多快。
但是更多的时候，代码的无序膨胀就是代码编写习惯不好，也没有经过专业的训练。很多年前，我在某公司咨询的时候，见过这样的PHP代码。一个页面几千行，没有任何函数关系，一以贯之。我当时就跟客户的程序员询问他的写代码习惯，他就说按照逻辑一句一句写，遇到类似的逻辑就复制粘贴，这样代码当然就越来越多。我就问他有没有觉得这样写代码很累，他说一点都不累。然后我问他，当代码出了问题，改起来容易么。他就快哭了。然后，我就教他怎么，去把重复的代码凝结成函数，抽取结构和参数，提高复用级别。
这部分听起来很简单，但是实际上，这是一个极端的例子而已，大多数从业者可能知道怎么构成函数，但是在代码里面，仍旧是复用级别太低。也许你是用面向对象的方法去编程，但是基本的逻辑是一样的。
那就是重复的代码，一定要被合并成函数，或者是类的方法。这样首先是节约代码，但是更重要是，结构开始展现，从彻底的面条代码变成有条理，有结构的代码。人的认知能力是有限的，记忆能力是有限的，屏幕尺寸也是有限的。当你把几百行面条代码变成，几个函数以后，首先，你用来理解代码的单元变化了，从大逻辑上，你可以把每个函数当作黑盒子，总体结构就变成，调用几个函数了。然后当发现系统有问题，且你怀疑出在某个函数内的时候，你可以只分析这个函数的输入输出，就可以定位问题是否是在这个函数内。确定后，你修改和去理解的难度也大大降低。
以前有一个原则，叫做重复两次的代码块，必须函数化。一个函数尽量在几十行内。不见得非要100%的严格执行，但是建议认真体会，时刻反思。
写代码的过程应该是，先写厚，然后再写薄。写一段时间就反思一下，实现的结构是否合理，是不是太过冗余。当你的代码总是能保持一定的结构和复用程度以后，代码行数就会是项目规模的良好评估参数了。多一行，就说明逻辑确实复杂了一层。如果形成这样的习惯以后，随着代码量的增长，你的功力自然会加深。
其实写程序，就是一连串逻辑，你可以抽象他们，也可以具象他们，在看全局的时候抽象，可以帮你思考问题，看清big picture，可以理清头绪。当做具体实现的时候，你可以回到具体的细节上，但是，有了全局的抽象结构，你可以只关心一个局部的细节。
刚才我和我们公司主程在商量新产品的开发步骤，我跟他回忆我们之前开发这个2万多行交互排版系统。我说，如果我们一开始，一个模块一个模块的从头做起，一步一步做精，那么也许我们做几年才能做完。但是实际上我们是先把每个模块都定义好，实现了一个空架子，然后一点一点完善。这样有几个好处，第一，这东西是可以持续集成，边开发可以边测试整体效果，可以不段的改进，不需要瞎子摸象。然而，我们实际上，从始至终可以掌握进度，可以看清轻重缓急。这样，这个项目才可为，否则就完全不可控。
我很赞同这段话，也一直尽可能的这样去做，也尽可能的把OOP的思想展现到项目中去。但回到现实中来看公司中的项目细思极恐。
路漫漫其修远兮，吾将上下而求索。
于是我告诉他有4W行代码，毕竟朋友觉得我成天在键盘上敲敲打打和码字员没什么区别，行数越多越厉害嘛~😂😂😂😂
