作为开发人员，在产品迭代过程中时常会遇到问题需要分析定位，而在分析和定位过程中一般要借助工具，要是能根据问题的现象就能找到原因，那么对快速改进产品品质无疑是一种很大的提升。那么如何做才能达到这样的效果呢？我个人认为要把握这两点：
（1）后端在遇到异常错误处理流程时要将状态码和简洁明了的描述信息组合成一条提示信息反馈给前端，前端收到这条信息时需要展示给用户；
（2）前端在处理异常错误流程时及时、直接地将也异常错误信息展示出来即可。
有的时候，还不能完全通过问题现象来确定问题的所在，此时可以借助另外一种快速分析定位问题的方式——日志记录，通过前端的控制台和后端的日志输出，我们也是可以快速定位的，此时就是需要我们如何快速检索日志的关键字了，否则的话分析过程依旧耗时费力。关于前后端日志的打印也是有讲究和策略的，不能随随便便地添加日志记录，否则的话即使看到日志信息了也没法判断是哪里出错了。我们一定要注意日志级别类型，若是只是单纯地记录流程就用info或者debug级别，若是是在某些业务处理流程中需要警告的就要用warn级别，若是遇到错误异常情况时就要用error级别；此外，还要注意描述信息，一定要简明扼要，能够传达错误所产生的原因，否则的话这些日志也仅仅只是日志，没有实际的意义价值。我时常看到一些日志不管三七二十一，都是采用info级别进行记录，并且描述语句也不通顺，少胳膊断腿的，让人很难明白其中的意思，好像是怕让别人知道似的，还有就是单词书写一定要正确，不能拼错，你要是写错了，至少说明你工作态度不够认真，你不懂的单词可以查找确认。此外，关于日志打印，有个建议，就是尽量对输入的参数进行记录打印，以及对不同组件服务之间的交互结果进行打印，这样的好处就是方便后续明确定位生产环境出现的问题，以便清楚是哪方出现了异常。
最后，是关于沟通方面。当问题反馈着反映问题时，反馈方不能简单粗暴地只说明哪个过程出问题了或者不正确，同时要把问题描述清楚；而处理方一定要弄清问题的具体现象，不明白的地方或者信息不够全的地方，一定要及时向反馈着咨询和确认，要是能够获取到他们触发的条件参数，那么对我们分析定位问题肯定是有帮助的；要是处理方没有掌握足够多有用的信息或者是反馈方提供的信息不正确，那么在没有及时沟通互动的前提下处理方式会走很多弯路，即费时又费力。
小结一下：对于问题的分析和定位，除了能够展示一个人的快速判断能力，还能提高一个人对业务的理解能力，更能够增强一个人与同事之间的互动能力。
------20191210闪