对于初级开发工程师的要求就是得到项目组的认可，如何得到项目组的认可呢？不管哪个职级的公司成员，首先要对自己做出的事情负责，上面的流程中发现一个问题，功能开发结束提测后，测试成员进行测试的时候，发现功能不能正常运行，无法开展测试工作。这自然是不合理的，会影响测试成员对研发成员的信任、还会影响测试成员的工作积极性，信任就类似刷信用卡，当你的信用值逐次降低，其他成员就很难相信你，演化到最后就是不愿意和你合作，他们认为你是一个不靠谱的人。
当然这个问题很容易解决，只要研发这个环节中增加自测流程即可。
我们一般认为研发人员对自己开发的模块进行自测，是应该的，用研发术语来讲是默认的，不需要另行强调。程序猿的工作是团队协作中的一环，和环上的所有人一样，都应该对自己所做的工作负责，这样对于环上的其他人才是公平的、有效的，团队的整体效率才能提高。
为了让研发成员能进行测试，我们还有些问题需要解决：
- 测试用例范围问题
- 被测试环境和测试执行环境的复杂性问题
- 测试数据准备的问题
- 测试执行与集成问题
- 失败测试用例归属问题
解决问题能力不是天生的，自然得靠后天的经验积累。我们工作中会遇到各种各样的问题，比如需要去跟踪调试产品所产生的bug，又比如说使用第三方组件所遇到的一些问题，再比如说使用一些插件或者IDE所产生的一些编译问题。这个时候第一反应不是去别人那里寻求帮助，而是自己尝试去看去解决问题。
当遇到阻塞性问题的时候，需要立即排查并处理。由于是线上的环境，我们在排查问题会有一定的难度，但依旧有一定的方法可寻，一般按照如下步骤进行。
l 日志查看
从日志中查看到报错的信息，依据这些信息进行问题排查，比如什么时间、什么人、操作了什么、触发了什么、产生了什么结果。
l 代码检查
在日志无法排查问题的情况下，需要通过代码来定位。这需要对代码有一定的熟悉程度，可以知道用户的操作是由哪里的代码执行的，然后对该块代码进行检查。代码检查的时候需要着重检查一些逻辑分支语句，同时可以借助一些工具，例如：FindBugs，Alibaba Code Guidelines等。另外，还需要关注一下触发器之类的隐蔽代码。
l 远程调试
由于代码是静态的，而代码执行是动态的。静态代码的检查可能并不能检查出问题，而需要通过线上的环境、数据一并进行检查。这时，可以在不影响线上用户使用的情况下，远程断点调试程序。
l 本地调试
有的系统可能并不方便进行远程调试，那么可以尝试把线上的全部数据（或者关键历史数据）拷贝下来，在本地环境使用线上环境的数据库，进行调试。断点调试是比较直观的一种检查错误的方式，通过异常信息的日志，能确定到指定的代码行，并结合线上的数据，很容易发现问题。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
