标签：bfd 用户需求 经理 计算 代码 怎么 事故 软件质量 职责
先前写过一篇文章《作为软件工程师选择比努力更重要》
今天主要谈谈怎样成长为优秀的软件架构师？这个话题
软件架构师的职责，并不单单是我们通常理解的，对软件系统进行边界划分和模块规格的定义。
从根本目标来说，软件架构师要对软件工程的执行结果负责，这包括：按时按质进行软件的迭代和发布、敏捷地响应需求变更、防范软件质量风险（避免发生软件质量事故）、降低迭代维护成本。
那怎么才能成长为优秀的软件架构师？软件架构师和软件工程师最根本的差别又在哪里？我认为关键在于四个字：掌控全局。
与架构相关的图书分类:
架构思维类。这类图书通常从一些著名的架构理论讲起，比如开闭原则、单一职责原则、依赖倒置原则、接口分离原则，等等。这种图书的问题在于过度理论化。计算机科学归根到底属于工程技术类，实践第一。
设计模式类。这一类图书则一下子进入架构的局部细节，每个模式的来龙去脉并不容易理解。就算理解了某个具体的模式，但是也很难真正做到活学活用，不知道还是不知道。
分布式系统架构设计类。这类图书通常从服务端的通用问题如一致性、高可用、高并发挑战等话题讲起，讲大型业务系统面临的挑战。这些知识是非常有价值的，但无法延伸到通用业务架构，对大部分企业的架构实践并不具备真正的指导意义。
重构类。这类图书主要讲怎么把坏代码一步步改进到好代码。我认为这是最实用的一类。但在没有优秀架构师主导的情况下，大部分公司的代码不可避免地越变越坏，直到不堪重负最后不得不重写。实际上，一个模块最初的地基是最重要的，基本决定了这座大厦能够撑多久，而重构更多侧重于大厦建成之后，在服务于人的前提下怎么去修修补补，延长生命。
我看到不少架构师都会倾向于把架构看作一项纯技术性的行为。他们的工作流程是这样的：产品经理根据用户的需求做出产品设计，然后架构师再依据产品设计给出实现，也就是软件的架构设计方案。
在我看来，这其实是个误解。架构关乎的是整个复杂的软件工程，它关乎实现它的人，它又因团队的能力而异。
同时，架构也关乎用户需求，作为架构师，我们不只是要知道当前的用户需求是什么，我们还要预测需求未来可能的变化，预判什么会发生，而什么一定不会发生。预测什么不会发生最为重要，只有做到这一点，才能真正防止架构的过度设计，把简单的事情复杂化。
标签：bfd 用户需求 经理 计算 代码 怎么 事故 软件质量 职责
原文地址：https://www.cnblogs.com/ibytecoding/p/13863498.html
