保持代码生命力 管理资料_第1页
保持代码生命力 管理资料_第2页
保持代码生命力 管理资料_第3页
保持代码生命力 管理资料_第4页
保持代码生命力 管理资料_第5页
免费预览已结束,剩余1页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

保持代码生命力 管理资料 代码是架构师和开发者共同的产物,在公司目前这种迭代式开发和需求多变的情景下,关键代码往往会被多个项目,多个程序进行多修改, 一、良好的设计。 一个良好的设计是保证代码质量的第一因素。设计就是对业务需求模型的抽象,对需求把握的准确与否,直接决定了设计的成败。在项目中,我们往往在寻找一些业务名词,如APP、ISV、USER、保证金、月租、订单、红包、有效期、平台等等,一些动词,如接入、订购、付费、退订、上架、下架、审核、共享、服务等等,还有之间的一些关系连线,状态迁移,数据流向等,这些就构成了我们的业务体系,再结合我们常用的SAAS平台图谱,就组成我们的架构体系。我们设计,就围绕这些点铺开。我们使用前人总结出来的多种设计模式或是设计原则来抽象,隔离变化,以便使我们的设计易扩展、可维护、健壮、职责单一,在项目迭代中保持顽强的生命力。 1、设计尽可能简单。简单是为了面对变化时有更多的选择; 2、遵循面向对象设计原则:单一职责原则、开放-封闭原则、里氏替换原则、依赖倒置原则、接口隔离原则; 3、设计的本质是抽象,目的是隔离变化。项目中我们经常发现,反复修改的地方往往就那几个,基本上都是在前面提到的使用动词的地方。 二、统一的编码规范。 统一的编码规范是高质量的保证。从机器码到高级语言的变迁,从过程式编码到面向对象设计,从小作坊式编码到多个团队的协作,这种软件变迁无一不证明可读性、易维护性的重要性。只有机器能懂的代码在现在大型的项目中实际上是没有价值的。一般来说,我们的项目组都有一个比较详细的编码规范可供参考,同时我们的软件过程中也有code review来保证规范的执行,TM或专人 review,团队交叉/结对review的方式,或是两者相结合的方式都是可行的。特别是结对,规范和一些技能能够快速地在团队新老成员之间传播,在编码风格上也比较容易统一。 三、组件化。 组件化是提高代码质量的有效方式。前面提到设计中的抽象和变化隔离,这其中不变的部分和公共的部分可以被组件化。组件按业务的相关性可以分为工具类和业务类组件。我们项目中常用的Utils,第三方包,包括工程中提取出来的一些UI组件,界面元素工具,校验工具,过滤工具,接口调用工具等都属于工具类,公共服务,API,CORE,以及一些业务封装属于业务组件。不论哪一类组件,都是封装变数,重用代码的方式,大大提高了系统稳定性。 四、单元测试, 单元测试其实是个好东西,但是一直都难于执行。原因可能是,可做可不做当然不做更简单,项目很紧,有投入没收益,没有好的方法或框架对单元测试支持不好,原因很多,值得讨论。我觉得,TDD是一种很理想的保证代码质量的方法: 1、测试用例中直接和程序的期望效果关联的断言,明确了程序的内含和外延,使程序输入输出有序,不至于产生所谓“灵异事件”; 2、编写单元测试必须考虑代码的可测性,这其实也就约束了上帝方法的出现,使代码结构更合理,重用性也更好; 3、直接的好处是不用起容器,间接的好处是调试时方便定位问题所在,提高跟踪的效率。这为开发人员调试代码节省了大量时间; 4、单元测试可重复执行,代码修改者易于从测试用例中找出编写者意图; 5、给开发者好的体验。绿条带信,红条发现问题。 五、大胆的重构。 重构必须加上大胆。因为业务变更、代码迁移、代码反复修改、一些为修复BUG而产生的临时性代码等等多种原因,造成了代码易于在迭代中腐化。这是一个非常值得关注的问题。前段时间因项目需要对原来的admin portal进行迁移,在阅读他人编写的代码中,发现了很多不好的地方。比如说重复的类,未实现的方法,废弃的方法,因为增删而产生的垃圾代码,大段大段的不知所以的代码段注释,和当前业务完全不相干的代码,”from app center”之类整段整段的拷贝。这些,都使代码变复杂,难懂(像为了防止他人读懂拷贝而混淆过的代码;D)。像这种问题,基本上都是在项目迭代过程中产生的。问题是不可避免的会遇到,关键是,我们有什么方法可以应对它。让项目永葆青春的方法就是重构。 重构的时机。重构的前提条件是在可控的范围之内。重构和重写不一样,不是一下子铺得很开以至没法收场,也不是改头换面,引出其它地方的问题。重构总是在不改变外部形式的前提下,对内部进行改造,使内部结构更合理。“内部”“外部”我想也没有一定的范式,可以是方法内、模块内,总之是要在可控制范围之内。重构过的部分也需要单元测试和回归测试。这里的时机,我觉得是:当你去修改某段代码感觉到了坏味道,在你完全理解了原有代码的全部意图之后,并且,项目中会有QA来进行回归测试的情况下。 重构需要勇气。我们有个愿望是我们的项目更健康,最大限度体现商业价值。重构的勇气就是于这个美好的愿望。一个苹果本来是好的,可能因为某个小的污点,它便慢慢腐化,一直到某一天我们意识到问题很严重了,为此付出更大的代价。 总的说来,上面的实

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论