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