前不久看了场球赛，解说员一个劲说科比打球现在很节省体力，很实用，没什么花哨的动作，用最少的力气投进篮筐，简练实用。

然后前几天微博上参加了一个讨论，博主发了如下的博文

刚工作做新人项目时，我Mentor教育我说代码要写的精简，代码越短犯错的概率越低，代码质量才会越高，我深以为然。最近跟另一个同事结对，他对我说，代码别写的太短，最好每个分支逻辑都单独写出来，即方便阅读，也容易根据每个分支Log查找程序出错原因，我认为他说的也很有道理。于是我就迷糊了。

很多人参与了讨论，我刚刚毕业，做后台开发的时候，讲实话有点扭曲，和其他工程师都在比拼自己的服务能运行几个月乃至一年都不重启，每个可能出错的分支到充分照顾到，一个武装到牙齿的“怪兽型”服务。里面处理各种状态的代码都有，面面俱到。就和科比年轻的时候打篮球一样，各种花哨动作，各种不惜力气。

等年纪再大一些的时候，特别是读博士期间，有点准创业的感觉的时候，一切都变了，我渐渐发现出现了一些新的情况

1）做得东西，常常跑不了多久就要下线了

在大公司往往有比较好的产品设计，做不了多久就下线这种情况还是相对少，但自己搞就不同了，效果不好就废了。那么一个随时可能被废的东西，是不是值得投入那么大代价去做到很精细，还是快速上线，快速验证，快速出结论呢？

2）因为自己一个人搞，全部都自己做，整个系统太过复杂了

比如做爬虫的时候，因为适合外部系统关联的，各种状态，各种情况都要判断，主干部分就越写越复杂，如果把所有可能的状态分支都面面俱到，简直要崩溃。

3）精力的有限

很多时候，在打log的过程中，发现出错了，但是这种出错概率很低，比如在手机上写爬虫，手机经常会莫名起码进入一些神奇的状态，那些确定的状态比如省电状态（低功耗）状态，断网状态这都好办，但有时候就会出现既不是低功耗状态，网络也正常，但就是程序跑出问题，如果在大公司，可以继续深入探究，但创业公司，真心没法这么搞下去，要快速止损。很简单手机定期重启动就行了，能降低大部分这种神奇的情况发生概率，同时即便发生了，重启后，通常都能正常恢复。

当然，我不同意微博的网友提到的代码越短，质量越高的说法。我只能说在特殊的情况下，可以接受存在问题的代码，可以接受不考虑一些状态分支的代码。不要过于的花大量精力在一些低概率发生的事件上，很多高概率发生的问题还没解决，就不要去尝试解决一些低概率出现的错误。等到有余力的时候，再做也不迟。

有人说可以持续做代码重构，是的，代码重构是一个好方法。重构通常是解决了代码的结构和可读性问题，重构后代码通常会变短，变精简，一方面是合并了一些公有的东西，一方面是去掉了一些“死代码”。所以在有条件的情况下，定期重构是必要的，据一个谷歌的朋友说，他们的系统几乎每年都要升级重构一次，一方面是让代码的可读性提高，另一方面是一次性考虑更多的功能和性能需求，整体做一个提升。

不过说归这么说，我刚看了我分词的那段代码，从刚开始上线到现在，一开始还吹牛很少if-else，现在看看，不知道多少if-else了。比如处理人名地名的情况，比如处理各种复杂的切分残差情况，不同情况的处理还不同，处理的结果还需要反馈，真心是维护很多状态分支的代码太痛苦了。

也欢迎大家对这个问题各抒己见，欢迎投稿给我们，联系我们的编辑Pennyjob