软件开发接力赛的最后一棒:上线发布

软件开发接力赛的最后一棒:上线发布

新产品新功能开发、测试完成后,就需要上线发布,可能中间还有个预发的过程,但一般的小团队没有精力也没有能力去维护这么多的环境。上线之后,绝非万事大吉,你将面临一大堆问题,日志报错,数据出错甚至出现严重偏差,如果并发量大,你还得解决性能问题,有时候还会遭遇应用直接崩溃。

这些线上问题和灾难,大部分不是源于发布这一单一环节,软件开发的整个过程是个接力赛,它的成功与否,不全在于最后一棒,而是前期的过程控制,前期控制越严格,上线时及上线以后就越轻松,否则,你前面在匆匆忙忙中埋下的坑在后面还得补上,正应了一句老话,出来混总是要还的。

下面是根据这几年的工作和观察,收获的一些经验,对初创小团队尤其有用,一切都是为了最后的顺利上线。

一、代码规范和开发要点:代码规范是十分重要却最容易让人忽视的一个地方,假如团队中有一个统一的规范,并且人人遵守,可以有效减少沟通成本,少埋很多坑,他之所以让人忽视,很多是因为开发任务的紧迫性,或者开发者自身不重视。常量直接写死,不写注释,日志不打全,不作非空判断,一开始上手开发追求的是走通主流程,对于一些细节却往往不去讲究,遵守代码规范,是具有公益性质的一种行为,它对整个团队都是有益的,对个人而言则可以体现他的专业和工匠精神,方便后期自己维护。对此,code review 也许是一种维护代码规范的不错的方式,即定期对别人所写代码进行点评,对优质代码进行奖励。

开发过程中,个人觉得特别要注意的几个规范和要点:

1、注释,有可能别人会参与你目前的项目,为了让他更快更好地理解整个流程业务,编码时需要写注释,如字段的含义,各个流程环节,以及未来可能会遇到的坑。

2、不要把常量写死,这个曾经有文章阐述,另外就是特别注意有些变量是根据不同的环境定义的,如生产环境和测试环境的相关回调地址是不一样的,这些配置项应该写在相对应的配置文件中,否则,你的代码在测试环境好好的,到了生产环境,就不起作用了。

3、log打全,特别是与第三方交互时的一些输入输出信息,方便排查问题,明确责任。异常信息也一定要打全,关键的地方要try catch一下,检查代码是否只有一行e.printStackTrace(),这是不会打印在相应日志文件中的,也不要用类似log.error("msg={}", e.getMessage());这看不出堆栈信息,不清楚具体错在哪段代码,直接用log.error("msg={}", e);

4、开发时尽可能多的建表保存有用数据,方便后期功能的扩展。

5、工具类涉及面比较广,凡有任何修改,所有成员都要知道。

6、不要只考虑主流程,多想想面对异常以及其他case的处理方式。新手程序员的代码往往是这样的:

if(condition){

//do something

}

老程序员的代码总是这样的:

try{

  if(condition){

  //do something

  }else{

  //do other things

  }

}catch(Exception e){

  //handle  exception

}

假如公司没有白盒测试,黑盒测试的时候总有些case没有覆盖到,这时候线上的系统是不完整的,当这种case出现的情况比较频繁时,也许你只能连夜修改紧急发布了。这里插一句题外话,我总是担心程序员会被未来的Ai程序员代替,也许充分理解、处理复杂多样、瞬息万变的业务场景是普通程序员应对Ai的最后一道屏障了,因为软件世界是人类世界的一个映射,它体现的是真实、完整的人类活动,而人类世界是很难模式化的。

二、严格测试:就算你开发的是逻辑不那么复杂的小模块,也不要太自信,以为光看代码就能找出bug,迅速发布,不变的是代码,变化的是数据,就算你能找出静态的错误,你能预测千变万化的动态场景吗?比如前面的代码规范没有做好,两个接口中的某一个变量名都是一样的,都是reqNo,但是由于调用方理解有误,传递的值却是不一样的,而接口实现者将它当成同一类变量来处理,这光看代码找不出任何漏洞,只有运行起来,跑起来才能找出来。对于高并发分布式应用,测试流程就更加需要规范了。

三、环境配置(生产与测试):上传代码后,别忘了上传表结构以及配置项的变化内容。还是前面说的,注意代码规范,针对不同环境的配置项不要写死,而要写在相应环境的配置文件里。另外,表结构的变化,配置项的变化都要整理成文档上传,像代码一样,做好版本控制。

四、没有靠谱的人,只要靠谱的过程控制:软件开发是一个细致活,有时候哪怕只是一个斜杠的缺失,也会导致整个流程都走不通,程序员需要像机器一样一丝不苟,但人不是机器,再精明的人总有犯困迷糊的时候。他可以集中精力可以攻克一个技术难点,但要长期保证一个大型软件项目的安全运行,绝不是靠一两个大牛就能搞定的。需要建立一套完整的,稳健的流程,检验从需求理解到开发到测试发布的整个过程。

五、问题排查过程就像个漏斗,越早发现,越早解决,成本越低:为什么程序员会那么厌恶恐惧产品经理临时改需求,因为虽然我们对软件设计的要求之一是具有弹性,可扩展可维护,但弹性并不意味着可随便修改,有时候仅仅只是调换下一个流程顺序,如果已有设计无法适应这种修改,而项目已经开发到了一半,就只能在代码上作大幅度的修改。所以,对比别人而言或许只是重新调整下流程图的事,对实现者而言却未必。因此,一些需求问题最好的解决方法就是将它扼杀在摇篮之中,开发之前所有需求细节都要明了。问题排查解决在不同阶段所花费的成本是不同的,越早发现解决,成本越低,上线之后,所花费的不单单是时间成本了,还有金钱了。

软件开发接力赛的最后一棒:上线发布

(图片来自代码大全)

六、处于两难困境的估计是既写代码又管进度的技术管理者,上要应付老板的催促,下要安抚一行一行写代码的程序员,还要保证一定的质量,在质量和速度之间求得一个平衡。

七、日常应用的上线标准(我自己总结的,可能还有更全面的表述):已有bug都已经解决,熟悉业务的人多次review代码和测试后没有发现任何严重缺陷的迹象,软件运行过程都是可追踪,有助于问题排查的,上线!上线之后需要留心观察一段时间,如果是新应用,则先内部测试使用,然后推广。

java达人

ID:drjava

(扫码或长按识别)

软件开发接力赛的最后一棒:上线发布