我理解的代码重构与完美思想

 

 

说说代码重构

 

公司项目初期,在很长一段时间内，并没有认真做好工作量的时间安排表。往往是早晨开个会，简单描述下任务，下午就最好能把模型给出来，甚至要求高的是当天做完，第二天可以展示给用户练手。 当年在阿里服装ERP组的时候，老板就是这么要求的。老板的出发点就是那样，追求极致的用户体验（此处应当是交付体验）。当技术资源不够时，我们底下做事情的人，往往就是偷工减料（当然不是制造 Bug，而是设计模型时偷懒，命名等不规范），要不就要加班，甚至爱有时候即便偷工减料了，还当天完不成。 可是说这样的编程产出的作品，和流水线工人无异，堆砌的代码，因为设计不清晰，缺少规划，等到用户不满意返工时，又要重做，而之前的产出，却不能被复用，劳心劳力。 所以，留给我们编码的最佳方案就剩 2 个： 1）重设计 2）要重构 重设计，一开始就能考虑各类应用场景，以及异常错误，做好完整的测试，接下来的任务再改变，基于之前设计基础，做修改会顺畅很多。 要重构，在设计这关缺失的情况下，我们对自己的代码负责，唯一途径就是通过重构，而且是及时的重构。当项目完成时，如果没有重构完毕，那么之后再重构也有心无力了。首先开发、测试资源人手都没了；第二，重构完毕也不知道是否有漏掉的业务实现；最后，重构未必有人肯买单，当系统好用的时候，开发或者用户都排斥无意义的改造，我们说服不了他们。

 

 

野蛮生长

 

 

我父亲多年前开办公司也有点项目初期赶工的味道。只要业务是正常进行，且账目流水是在增长的，并没有开设过多的部门去优化公司业务开展流程，比如财务、人事、战略 等。而是统统几个合伙人自己上，一把梭，什么都要自己干。上了轨道之后，才开始定制公司章程、财务人事分开。 和项目开发初期到成熟期一个样。没有设计图纸，没有文档，没有测试，没有架构。写具体的代码也一样，你要是一开始就要讲究各类规范，时间就那么多，根本玩不起来。呆呆的想一个下午怎么优雅的写好类，写好继承，半天可能还动不了手，结果自己就先慌了。 如果入行尚早，与其冥思苦想，不如一气呵成把代码写完，再慢慢改。养成这个习惯后，一来你会重复去读业务逻辑，评代码实现，二来可以积累实践方法，用于下次项目的实施。

 

警惕完美思想

 

 

在台湾，日本的街头，经常给人的感觉是干净，整齐。哪怕是一排自行车，做到头就是头，尾就是尾，头与头在一条水平线上，尾和尾同样也基本保持一条水平线。不知道他们是故意做到这么变态的严格，还是做不到就会有罚单。总之，作为游客看上去，非常整齐，舒服。这一点，哪怕在综合素质较高的上海，也不多见。尤其有了共享单车，那怎能用一个乱字形容！

 

 

 

 

 

 

我们很多时候用工匠精神来形容追求完美的行为。 但今天我想说的是，我们千万不能硬搬这个匠人精神来处理工作或者学习。就像前面我在谈起写代码的时候，如果要考虑到完美精神，尤其是一次成型就做到完美的奢求，不仅仅会给自己的项目造成延迟，失去早期占领市场的机会，还会给我们内心追求成事带来一定的心理压力。 不得不说，通过观察很多程序员，他们最大的特点是执着追求者完美。追求没有 Bug, 追求高性能，支持高并发，哪怕他所负责的项目就是那么几百个人用，也还在痴痴地追求这里要复用，这里要符合设计模式，这里的数据库架构要分布式，要读写分离。 当做练手项目，无可厚非。但如果是靠市场做产品，这么讲究，必须还得考虑IOR,即投资回报率。曾几何时，我也这么追求。首行必须缩进，括号必须对齐，哪怕是 ER 图，虚线与实线就要严格分开，必须采用第三范式，必须要用驼峰命名，总是，就是必须的。

 

直到2012年有一次项目裁员，我才明白，我的位置本质上是项目给的，而非我个人技术

 

如果公司不在合理的时间推出新的产品，你的顾客就要转身投向你的竞争对手；如果项目跟不上公司的发展要求，不产生效益，就要被砍。在每个岗位上，我们要注意的是正确评估公司产品、项目的收益、周期，在合理的时间段内追求完美的品质。

 

过度追求完美，会败给时间。

 

剩下一种可能，通过迭代去打造完美的产品，是可行的, MVP(Minimum Valuable Product) 即最小化可用产品。用MVP去市场试水，发现有利可图的产品落脚点，再开动马力全面出击，设计与优化并行，最终为产品赢得市场空间。