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