纸上得来终觉浅,绝知此事须躬行 陆游

10月底以来,加班频繁,写代码经验也积攒了不少,择其要点,简单梳理下

第1类 工作方法

第1-1条 自底向上

接到任务需求后,分析清楚业务,认认真真设计表结构,按照『表结构 – META类 – DAO类 – Service类 – 业务代码』的顺序按部就班地实现

表结构很重要,功能、性能、扩展性、兼容性都要考虑;表结构一旦确定了,就不可以随意改动了

第1-2条 不能偷懒

一个功能、一个模块,在实际项目中,绝不会是一锤子买卖,后续必定有各种各样的新需求、优化等;一开始做的时候,就老老实实把Dao、Service、缓存、单元测试等必要的基础代码写好

只要偷懒,用不了多久,后面还得连本带利补上

第1-3条 点滴重构

重构不一定非得大动干戈,有时候看到坏味道的代码,就一定要及时优化:勿以善小而不为

第2类 代码设计与实现

第2-0条 不欠技术债

出来混,迟早要还的

第2-1条 分离业务功能不同的代码

实例:

之前设计一套对外接口,由一系列功能不同,但数据结构十分接近的接口组成。一开始为了贪图减少工作量,把这些不同功能接口的数据结构合并为一个META类,只在具体调用时,以『if-else』的形式有选择地取用META类里面的一些字段

事实证明,这是一个灾难:仅仅为了节约一点点写META类的工作量,而把几个功能不同的接口硬是搅和在一起了,搅和在一起以后,Bug丛生,阅读和扩展都很吃力

第2-2条 接口变更/升级时做好对旧代码的兼容

实例:

某接口一开始使用MD5做加密签名,后要求升级至RSA签名,在升级过程中会有一段时间兼容RSA及MD5:优先使用RSA验证签名,一旦失败,再使用MD5验证签名

通过日志、运维监控可以观察旧代码(MD5)的调用情况,等其完全无人调用后,再移除之,实现平滑升级

第2-3条 对外接口要提供必要的error code

不然,调试对接过程会很浪费时间

第2-4条 同样的数据不要存2份,同样的代码不要写2遍

实例:

由于产品方需求,某表单的内容须要同时存在A、B、C三处地方,并以类似的交互进行操作,结果是同样的表单数据在数据库存了3份,类似的交互页面前端实现了3个,Java后端也实现了3个类似的Service

产品用户对这几个类似的交互页面感到迷惑,开发人员也不得不重复编写类似的代码,从而埋下了坑

第2-5条 重复的代码就是坏味道

必须及早重构

常见的重复代码:一堆高度类似的『if-else』代码块

第2-6条 模块要有统一的对外窗口

例如:

A模块下属有B1模块、B2模块、B3模块,那么尽量对外只暴露A模块的API,A模块作为下面B1、B2、B3模块的对外『窗口』出现

第2-7条 代码要有清晰的层次感,避免循环依赖

有了清晰的层次感,代码可读性、扩展性都会好得多

第2-8条 使用抽象、重构、xml配置,减少代码量

代码越少,Bug越少

第3类 杂项

第3-1条 Hessian/HttpClient等是否加上超时设置,是否需要安全认证(如IP白名单)

第3-2条 事务内部不应该有网络调用或者长延时操作

第3-3条 接口(尤其对外、Http接口)注意等幂性

第3-4条 一个方法代码行数尽量不超过50行;一个Java类尽量不超过500行

第3-5条 线上数据库已有的字段不能改,更不能删;只能对其进行兼容

小结

  1. 写代码是一项『艺术』,但首先是一种『工程』,只要按照科学的、经过实践检验的方法去做,风险、进度、质量完全可以做到可控
  2. 不怕犯错,快速纠正,及时总结

发表评论

电子邮件地址不会被公开。 必填项已用*标注