架构学习心得:系统架构-复杂系统的产品设计与开发

CSDN话题挑战赛第2期
参赛话题:学习笔记

学习之路,长路漫漫,写学习笔记的过程就是把知识讲给自己听的过程。这个过程中,我们去记录思考的过程,便于日后复习,梳理自己的思路。学习之乐,独乐乐,不如众乐乐,把知识讲给更多的人听,何乐而不为呢?

系统架构-复杂系统的产品设计与开发-学习心得
1、帮助形成“思考并创建系统”的架构思维
2、管理系统复杂度,优化生产成本,赢得竞争先机
3、23项架构原则,助力系统架构的创建

1、学习笔记-本书框架

        技术始终是为业务服务的,能解决问题、产生业务价值的技术都是有意义的。但我们有理由追求更高、更快、更强,架构方面一样有理论知识来指引我们实现目标。

        架构师不能脱离业务,因为要创造业务价值。        

        架构师的职责之一,在于管理系统复杂度,目标就是降低系统复杂度,达到目标的策略就是分解。由此引发出架构的硬技能:用什么知识+选什么工具+坚持什么原则。《系统架构-复杂系统的产品设计与开发》就是一本理论扎实的一手知识。

一手知识:知识经得起时间的考验,引发读者共鸣与思考,持续产生价值。

特性:内容少而精(但需要读者去参透)、保值时间长。

例子1:医生、律师、艺术家等行业,不用担心失业问题,因为掌握的是一手知识,且需求大。

例子2:开发者等,经常担心被技术革新革掉出路,经常担心,因为掌握的是多手知识(每年总会产生比去年更好用、更简单、更吸引人的新框架)。

本书知识结构如下:

​​​​​​​

2、架构师能力模型

        由此可看到架构师应具备的能力。

什么是软件架构

        软件架构是一个系统的基础组织。包含组件,他们之间的关系以及与周边的关系,设计原则,以及系统演进。

架构的级别

应用级别(Application Level): 架构最下层级别(lowest level)。只关注一个单一的应用。非常的关注细节,关注底层设计( Very detailed, low level design)。沟通往往只限于开发团队内部。 

解决方案级别(Solution Level): 架构的中间级别(mid-level)。关注的是一个或多个应用,从而满足某个业务需求 (业务解决方案)。有点高,但主要还是low-level设计。沟通跨多个开发团队。

企业级别(Enterprise Level): 架构最高级别。关注多个解决方案(solution)。高级(High level), 抽象设计(abstract design), 需要总览全局,总览多个解决方案和多个应用架构师。沟通横跨整个组织。

有时候,架构师也被戏称为“胶水(粘合剂)”,不同利益相关者之间的胶水,举三个例子:

水平: 业务、开发人员或不同开发团队之间的沟通桥梁。

垂直: 开发人员和管理人员之间的沟通桥梁。

技术: 不同技术或项目(产品)之间的集成桥梁。

什么是架构师

        软件架构师是一个软件专家,技术上:负责做出高阶设计选择和输出技术标准,包括软件编码标准、工具和平台(框架);业务上:承上(业务)启下(技术),减少歧义和复杂度。

软件架构师要做的几个典型活动

  • 确定和决定要使用的开发技术和平台。
  • 定义开发标准。比如,编码标准,工具,代码review流程,测试方法等。
  • 协助识别和理清业务需求。
  • 设计系统和基于需求做出决策。
  • 记录和沟通架构定义、设计和决策(Document and communicate architectural definitions, design and decisions)。
  • 检查和review架构和代码。比如,检查确定的模式和编码标准的实现是否合理。
  • 与其他的架构师和利益相关者协作。
  • 开发人员的教练和顾问。
  • 细化并把high level的设计具体到low level设计。

3、在线资料

如何做架构设计和评审:如何做架构设计和评审

阿里技术大牛:一份架构师成神路线图!:阿里技术大牛:一份架构师成神路线图!

如何画好一张架构图?:如何画好一张架构图?

架构师必备的37项技能清单:架构师必备的37项技能清单

你可能感兴趣的:(工作感悟,系统架构,软件工程,软件构建,职场和发展,架构,经验分享)