如何快速的熟悉项目？
如何快速的定位问题？
如何最小代价解决问题？
如何让自己有快速定位问题和解决问题的能力？
开发者 编写代码的时间应该只占工作的时间的一部分，大部分时间都是用来解决问题的。
在开发一个需求之前，肯定是要了解需求，并且在此基础上，有具体的方案落地想法。
从头开始做一个产品或者说项目的机会是比较小的，大部分都是半路接手，或者二次改造，这时候我们面临的就是对产品项目的熟悉度问题和对问题的处理。
那么，如何快速的熟悉项目呢？
熟悉项目之前肯定要熟悉相关业务，我们不必对业务熟悉到具体细节，但是大致的脉络需要熟悉，要有总揽全局的感觉，这样有助于我们突破对项目的疏离感。
简单来说，就是通过大致脉络进行业务建模。完成简单的业务建模后，就可以着手熟悉项目代码了！
现在，基本上都是微服务架构，当然也存在一些单体架构。
对于微服务相关项目的熟悉，需要我们整理、明确有多少个服务，服务大概是用来做什么的（如果能了解诞生的背景最好，但是一般情况下，只有完整开发了这个服务才知道）。
对于所有服务的数量和列表，以及能力，有时候我们刚开始可能比较不容易获取所有的代码权限，但是相关文档权限应该是有的，这时候我们可能需要通过文档来进行初步的整理，可以梳理成表格。
完成产品项目本身所涉及的服务整理后，最好能简单的了解下相关的上下游系统（有时候上下游系统没有统一的文档去了解到，很离散，我们可以遇到再了解）。
这时候可能会有需求下发，需要来提前熟悉了，对应的代码权限也会给到，现在就到了读代码的时候了。
目前来说，有几种不同的web代码结构模式：
一种是我们熟知的MVC模式，也就是controller—service—dao分层结构。
一种是我们了解的DDD模式，也就是领域驱动，领域驱动的理念比较宽泛，但是他的实现方式可能略有不同，要根据具体实现代码来阅读分析。
还有一种是自己开发的框架，这种种类比较多，都是比较老的代码或者程序员会这样做，比如通过自定义注解和反射自实现对请求的解析，当然有些公司也会基于已开源的框架再做二次封装，但是基本模式都是前面两种，这跟完全自开发的框架和模式有所不同。
对于MVC模式，我们阅读代码是比较容易的，最多代码写的不整洁，或者是业务问题导致的无限if/else，或者大道至简，无限行数😂，让人难以阅读。这时候从顶层向下阅读比较容易，也就是找到入口，然后去追溯（OD破解时也是要找到入口，😄哈哈，可见在代码领域找入口是一步）。
如果对于已有功能的扩展或者优化改造，则直接从页面操作，去找它的调用接口，然后从接口调用开始去查看它的链路。
如果是新的功能，则根据产品设计文档，或者需求文档，结合前面整理的服务列表，去归类这个功能应该放在那个服务里面（一般leader会做好这个大体统筹，不过如果leader是自己呢，或者完全由自己来设计呢，这时候就考验到功力了）。
或许这里有些疑惑：
我刚来，还不是太熟悉，这个怎么归类，应该放在哪里呢？不要怕，带着自己的方案和疑惑去求证，去问询其他同事，然后排除疑惑，确定方案。方案本身就是不断否决中确定的。
我刚来，怎么让我做这些功能，就干坐了一两周，什么都不知道啊！想象一下，如果只是增删改查的话，对你说明白该怎样怎样做？那你怎么体现出能力呢？能力不止是编码能力，还有快速适应能力，自己的方法论和理念，自己解决问题的能力。刚入职，就是对这些综合能力的考验，有些公司会有人专门观察你，进行考核，这时候其实就是展现真正技术的时候了。
当然，做好了这些，剩下的就是结合业务需求进行编码实现了，如何更好的实现需求，我们结合一些设计原则进行思考设计，比如高内聚、低耦合等，和使用一些设计模式，当然大多数情况下，我们使用最基本的开发原则和常用模式即可，不要过度设计，应该尽可能小代价来实现，也就是快速落地需求，在此基础上考虑业务的后续变化和拓展性，进行适配兼容。
具体的一些开发原则，可以参考笔者以前的文章 juejin.cn/post/722302…
需求开发八字真言：先定方案！延迟开发！
如何快速的定位BUG？
去猜测可能出问题的环节，列出来，然后去排除！
如果绝对熟悉，有时候根据错误问题，就可以直接定位出来问题所在，做到一击命中。
日志很重要，一些容易出问题的关键节点，养成打日志的习惯。
DEBUG是基础操作，但是比较浪费时间，其实关键节点有日志的话，大部分问题是不需要DEBUG的，在微服务环境下，有些调用链路可能比较长，再去DEBUG的话，那真不是一般的麻烦，尤其是线上问题。
对于一些复杂问题，比如死锁、内存泄露、内存溢出等，需要我们去单独分析，这时候我们需要设置一些JVM参数，将GC和OOM日志打印出来，然后使用工具具体分析。有些麻烦问题可能是我们对于第三方包的API不恰当使用所造成的，这时候可以去相关社区找类似问题是否有出现，当然，stack overflow也是很好用的。
比如对于一些性能问题，可以参考笔者以前的文章：
CPU 飙升 juejin.cn/post/698657…
如何最小代价解决问题？
有时候解决一个问题的方案可能不止一种方案。正常常见的问题我们其实在测试阶段就可以处理掉，但是有些问题是在具体的复杂场景、或者说有问题的业务操作下发生的，乃至数据量增大后发生，这时候就要考虑低代价处理问题了。
低代价处理问题，可以从原生代码修复，增加补偿代码来处理。并且根据情况，可以从业务层面来处理：直接不去修改这一块代码，而去处理业务。更甚者，可能有些不是问题，是环境配置的问题，所以不要遇到问题就去解决，应该先去检查环境，分析这个问题要不要解决，从而选择最小代价。
如何让自己有快速定位问题和解决问题的能力？
可以训练，让自己养成下意识习惯。
程咬金三板斧，公司运行的模式，都可以吸收成自己解决问题的习惯！
有些制造业公司会不停的优化流程，有些流程的优化，所带来效益的提升可能是巨大的，我们自己解决问题的习惯（模式/流程）所产生的效率也可能是差异巨大的，所以去整合和训练适合自己的习惯，是一件益处远大于付出的行为。就跟找问题的5Why分析法一样，形成自己解决问题的套路。
