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

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

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

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

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

原文发表时间:2017-11-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏纯洁的微笑

微服务2.0技术栈选型手册

一晃三年过去,微服务技术生态又发生了巨大变化,容器,PaaS,Cloud Native,gRPC,ServiceMesh,Serverless等新技术新理念你方...

53630
来自专栏云计算D1net

你为什么需要在云端构建Linux服务器?

云端Linux服务器比以往来得成本更低、性能更好。 要是你之前还没有启动过云端Linux服务器,眼下也许正是大好时机。原因何在因为你在短短几分钟内就能安装好一台...

66570
来自专栏后端技术探索

12306系统高并发探讨

铁道部的12306网上购票系统着实“火”了一把,在中国境内可谓是无人不知无人不晓,曾有人在网上戏称12306为“史上最牛电商”。12306购票系统的初衷是系统通...

92620
来自专栏程序员互动联盟

单片机距离智能机器人有多远?

提到单片机很多人都很觉得不陌生,大街小巷上面电子产品都用到。近几年随着嵌入式的发展,智能机器人是未来一个大方口,其实智能机器人也是嵌入式的一种,里面融入了生物科...

38250
来自专栏斑斓

如何在咨询项目开展Inception

本文通过我在咨询工作中的真实案例讲解了如何将敏捷开发的Inception与可视化咨询手段结合。2014初,我作为咨询师为客户提供咨询服务,负责一个新项目的敏捷咨...

32740
来自专栏大数据钻研

Web前端知识体系大全

1、前言   大约在几个月之前,让我看完了《webkit技术内幕》这本书的时候,突然有了一个想法。想把整个web前端开发所需要的知识都之中在一个视图中,形成一个...

48940
来自专栏全华班

微信公众号、小程序、接口统一集成开发平台框架

RhaPHP微信平台管理系统,支持多公众号管理,小程序开发,APP接口开发、几乎集合微信功能,简洁、快速上手、快速开发微信各种各样应用。简洁、好用、快速、项目开...

68820
来自专栏CSDN技术头条

仅用8个虚拟机,PayPal是如何扩展至日处理数十亿事务的

仅在8台虚拟机上,就实现了原本需要100台虚拟机才能实现的工作。甚至当CPU占用高达90%时仍能快速响应,这种Paypal前所未见的事务处理密度,却仅需之前十分...

26560
来自专栏Crossin的编程教室

几个以前发过、回复过很多次、比较有用的学习资源

最近事情有些多,所以“每周一坑”偶尔不得不跳票一下,各位莫急哈。 既然来都来了,说几个经常被问到的资源,应该还是不少人需要的。已经看过的就忽略。有其他好资源欢迎...

292110
来自专栏程序员互动联盟

如何深入学习C语言?

疑惑一 遇见编译错误了咋办? 经常见有小伙伴,呼呼的把一大段的编译错误呈现在群里,然后问这是啥原因,其实解决编译的办法还是挺多,现在重点说下编译错误是怎么出来的...

45250

扫码关注云+社区

领取腾讯云代金券