项目问题定位的方式
转发自https://my.oschina.net/u/238296/blog/1605603
1.1 问题原因分析
从问题发生的环境，大致可分为线上环境问题、测试环境问题、本地环境问题。
1.1.1 线上环境问题
线上环境问题大致可分为阻塞性问题和非阻塞性问题。其中，阻塞性问题是影响用户正常使用并且需要立即处理的问题；非阻塞性问题是不影响用户使用的问题，这类问题可能是版本允许并带着BUG上的问题，也可能是其他原因引起的。线上问题发生的种类大致有以下这些：
Ø 线上特定环境产生的问题。例如：数据量大、并发量高。这类问题在本地不易被发现，而线上在刚上线也不易出现，而是到了一定阶段才会突然出现。
Ø 线上环境和线下环境不一致。这类问题的表现大体直接表现为“我本地环境是正常的，线上环境不正常”。这类问题可能是硬件环境不一致（如：本地是32位，线上是64位）、软件环境不一致（如：Tomcat版本不一致）、配置环境不一致（如：Tomat配置参数不正确）、版本未正确更新、数据脚本未正确执行等。
Ø 未测试的BUG。在开发认真完成开发和自测，测试负责的完成测试的情况下，这类问题出现的场景是很隐蔽的，一般很难被发现，但一旦被发现，相对来说是比较容易排查的，因为这些隐蔽场景的范围比较狭窄。
Ø 不规范的代码。这类问题测试很难发现，线上也不一定会出现。如果出现此类，是很难排查的，因为代码逻辑是正确的，但是存在隐患。所以，我们在提交代码的时候务必先检查再提交。
Ø 安全性。由于大部分需求并未将安全性纳入需求的范围内，大部分开发人员也不会考虑安全性的问题，但是往往由于这类的疏忽，却会导致一些不可挽回的后果。
Ø 其他原因。线上环境复杂万分，各种用户和使用场景也绝不是我们能考虑周全的，这类问题促使我们不断的去学习，巩固，通过学习的知识和已有的经验来排查和解决问题。
当遇到阻塞性问题的时候，需要立即排查并处理。由于是线上的环境，我们在排查问题会有一定的难度，但依旧有一定的方法可寻，一般按照如下步骤进行。
1. 日志查看
软件系统一般都会有运行日志，可以从日志中查看到报错的信息，依据这些信息进行问题排查，比如什么时间、什么人、操作了什么、触发了什么、产生了什么结果。
2. 代码检查
在日志无法排查问题的情况下，需要通过代码来定位。这需要对代码有一定的熟悉程度，可以知道用户的操作是由哪里的代码执行的，然后对该块代码进行检查。代码检查的时候需要着重检查一些逻辑分支语句，同时可以借助一些工具，例如：FindBugs，Alibaba Code Guidelines等。另外，还需要关注一下触发器之类的隐蔽代码。
3. 远程调试
由于代码是静态的，而代码执行是动态的。静态代码的检查可能并不能检查出问题，而需要通过线上的环境、数据一并进行检查。这时，可以在不影响线上用户使用的情况下，远程断点调试程序。
4. 本地调试
有的系统可能并不方便进行远程调试，那么可以尝试把线上的全部数据（或者关键历史数据）拷贝下来，在本地环境使用线上环境的数据库，进行调试。断点调试是比较直观的一种检查错误的方式，通过异常信息的日志，能确定到指定的代码行，并结合线上的数据，很容易发现问题。
1.1.2 测试环境问题
测试环境（广义）有自测环境、测试环境（狭义）、预发布环境等。
测试环境中出现的问题，通常为BUG，而这类问题都是比较明显的问题，可能是需求不符、代码逻辑不正确等。一般我们在处理这类问题的时候，都会和测试、需求进行沟通，先明确目标输出内容，然后进行场景回溯来复现问题，最后针对问题进行修改。
1.1.3 开发环境问题
通常，有一定开发经验的程序员，都不太会在开发环境出现问题，又或者一旦出现问题，能很快的定位并解决。而经验并不怎么丰富的程序员，会在开发环境中遇到各种各样的稀奇古怪的问题，比如：
Ø 刚接触框架搭建（如SSH），却启动的时候各种报错，无法启动Tomcat
Ø 修改了代码，执行的却还是之前的代码
Ø 中文乱码
Ø Eclipse突然就不编译了，改了代码也不编译了
Ø svn覆盖其他人的代码，下载的代码又各种冲突，没法合并
Ø 本地测试各种空指针异常、数组越界异常
Ø 其它
这类的问题，会随着工作经验的丰富，逐渐减少甚至没有。
1.2 结尾
本文主要是讲述了一些问题发生的原因，以及问题发生了如何解决。但这个其实是点到点的一个处理方式，由问题点到原因点再到解决点。这种解决方式，更像是一种打补丁的方式。而实际上，一件衣服，补丁越多可能就越难看；对应到程序中，补丁越多，可能这个程序也越难看懂，越难维护。所以，在条件允许的情况下，我们可以尝试由点到面，由问题点到原因点再到整体解决方案，这类似于汽车的补漆，某块地方掉漆了，却并不是单纯的补这一块，而是补这一面，让漆面更加好看。对应到我们程序来说，假设某段查询很慢，如果光优化这段查询的sql，似乎这个问题就解决了，但当数据量上去，业务复杂程度上去后，其他的查询也会变的缓慢，这时，再在代码块进行补丁式修复，补丁会越来越多，不仅工作量会越来越多，而且对线上用户的体验也是非常不好的。所以，在条件允许的情况下，是否可以对查询进行整体检查优化，又或者添加缓存机制、分库分表等，出一个整体解决方案。
说了这么多，其实很多情况下即使看了之后也不是就能解决问题的。每个人思维方式和处理方法都有一些区别，就好比我喜欢用叉子而你喜欢用筷子。总之，多学、多看、多积累吧，很多问题，有经验的程序员看了问题表现，大致也就能猜到问题的原因了。
