未找到评论

软件架构师通常与项目的客户和利益相关者进行互动。理想情况下，他们需要参与确定客户的具体需求，并确保这些需求是业务需求，而不仅仅是“让这个页面有一个浮动的顶部菜单栏”。

题外话：是的，我曾经参与过一个项目，我们花了好几个小时与两家大型保险公司的CEO开会，就为了决定是否在网站上使用浮动顶部菜单😜。这种情况确实会发生……

无论如何，架构师需要确保项目的技术方向是可行的，能够满足业务需求。

因此主要有两个部分：

• 你需要非常了解技术（系统设计以及了解特定技术解决的问题）
• 您需要能够与非技术人员进行良好的沟通，并将业务需求转化为软件系统/设计，以使企业能够实现这些目标，同时又允许系统的灵活性随着时间的推移而改变。

了解这篇文章“问题”中提到的多种编程语言、范例等是有帮助的，因为每种语言和范例都解决特定和不同类型的问题。

例如，如果你的企业需要一个由数百名开发人员开发和维护的系统，那么你需要知道构建此类系统的特定模式（DDD、微服务等）。

想象一下，一个电商网站需要保存所有用户与网站交互的数据（例如订购商品、添加到购物车的商品、从购物车中移除的商品等等），以便将来进行分析（例如预测分析等）。事件溯源可以解决这个问题，这一点在这里非常适用。

所以，成为一名优秀架构师的很大一部分原因在于你的知识面足够广，至少知道哪些技术可以解决哪些问题。并且你能够弄清楚哪些业务问题对应哪些技术问题和解决方案。

最好先了解一下你的求职意向。“软件架构师”通常指的是企业环境中的工作。以下说明可能会有所帮助。

您所描述的例子更多的是关于现在和过去积极参与编程社区的人们，他们提出了一组非常具体的问题：

1. 我的思维方式的改变是否会改善我编写软件的某些方面？
2. 它会破坏其他方面吗？
3. 是什么原因导致这些人这么做的？

所以，一旦你经历过多次这样的过程，当你看到一个新的库、框架或语言时，就能快速地对其中的大部分进行分类。通常情况下，你可以对所有内容进行分类，在这种情况下，它之所以有趣，只是因为你可能需要用它来完成一些有偿工作。有时，它之所以有趣，是因为它有一些你从未见过的交互方式（例如，Scala 尝试将 Java 类型系统与 Hindley-Milner 类型系统结合起来，我觉得这个实验失败了）。偶尔，你会发现某个东西很有趣，然后花几个小时甚至几天的时间去研究它，试图找到其中的奥秘。

刚开始的时候，你可以尝试一些常见的方法，这样会受益匪浅。以下这些方法我保证不会浪费你的时间：

• Ullman 的标准 ML 元素。然后去看看 ML 语言家族，阅读设计各个成员的人的论文以及驱动他们的因素。
• Leo Brodie 的Starting Forth和Thinking Forth，然后去玩 Pygmy Forth 并阅读 Charles Moore 对 colorForth 所做的事情。
• 花一些时间使用 Pharo 或 Self，并了解不将系统分离为程序、shell 等会是什么样子。然后阅读在这些系统上工作过的人的文献，找出其中的问题。
• 学习编写 Prolog。
• 读一堆 Dijkstra 的 EWD，尤其是后期的，深入理解他关于计算数学的思想。也读一堆 Alan Kay 的作品。这两个人彼此看不顺眼，能够在他们的观点之间来回切换，真是难能可贵的能力。

《SICP》是一本很棒的书。如果你喜欢它，就去读一读吧。分支预测值得理解。如果你懂概率，大概半个小时就能理解它的工作原理。除非你正在设计芯片或解决一些真正棘手的性能问题，否则没必要深入理解它。同样，《类型和编程语言》这本书的内容可能比你现在需要的还要复杂。如果你正在构建类型系统或编程语言，那么从头到尾读完它，你会发现它就像你迄今为止最精彩、最实用的建议。如果你不打算从事这个行业，最好先掌握基础知识，这样你就能理解各种类型系统的区别，以及专家们在争论这些系统时究竟想表达什么，然后再转向其他方向。记住，你的时间是有限的。