根据自己2年多的实际开发经验，我认为：在项目开发过程中，功能是最优先的，开发与重构同样重要，性能放后面考虑。

    我们工作的最基本目标是，保证工作单位的项目能够如期交付，至少要保证自己的进度。一份薪水，一份责任。
此外，作为技术工作者，我们也有自己的技术追求，提高写程序的能力，写有含金量的代码，保证自己的能力能够与时俱进。

   功能优先，进度就是最直接的要求。对于有可视化界面的项目来说，功能能跑通更是最基本的。Boss看不到界面和功能可以正常运行，是不能清楚地知道你的进度了。客户看不到界面，就等于未完成，人最怕没有进度条，只能焦急地等待。下游环节，比如功能测试等，不到完成的功能交付，真正的测试工作就无法开始（测试用例可以提前编写）。

  重构与开发并举， 项目开发过程中，重构很重要。前期的设计再详细，不到实际动手编码，很多问题的细节，你是考虑不到的。因此，代码功能虽然完成了，但是经常存在思路不清楚、代码重复等小问题。所以，开发完一个小功能，重构一下，比如提取清除不必要的临时变量、取个更准确的方法名称、提取公共的逻辑为工具方法等。而在后期，大的重构则要慎重。主要是这个时候，重构与项目质量与项目进度可能冲突。尤其是对项目负关键责任的经理等人，不希望在交付前期，出现差池。

性能殿后，不是说性能不重要，而是说性能不好衡量，在项目前期和运营前期，性能不好向客户等角色阐述它的价值。此外，很多项目前期对性能的要求根本不会太高，只要不乱写代码，性能应付前期一般是可以的。
  很多项目，比如针对普通消费者(to-c) 的项目，前期可能就对性能有明确要求。针对这种情况，我觉得：项目的架构设计、代码组织、数据库设计，只要保证结构清晰和业务清晰，后期优化是很容易的，基本不会对代码的整体结构有大的改变。比如增加缓存，不会对核心业务有改动。

  以上是大道理，下面以我最近的项目开发经历， 再谈谈一点体会。

  项目，后端是个管理系统，从后台读取数据，然后显示当前用户可以操作的菜单。

   功能优先，我们有3个开发，同时进行编码。菜单是项目最基本的，没有菜单，开发测试非常不方便，所以非常迅速简洁地把权限和菜单做了出来。
   
   开发与重构并举，最近主要功能完成了，我想对菜单这块进行重构。以前为了优先保证整体进度，菜单相关表存储了一些额外的数据，感觉比较多余，而且要完成新的功能，又需要编辑这张表的数据。手动维护冗余字段，给新功能带来了额外的工作量。所以，我觉得先重构，再完成新功能。

  但在重构中，我范了“编码之大忌”，这是一个反面典型案例。

  我一边完成正常功能、一边为了保证程序的性能，写了不少功能之外的代码。大概是这样，把List集合转换成Map格式的Tree树，写的是递归算法。本来递归，对思考逻辑就要清楚，为了性能，多写了判断“提前返回” 的优化代码。结果很惨，优化代码写得不准确，导致最后的菜单数据，不出来、数据不完整（提前返回导致的）。

  事后反思，我觉得写代码的时候，尽量先专注一件事， 逐个击破比较好。把功能正确实现，在写的过程中，如果有疑问，比如数据校验、性能之类，可以先写个"TODO：需要优化"，等功能测试通过，再搞下一个。One by one, it is good.


雷观：小雷FansUnion的个人观点，欢迎互动交流
2014年12月15日
湖北-武汉-循礼门