Share_Week5-制定项目规划

最近在负责公司的一个项目,颇多感悟,一一记录一下。
*项目情况

  1. 这是一个老的商用项目
    老项目一般都有一个共通的问题:维护成本很高。因为存活时间太久,经手太多人。如果没有一个统一的约定代码风格,可读性会很差。再加上项目只追求完成业务逻辑,不考虑或者不敢重构,因为怕影响现有逻辑,同时不考虑代码执行效率,只要项目可以跑,完成业务逻辑就可以。代码行间各种坏味道。

  2. 没有注释或者过多注释
    关键的函数注释太少,或者注释并没有随着项目代码的变更而更新。更常见的情况是,随处可见、层层叠叠的“BEGIN: add by xxx”,”END: add by xxx”, 极度影响代码的阅读和理解。不理解为啥有了git作为代码管理工具了,还需要写这么多谁修改的用意何在?!

  3. 项目缺少文档或者文档过时
    文档对于项目开发来说很重要,让开发者知道需要把系统开发成什么样;让维护项目的工程师知道整个系统的业务和代码逻辑,便于结合源码深入理解整个系统。但是这个项目文档实在很随意,要么就是没有,缺少帮助新手快速理解系统并上手干活的资料。对于项目里涉及的一些软件和流程缺乏一个很系统的指导书,要么就是虽然有,但是很久没有更新,只能辩证的看…

  4. 项目的概要设计过于简略
    接手项目进行迭代开发时候适逢项目详细设计阶段。作为一个新人,我手上的概要设计的文档是由一个不懂代码的需求工程师完成的,对于业务逻辑的描述粒度不够,或者根本不涉及。详细设计阶段我需要参考其他模块的文档来理解负责模块的概要设计,然后在不理解业务和没有系统运行环境的情况下,光啃代码去完成详细设计。要命的是,需求工程师因为不懂代码,需求实际所需时间和预定时间差太多,代码量是预估的2倍,交付时间不变,期间还要参加公司的培训、完成一系列考核…

  5. 单元测试是为了应付指标达标
    项目也有单元测试,要满足行覆盖率80%以上。但是,项目紧、维护难、人手少,单元测试的指标最终也是应付了事。函数基本mock,并没有起到单元测试原先的作用。

  6. 项目的计划再三变更
    上面领导一声令下,下面的人就开始动起来垒代码。做了一半,领导拍了个脑袋说,这个方案不行啊。于是,代码开始回滚,从代码库里删除。之前几个月的努力泡汤。过几天,另一些领导开始拍大腿,不能白做了几个月,至少得要交付一个最小的子集模块,于是继续开始搬砖。紧接着,来了个更急的任务,所有编码工作暂停,所有人员转移到新任务去,因为之前那个任务很有可能不做或者要做,谁也不知道,但是现在手头新项目是权重最高的,那么,开始做吧。等着上面哪位领导继续拍脑袋或者大腿…

反思

  1. 根据敏捷开发的作法,越是这样老的系统,越需要在下一次的迭代开发的过程中重构优化,小步走,保证单元测试覆盖率,提升系统可维护性。
  2. 注释和文档一样重要,尤其是一些关键函数,如果过时的注释,还不如没有注释,否则只会误导后人。
  3. 文档的维护和更新要随着项目同时进行,并且需要有一个统一的地方去堆放相关的项目文档视频等资料,且需要有一个索引方便后人查找。
  4. 概要设计是后续详细设计的基础,如果前期做的不够好,后面就有可能出问题,导致详细设计中某些点考虑不全或者功能点遗漏。后期发现再来补救的成本就要高很多,得不偿失。项目开发交付周期的制定需要科学严谨,既满足客户的需求也要考虑实际情况,不是一拍脑袋就出结果。
  5. 单元测试和集成测试不是摆设和给上面交代的指标数据,如果做不到函数功能代码逻辑的覆盖,只能是形同虚设。
  6. 计划要科学,前期没有调研清楚就做做看的想法,只会浪费时间和金钱。制定一个计划同时也反映了一个领导的能力和远见,希望少拍几次脑袋和大腿,你不疼,我加班加的还疼呢…
------本文结束感谢阅读------
坚持原创技术分享,您的支持将鼓励我继续创作!
显示 Gitment 评论