我的从编码到架构思想的转变

入门：

在刚开始工作时，一个业务需求过来，只想的是用代码怎么样实现这个需求，没有去追求写的代码质量问题，大量的if else、重复代码copy等

1年：

随着工作1年后的编码思想转变，看过一些书籍文章，有了代码抽取的思想，会封装util工具包，将公共方法独立抽取出来。

写代码时方法不再是那么冗长让人难懂，而是将业务逻辑抽取出多个小方法中，每个方法只做一件事。

2-3年：

在工作2年+后，经过阅读源码和书籍文章的沉淀，具备了基础的抽象代码思想，在代码设计方面会考虑用设计模式来解决问题，怎么样设计出来的程序健壮和扩展性高。

在编码和设计时去遵循设计模式。在修改代码时会考虑如何在不修改原有代码的基础上来满足需求。

3年+：

在随着工作年限的增长时，在工作中接触到从零开始的架构设计，也接触到过从单体架构改造到微服务架 构。

当面临系统架构时，我会首先考虑从业务场景考虑，如何拆分业务系统。在技术上考虑中间件数据库等的架构与选型做出对比选择。

在服务的架构考虑定义服务的规则（服务间下层不能调用上层，不能循环调用RPC接口等）不能跨过的线， 基础服务端的抽取与下沉（共性的服务：工具服务、http平台调用服务等） 在某些核心服务的设计过程中也是会包含一些架构思想，根据当前服务业务场景采用分层架构设计， 每一层只做当前层次的事情，上下层不做依赖。采用分层架构设计系统时，可以让不同的人专注做不同的事情，避免因为耦合导致 开发人员需要对整个系统的流程都需要了解。分层还带来很高的复用性且更能横向扩展。

未来：

DDD（领域驱动设计）的思想，容器k8s、服务网格Service Mesh、优化+疑难问题排除能力