写代码一遍就成功是怎么一种体验写代码，问题总是不可避免的，一遍就成功的可能有，但就个人的经验来说，还是比较少的，尤其是大家一些线上维护的项目，由于种种原因，本地无法运行，在预发环境部署后，才能看到执行的效果。在本地修改代码，改了一段有一段，偶尔还会写写单元测试，一些典型的工具类方法，还是通过Main方法重点自测，模拟各种边界测试数据来看是否达到效果。但是如果需求紧急时，或者构造测试数据比较困难时，就会选择直接在预发环境进行测试，跳过单元测试流程。往往是一个需求代码gitpush了5次以上，才能完成达到提测要求的代码程序。除此之外，有时再预发环境自测中出现问题，还需要增加一些历史代码的日志打印来方便排查问题，在各个调用方法加日志之后，又是一系列的gitpush。
通过预发环境来自测，是特殊情况下的无奈选择，有可能的话，还是建议自己在本地搭建起自己环境，有较为完整的测试数据，这样开发新需求时，就比较容易，可以比较直观的断点调试看到每个步骤的执行结果。同时，在改代码前，需要对自己编写的代码以及达到的效果有一个较为清晰的评估，该如何显示的进行自测和测试，该怎么描述修改内容以及评估影响范围等，都需要有一个较为完整的思路，来避免本次需求对其他模块的影响，有利于线上业务的稳定。
写代码一遍就成功是一种理想情况，但规范的代码风格有利于你朝着这个方面迈进，虽不能至，然心向往之。增加Sonar等代码规范扫描工具的使用，有助于避免一些容易被忽略的问题，比如空指针。良好的代码习惯，让大家在写代码时更顺手，当然，在预发环境部署自测的方式久而久之也会让偶自觉的去走查自己写的代码，避免提交低级别的问题，耗费预发环境部署的时间，但这种代价太大，在一些特殊的场景下用可能会好一些。
作者：夕阳雨晴，偶的：偶尔美文，主流Java，为你讲述不一样的码农生活。