雷观(十三):功能优先,开发与重构并举,性能殿后
雷观(十三):功能优先,开发与重构并举,性能殿后
FansUnion 发表于2年前
雷观(十三):功能优先,开发与重构并举,性能殿后
  • 发表于 2年前
  • 阅读 4
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 十分钟定制你的第一个小程序>>>   

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

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

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

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

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

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

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

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

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

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

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


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

版权声明:本文为博主原创文章,未经博主允许不得转载。

共有 人打赏支持
粉丝 52
博文 857
码字总数 825464
×
FansUnion
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: