我们工作的最基本目标是，保证工作单位的项目能够如期交付，至少要保证自己的进度。一份薪水，一份责任。
此外，作为技术工作者，我们也有自己的技术追求，提高敲代码的能力，写有含金量的代码。保证自己的能力能够与时俱进。
功能优先，进度就是最直接的要求。对于有可视化界面的项目来说，功能能跑通更是最主要的。Boss看不到界面和功能能够正常执行，是不能清楚地知道你的进度了。
客户看不到界面。就等于未完毕。人最怕没有进度条，仅仅能焦急地等待。
下游环节。比方功能測试等，不到完毕的功能交付，真正的測试工作就无法開始（測试用例能够提前编写）。
重构与开发并举， 项目开发过程中。重构非常重要。前期的设计再具体，不到实际动手编码。非常多问题的细节，你是考虑不到的。因此，代码功能尽管完毕了。可是常常存在思路不清楚、代码反复等小问题。所以，开发完一个小功能。重构一下。比方提取清除不必要的暂时变量、取个更准确的方法名称、提取公共的逻辑为工具方法等。
而在后期。大的重构则要谨慎。主要是这个时候。重构与项目质量与项目进度可能冲突。
尤其是对项目负关键责任的经理等人，不希望在交付前期。出现差池。
性能殿后，不是说性能不重要。而是说性能不好衡量，在项眼下期和运营前期，性能不好向客户等角色阐述它的价值。此外。非常多项眼下期对性能的要求根本不会太高，仅仅要不乱写代码。性能应付前期通常是能够的。
非常多项目，比方针对普通消费者(to-c) 的项目，前期可能就对性能有明白要求。针对这样的情况，我认为：项目的架构设计、代码组织、数据库设计。仅仅要保证结构清楚和业务清楚，后期优化是非常easy的，基本不会对代码的总体结构有大的改变。比方添加缓存，不会对核心业务有修改。
以上是大道理。以下以我近期的项目开发经历， 再谈谈一点体会。
项目。后端是个管理系统，从后台读取数据，然后显示当前用户能够操作的菜单。
功能优先，我们有3个开发，同一时候进行编码。
菜单是项目最主要的，没有菜单，开发測试非常不方便。所以非常迅速简洁地把权限和菜单做了出来。
开发与重构并举，近期主要功能完毕了，我想对菜单这块进行重构。
曾经为了优先保证总体进度，菜单相关表存储了一些额外的数据。感觉比較多余，并且要完毕新的功能，又须要编辑这张表的数据。手动维护冗余字段，给新功能带来了额外的工作量。
所以，我认为先重构，再完毕新功能。
但在重构中，我范了“编码之大忌”，这是一个反面典型案例。
我一边完毕正常功能、一边为了保证程序的性能。写了不少功能之外的代码。
大概是这样。把List集合转换成Map格式的Tree树。写的是递归算法。
本来递归，对思考逻辑就要清楚，为了性能。多写了推断“提前返回” 的优化代码。
结果非常慘。优化代码写得不准确，导致最后的菜单数据。不出来、数据不完整（提前返回导致的）。
事后反思，我认为写代码的时候。尽量先专注一件事。 逐个击破比較好。把功能正确实现，在写的过程中，假设有疑问，比方数据校验、性能之类，能够先写个"TODO：须要优化"，等功能測试通过，再搞下一个。One by one, it is good.
雷观：小雷FansUnion的个人观点。欢迎互动交流
2014年12月15日
湖北-武汉-循礼门