功能优先，进度就是最直接的要求。对于有可视化界面的项目来说，功能能跑通更是最主要的。Boss看不到界面和功能能够正常执行，是不能清楚地知道你的进度了。

客户看不到界面。就等于未完毕。人最怕没有进度条，仅仅能焦急地等待。

下游环节。比方功能測试等，不到完毕的功能交付，真正的測试工作就无法開始（測试用例能够提前编写）。

  重构与开发并举， 项目开发过程中。重构非常重要。前期的设计再具体，不到实际动手编码。非常多问题的细节，你是考虑不到的。因此，代码功能尽管完毕了。可是常常存在思路不清楚、代码反复等小问题。所以，开发完一个小功能。重构一下。比方提取清除不必要的暂时变量、取个更准确的方法名称、提取公共的逻辑为工具方法等。

而在后期。大的重构则要谨慎。主要是这个时候。重构与项目质量与项目进度可能冲突。

尤其是对项目负关键责任的经理等人，不希望在交付前期。出现差池。

性能殿后，不是说性能不重要。而是说性能不好衡量，在项眼下期和运营前期，性能不好向客户等角色阐述它的价值。此外。非常多项眼下期对性能的要求根本不会太高，仅仅要不乱写代码。性能应付前期通常是能够的。

  非常多项目，比方针对普通消费者(to-c) 的项目，前期可能就对性能有明白要求。针对这样的情况，我认为：项目的架构设计、代码组织、数据库设计。仅仅要保证结构清楚和业务清楚，后期优化是非常easy的，基本不会对代码的总体结构有大的改变。比方添加缓存，不会对核心业务有修改。

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

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

   功能优先，我们有3个开发，同一时候进行编码。

菜单是项目最主要的，没有菜单，开发測试非常不方便。所以非常迅速简洁地把权限和菜单做了出来。
   
   开发与重构并举，近期主要功能完毕了，我想对菜单这块进行重构。

曾经为了优先保证总体进度，菜单相关表存储了一些额外的数据。感觉比較多余，并且要完毕新的功能，又须要编辑这张表的数据。手动维护冗余字段，给新功能带来了额外的工作量。

所以，我认为先重构，再完毕新功能。

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

  我一边完毕正常功能、一边为了保证程序的性能。写了不少功能之外的代码。

大概是这样。把List集合转换成Map格式的Tree树。写的是递归算法。

本来递归，对思考逻辑就要清楚，为了性能。多写了推断“提前返回” 的优化代码。

结果非常慘。优化代码写得不准确，导致最后的菜单数据。不出来、数据不完整（提前返回导致的）。

  事后反思，我认为写代码的时候。尽量先专注一件事。 逐个击破比較好。把功能正确实现，在写的过程中，假设有疑问，比方数据校验、性能之类，能够先写个"TODO：须要优化"，等功能測试通过，再搞下一个。One by one, it is good.


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