架构认知

对架构设计的认知

1. 架构设计的问题，一定要立足于点、连接成线、扩散成面
2. 为什么做架构拆分？通常最直接目的就是做系统之间解耦、子系统之间解耦，或模块之间的解耦。
3. 为什么要做系统解耦？系统解耦后，使得原本错综复杂的调用逻辑能有序地分布到各个独立的系统中，从而使得拆封后的各个系统职责更单一，功能更为内聚。
4. 为什么要做职责单一？因为职责单一的系统功能逻辑的迭代速度会更快，会提高研发团队响应业务需求的速度，也就是提高了团队的开发效率。
5. 为什么要关注开发效率？研发迭代效率的提升是任何一家公司在业务发展期间都最为关注的问题，所以从某种程度上看，架构拆分是系统提效最直接的手段。

对分析问题的认知

1. 业务方的诉求是在技术升级后，系统有能力迭代功能来满足市场的要求，所以关注点在系统能力。
2. 管理者的诉求是在技术升级后，系统研发团队的开发效能得到提升，所以关注点在人效管理。
3. 作为技术人员的你，需要找到自己做系统设计的立足点，来满足不同人对技术的诉求，而这个立足点通常就是系统设计原则。

针对系统现阶段业务发展带来的主要矛盾提出，才会更有价值且被认可

《人月神话》的作者就分析，软件复杂性来源于两点：本质复杂度和偶然复杂度。开发工具、开发框架、开发模式，以及高性能和高可用这些仅是偶然复杂性

架构最重要的是要解决本质复杂性，这包括人的复杂性和业务的复杂性

对能力边界的认知

1. 一个中高级研发工程师对系统的驾驭边界至少是模块或者子系统层面；
2. 一个架构师对系统的驾驭边界至少是全系统层面；
3. 一个高级架构师对系统的驾驭边界至少是某一领域层面。

 

屁股决定脑袋，不在那个位置就不会真正体会到那个位置带来的问题

1. 提高你对系统架构设计的认知能力，一个好的架构师的架构设计不是仅仅停留在技术解决方案上。
2. 提高你对系统架构设计的认知能力，一个好的架构师的架构设计不是仅仅停留在技术解决方案上。
3. 扩大自己能够驾驭系统的边界，因为只有这样才能遇到之前没经历过的问题层次，注意我这里说的是问题层次，而不是问题数量。

同一思维层次解决不了同一思维层次上产生的问题， 需要拔高一个层次