你可以看到一个商业需求的发展. 也许是一家初创公司推出了一款公司赖以生存的新产品, 或者企业向大众发布新产品或新功能. 不管怎样, 在保持高质量代码的同时，以最佳方式开发满足上述业务需求的应用程序，这不是一项简单的任务. 但是谁负责设计满足业务需求的开发计划或项目路线图呢? 谁有资格做这样的决定?
这些问题都有相同的答案:软件架构师.
但是软件架构师到底是什么?
软件架构师通常是具有丰富的端到端产品经验的开发人员, 除了知识和技能的一些 非技术 我们会在下面讲到. 软件架构师角色甚至不一定是一个成熟的职位:相反, 这更像是给那些有能力将商业理念转化为完整产品的开发者的头衔.
因此，软件架构师的角色是高级开发人员的混合体, 团队领导, 和首席技术官——但这个比例在整个行业差别很大. 让我们深入研究一下它们通常有什么共同点.
1. 软件架构师要注意客户的类型
一个伟大的软件架构师对他们正在工作的客户类型有敏锐的眼光. 有些客户对可能发生的事情没有清晰的认识. 他们对自己的产品没有长期计划，需求和结构不断变化.
软件架构师的工作就是对这些方法有一个准确的认识. 这意味着提出可能的未来计划和设计，以服务于开发团队，以防止破坏性的更改.
或者早期引入一些特性，这些特性可能需要在代码库中进行大量重构，如果出现较晚，甚至需要进行数据迁移. 例如, 从NoSQL数据库迁移到SQL数据库可能需要几周甚至几个月的准备时间. 维护数据一致性的脚本和过程以及重写后端功能以使用新数据库并不是一项容易的任务.
另一种类型的客户是那些确切知道自己想要什么的人. 他们有一个清晰的产品路线图和清晰的愿景. 他们在某些方面仍有不足, 而且业务通常会迫使路线图迟早改变. 但至少他们有个计划.
这种类型使得软件架构师的工作更加轻松，但也带来了一些挑战. 首先, 软件架构师需要确保路线图实际上有一个合理的时间框架(下面将讨论)。. 其次, 有时，它会引入一些约束，比如与文档记录糟糕的API集成，只是因为使用该服务对企业来说更便宜.
2. 软件架构师了解业务需求
顶级软件架构师能够与业务所有者进行有效的沟通, 首席执行官, 或者客户. 他们能够准确地梳理出客户对输出的想法，同时将技术上的困难和挑战抛在脑后.
软件架构师能够有效地:
- 与技术和非技术客户讨论需求和挑战
- 简化并总结客户的需求
在开发方面，他们能够:
- 绘制相关数据模型的草图，以及它们如何相互连接
- 了解最能满足项目需求的语言、数据库和工具
- 深入挖掘需求并提取最微小的细节，以便与开发团队进行解释和讨论
没有这些技能, 软件架构师从一开始就会构建错误的产品——这是一个昂贵的策略, 当然!
3. 软件架构师擅长时间管理
一个伟大的软件架构师也能够有效地管理他们的时间. 软件架构师不必是团队领导:他们可以是产品的唯一开发人员，也可以是开发团队的一员.
也就是说, 作为团队领导的软件架构师将知道如何快速了解他们所领导的团队的能力. 他们将能够合理地估计产品开发所需的时间, 考虑到紧急情况, delays, 或者其他可能出现的问题. 换句话说, 他们将能够给出所需时间的最佳情况和最坏情况估计.
至于作为团队成员工作的软件架构师, 他们负责仔细听取团队领导提出的预计时间和交付需求，并为交付设定个人时间表. 他们还负责向团队领导指出他们可能遗漏的任何要点和/或所给出的需求中不明确的任何内容.
4. 软件架构师通常精通多种语言
软件架构师明白，没有什么工具能把所有事情都做好. 没有什么是十全十美的. 同样的概念也适用于编程语言、框架、库和数据库.
尽管大多数流行的编程语言都可以完成这项工作, 它们并不总是开发手头产品的最佳选择. 把节点.js作为例子:当然, 对于几乎所有的应用程序来说，它都是一个很好的工具, 但并不总是彩虹.
如果使用不当，必须处理事件循环和阻塞代码等问题有时可能会减慢执行速度, 损害用户体验. 写入while Node.Js可能是架构师个人最喜欢的开发工具, 当涉及到并发性时，他们可能会把它放在一边，转而使用基于golang的方法. 同样的, 当客户赶时间并且不需要微调时，他们可能会推荐Ruby on Rails后端:Rails大量使用的魔力意味着它可以作为一个非常有效的快速开发框架.
这不仅是选择正确的编程语言的问题, 还要决定使用哪个数据库. 软件架构师的第一个决定是使用SQL数据库还是NoSQL数据库. 这取决于在软件设计阶段设置的多个变量.
即使在做出选择之后，还必须做出另一个选择:将使用哪个确切的数据库? 如果你使用的是SQL数据库，你应该选择PostgreSQL还是MySQL? 如果你比较NoSQL数据库，你应该选择MongoDB还是CouchDB?
这只是一个简单的例子，有时可以根据个人偏好或开发团队的舒适度来解决. 但有时这取决于其他重要因素. 例如, 如果需要存储时间序列条目，最好使用为此进行了优化的数据库, 例如InfluxDB. 这不再是一种偏好, 而是一种需求:为了性能, 可伸缩性, 和能否经得住时间的考验.
底线是，软件架构师不会将自己限制在某种编程语言或范式中，并将其用于他们所做的任何事情. 他们明白每种工具都适合于特定的工作，而不是被变化所排斥, 他们欣然接受.
软件架构师了解更广泛的开发人员社区及其对新趋势的采用. 他们不会盲目追随趋势，而是密切关注可能扰乱行业的潜在解决方案. 他们甚至可能成为某种技术的早期采用者, 在某些情况下:一些公司采用Flutter开发跨平台移动应用程序 在其第一个稳定版本发布之前.
这不仅关乎新趋势，也关乎对当前技术的认识. 有时候，一项技术会被竞争对手超越，而竞争对手提供的功能和体验比它更好. 例如, 几年来，Docker Swarm与谷歌的Kubernetes展开了激烈的竞争, 直到很明显社区对Kubernetes更感兴趣.
一个伟大的软件架构师会意识到社区中的这些变化. 他们知道，寻找有Docker Swarm经验的开发人员或DevOps工程师是毫无意义的，因为很明显，Kubernetes正在接管并坚持当前的技术，这可能对公司和产品的危害大于它所提供的好处.
6. 软件架构师知道什么时候打破代码
有时产品已经构建完成，在许多情况下，其现有功能需要更改. 这可能是一个管理决策, 出于安全考虑做出的决定, 或者其他一些原因.
其他时候，代码可能是好的, 但这款应用的受欢迎程度增长得非常快，人们对其功能的需求也在不断增加.
这些是软件架构师可能会遇到的挑战. 他们的解决方案可以用一个词来概括:“打破”.”
破坏代码可以有两种定义.
第一种类型是引入改变应用程序行为的解决方案. 这可能是为了代码的可读性, 能够更快地调试, 或者为了应用程序本身的性能和/或稳定性.
例如，Stripe曾经支持加密货币. 使用Stripe的应用程序必须在后端编写一大块代码来处理这些货币的交易. 当他们在2018年决定停止对加密货币支付的支持时，他们破坏了自己的代码库. 他们还为所有实现了加密货币api的客户端开启了一种分秒秒秒的局面——他们突然面临一个最后期限，要么停止接受这种加密货币支付，要么迁移到不同的支付网关, 至少在处理这种付款时是这样的.
第二种类型的代码破解与分割代码库有关. 有时应用程序变得太大，以至于变得很慢, 或者太不连贯，太依赖他人. 其他时候，这仅仅是因为应用程序的一个功能比另一个功能使用得多.
脸谱网, 例如, 有单独的后端聊天应用程序吗, 新闻提要, games, 还有其他特点. 想象一下，脸谱网的聊天应用的使用量激增. 如果他们必须扩大规模 所有与脸谱网有关的东西 只是为了满足聊天功能的需求，这将是一个非常昂贵的规模. 这就是为什么应用程序的每个大特性通常由它自己的一组后端服务支持. These microservices 可以用低初始化占用快速扩展吗.
7. 软件架构师知道如何实现成本效益
软件架构师还可以负责对应用程序的部署做出决策. 如果你是一家初创公司，你还有少量的用户, 将应用程序部署在分布在三个不同区域的六个不同服务器上，使用三个数据库副本是没有意义的. 部署应用程序也是不合逻辑的, 数据库, 用户上传的文件都在同一个五美元的服务器上，没有备份.
两种方法都是错误的. 第一种是过度杀戮，第二种风险太大. 软件架构师可以预测运行应用程序所需的硬件大小，并以安全的方式使用它, 不用在闲置服务器上花太多钱.
但是成本效益不仅仅是部署和服务器. 它也可以是关于将致力于产品的开发团队. 我们曾经看到过一个由4名初级开发人员组成的团队, 估计有些工作需要两个月, 并在8小时内交付了产品. 与此同时, 质量很低，代码没有文档化——这对最终维护它的团队来说是一个负担.
优秀的软件架构师知道，最好聘请两名能够以干净的方式开发应用程序的资深人员, 用三个月的时间结构化. Sure, 每个人都必须从某个地方开始, 但重点是, 软件架构师团队领导应该有能力知道何时何地投资客户的资金和资源, 当它只是一种浪费.
8. 软件架构师关注用户体验(UX)
软件架构师不仅仅是一个程序员, 而是, 他们能够设身处地为最终用户着想. 他们对用户的行为有准确的想法. 软件架构师还能够评估处理系统的容易程度. 尽管这一点的主要责任在于UI/UX设计师, 它仍然与系统在后台的工作方式相关联.
开发团队总是知道他们所创造的应用的方法, 这有时会让他们忘记新用户需要适应新的图标, UI流, 或者添加到应用程序中的功能. 我们面临的挑战是使这种适应尽可能顺利和短暂. 这是通过遵循设计的市场趋势来实现的. 毕竟, 所谓的“直觉”是一个不断变化的目标, 与用户交互的其他应用程序产生的期望使情况变得复杂.
但即使在这个范围内，也有空间让事情尽可能地简单和一致. 例如, 我们已经在生产中看到一个应用程序，其中用户的姓名充当打开用户配置文件的链接, 但用户的照片在按下后没有任何动作.
人们习惯的默认行为是，当你按下用户的照片或名字时, 您打开概要文件或概要文件的摘要. 这是当前的标准，因为它可以很容易地访问相关的配置文件信息. 但是在上面的例子中, 在一个相对较小的屏幕上, 这个名字很难按，有时需要多次按才能正确. 这样的设计甚至可能向用户暗示，没有办法通过此上下文导航到概要文件.
我们在生产环境中看到的另一个UX问题是附加的功能 导航抽屉按钮 to 浮动动作按钮(FAB). 这是违反直觉的. 一个伟大的软件架构师会在设计阶段抓住这些问题.
就用户体验而言，软件架构师基本上遵循一条规则: 让它尽可能简单.
软件架构师简介
软件架构师 难道这不是任何开发者都可以拥有的头衔吗, 现在你已经看到了区分一个人的标准. 软件架构师对交付给客户的内容负有重大责任, 也让大家的生活更轻松. 为您的下一个项目选择一个优秀的软件架构师是交付成功产品的关键因素——所以明智地选择吧.
