转眼2017，首先在这里祝您鸡年大吉/*吧*/。

回想初到南京那会，15年夏天，还是抱着换换口味想要新鲜感的心情加入了现在这家创业公司。刚摆脱了一团乱麻一般的代码的我心情愉悦，工作学习特别带劲，一个礼拜能做十几个feature。然而现在看看自己过去十几个月里参与的项目。。只是一团稍显整齐的乱麻而已，终究还是乱麻。

我可以说我编写的代码依旧遵守着我给它们的秩序，但是你没法指望别人都这么做，同样别人也没法指望我那么做。尽管我在修改前人所写的代码的时候极力保持了同样的风格，但是如果前人压根就没考虑过可扩展性以及高复杂度下的可读性——比如一个if else块300多行，你再怎么保持都没用。给臭的东西喷香水只会让味道变得更恶心。

一般在这个时候我们都会说，该重构了。没错，每个工作日我内心都有100个声音在说重构吧重构吧。道理我都懂，但是看着越来越近的deadline和还没做完的二十几个feature，实在是没有底气和领导说我能在保证新功能测试时间的前提下完成重构，老板也不会在我们说要把新功能放一放先做点看不出效果的重构以后给我们好脸色看。

是的，有种陷入恶性循环的感觉。假如我是我领导，现在应该挺骑虎难下的。

为了有更直观的感受，先来说说我们主站项目里几个大概的数字吧。

客户操作（如关注购买等）api数： 100-200

客户操作api的文件数：5个左右

上述文件中最大一个的代码行数：30k行以上

上述文件中class数：0

如果让一个其他公司的同行来做代码审查，过程中骂出的脏话估计够把全上海人都骂一遍。

但是我们不知道这是不对的吗？不，我们知道，我们清楚的知道，这也是我在15年为公司做的内部系统里采取完全不同设计的主要原因——旧代码太乱了，我想看得清楚一点。但是为什么我们明明知道但是没有去做呢？

测试，测试，测试。重要的话说三遍，我们没有足够的测试覆盖率，因此也就没法保证重构的效率。我不知道我同事没有去做的原因是什么，反正我自己每每要尝试重构的时候，测试这两个字都像是在我面前的拦路猛虎。或许这与领导的风格有关，团队最初建立的4个月里我没有参与到，在我加入时大家对测试的要求都是自己测一测，保证功能没问题就赶紧投入到下一个功能里。现在想想，我真是欠我的代码，我的领导，看这篇文章的所有人，以及我自己一个大大的道歉。我的前一份工作是一个测试难度颇大的项目，UI代码和AI代码都是难以编码测试或是依赖太多外部条件没法确定明确的输入输出的，多数也都是跑一下看看没问题就过了。于是我也就把这份惯性思维带进了网站后台的开发里。犯了如此愚蠢的错误真是对不起，让你们瞎眼睛了。

毕业之初，我对测试的概念还是在保证功能正确无误的工作的程度。但你现在要我说的话，测试不仅仅是保证你所写的代码正确无误，这也是日后给你自己，你同事，接替你代码的人的一份重要保证，是你敢修改代码的底气。不知道大家是否有犯过这样的嘀咕：我改了这里以后会不会出BUG？我也经常会这么问自己，当别人问我改完会对旧功能造成影响吗？我往往需要深思熟虑一番，把这段代码的各个调用点都找出来核对一下才敢给出确定的回复。

这番体会在有些人看来估计会很幼稚。没错，在我想明白之后我也觉得很幼稚，以往看过各种大牛的文章，没有一个人说测试不重要的，然而却花了我这么久才有自己的体会，真是难为情。不过这同时也引出了另一个问题，有了测试就万无一失吗？或者换个方式，要怎样做测试才能万无一失呢？

知乎有句话叫抛开剂量谈毒性都是耍流氓，我们在谈重构和测试的时候，抛开编码也是耍流氓。在写代码的时候我们就要秉持着“可测试”的模式而去。什么叫可测试的模式呢？就是精简模块与单一功能。这概念很多年前就被说烂了，但是随着阅历增加每年都能有新的体会。前面说我在写内部系统的时候采用了完全不同的设计也是使用了这个思路。主站项目里一个大类的所有模块都揉在了一起。比如客户端相关的功能就全都在同一个叫Customer的app下，后台逻辑全都在同一个views里（没错就那个30k行的）。而内部系统采用了一个模块一个app的设计，例如客服-反馈管理一个模块，客服-订单管理一个模块，财务-退款审核一个模块等等。这么做的好处是每次你打开一个文件，你所需要考虑的只有极少的事情，从而可以提高做事效率。同时保证模块里每一个小函数都只做一件事情，这样就又免去了不小心动到其他功能代码的困扰，同时，测试代码写起来很方便。所以说好的编码可以帮你做出好的测试。

内部系统持续迭代了一年多，到目前我惊讶的发现没有重构的必要。因为各个模块都分得很清楚，也很细。但是，事情总有个但是，模块分得太细了导致其他同事认为不管新增什么功能都要新增一个app。举个例子，现在线上活动越来越多了，我有专门建立过一个app来处理各类活动——因为活动是有时限性的，通常做过一次就不会再需要了，所以可以放一起。但是当某一天我同步了其他同事的提交后我还是无语了，他也新建了一个app专门处理17年新春活动。但这不是主要的，反正活动结束了把代码归档就好了。更主要的是，他虽然模仿了我的风格，但是没有理解我的意图。就在那一刻我意识到了以后还可能出现元宵节活动，情人节活动，展馆A活动，展馆B活动等等大大小小的活动，都以一个app的形式出现在项目根目录里，而不是我最初用来处理活动的app里。我不禁背后感到一丝凉意，虽然这件事和同事沟通一下就可以了，但是让我感到恐慌的是今天是我同事，明天可能就是我了。我修改旧代码时虽然极力保持了一致的风格，但那也只是我认为的风格，而对于整个项目来说这样真的无害吗？我是在帮助整个项目更有序化还是更无序化了呢？

或许这需要更高层的把控，每隔一段时间就要对整个项目做一次评估来确定重构的规模。但是，这世界上怎么这么多但是，重构前也要考虑这些时间花下去是不是划算？曾经和领导交谈的时候有说过，对于稳定而陈旧的代码是否真有重构的必要？长时间下来都是小修小改，重构完也只不过是让我们自己看着舒服罢了，对于非技术出身的老板来说重构更是一件吃力不讨好的事情。花了时间，取得了什么效果吗？有效果，但是看不出来 = 没效果。当然作为程序员我们比任何人都清楚重构的重要性，但是我们不能眼里只有技术。

十几个月的过程感受下来，程序员还是要有对技术之外的理解，比如商业需求之类的。有时候运营人员或者是PM来和我们谈需求的时候，我们认为的愚蠢需求其实是有其商业价值的，只不过对方在转化的时候没能帮我们解释清楚，到最后我们的一句做不了或是没意义可能就错失了机会，尤其是对于一个运营不成熟的团队。对于系统的理解我们是高过他们的，但是对于用户的理解，还是要相信他们的判断。

罗罗嗦嗦一大堆，自己都觉得自己太怨天尤人了。程序员还是要做实干派，有问题就要解决，有BUG就要修，不能单单纸上谈兵。希望2017能让自己成为一个更优秀的人，年后要考虑回上海工作了，相比15年走的时候我有没有变更好呢？

世界太广太大，我连好的边缘都够不上。只有那一亩三分地，略有收获而已。