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

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

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

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

一、代码规范和开发要点：代码规范是十分重要却最容易让人忽视的一个地方，假如团队中有一个统一的规范，并且人人遵守，可以有效减少沟通成本，少埋很多坑，他之所以让人忽视，很多是因为开发任务的紧迫性，或者开发者自身不重视。常量直接写死，不写注释，日志不打全，不作非空判断，一开始上手开发追求的是走通主流程，对于一些细节却往往不去讲究，遵守代码规范，是具有公益性质的一种行为，它对整个团队都是有益的，对个人而言则可以体现他的专业和工匠精神，方便后期自己维护。对此，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代码和测试后没有发现任何严重缺陷的迹象，软件运行过程都是可追踪，有助于问题排查的，上线！上线之后需要留心观察一段时间，如果是新应用，则先内部测试使用，然后推广。