新手架构师的30条原则，你都知道吗？（上）

内容

经过不懈努力，他终于总结出30条建筑原则。他主张架构师的角色应该由开发团队自己来扮演，而不是一个专门的团队或架构师部门。

人们认为，建筑师的角色应该是促进者、讨论发起者、花草建设者，而不是定义者和建设者。

为了解决团队内部的架构纠纷和决策，制定了以下30条原则，得到成员的广泛认可，成为新手架构师的学习路径。

基本原理

| 原则 1

KISS (Keep it, )) 并保持一切尽可能简单。用最简单的方法解决问题。

| 原则 2

YAGNI（你不会需要它），不要做你不需要的事情，在你需要的时候做。

| 原则 3

爬，走，跑。换句话说，确保它首先工作，然后优化变得更好，然后继续优化使其变得更好。迭代做事，敏捷开发的思路。对于每个特征点，创建里程碑（最多两周），然后进行迭代。

| 原则 4

创造稳定、高质量产品的唯一方法是自动化测试。一切都可以自动化，在设计时考虑一下。

| 原则 5

始终考虑投入产出比（ROI），即是否值得。

| 原则 6

了解您的用户并在此基础上平衡您需要做的事情。不要花几个月的时间制作一个 UI，只是为了发现那些人只是喜欢命令行。该原则是原则 5 的具体体现。

| 原则 7

尽可能独立地设计和测试功能。当你在设计时，你应该考虑这一点。从长远来看，这为您解决了很多问题，否则只有在系统中的其他所有内容都准备好时才能测试您的功能，这显然是不好的。有了这个原则，你的版本会更流畅。

| 原则 8

不要花哨。我们都喜欢高端酷炫的设计。最后，我们在我们的架构中构建了许多从未使用过的特性和解决方案。

特征选择

| 原则 9

无法预测用户将如何使用我们的产品。所以拥抱 MVP ( )，最小的可运行版本。

这个观点的主要思路是，你挑几个使用场景，拿出来，放到网上发布给用户使用系统架构师压力大吗，然后根据经验和用户反馈决定下一步做什么。

| 原则 10

做尽可能少的功能。当有疑问时，不要这样做，甚至杀死它。许多功能从未使用过。最多一个扩展点就足够了。

| 原则 11

等到有人询问（除非它影响核心流程，然后等到需要）。

| 原则 12

有时你必须有勇气对客户说不。这时候就需要找到更好的解决方案来解决它。记住亨利福特曾经说过的话：“如果我问人们他们需要什么，他们会说我需要一匹更快的马”。

记住：你是专家，你在那里领导和领导。做正确的事，而不是流行的事。最终用户会感谢您为他们提供汽车。

服务器端设计和并发

| 原则 13

要知道一个人是如何工作的，从硬件到操作系统系统架构师压力大吗，再到编程语言。优化 IO 调用的数量是您获得最佳架构的首选途径。

| 原则 14

了解同步规律。在线程之间共享可变数据会使您的程序变慢。仅在必要时使用并发数据结构，仅在必要时使用同步。

如果您想使用锁，请确保持有锁的时间尽可能短。如果您想在锁定后做某事，请确保您在锁内做您正在做的事情。

| 原则 15

如果你的设计是非阻塞和事件驱动的架构，那么永远不要阻塞线程或在这些线程中做一些 IO 操作，如果你这样做，你的系统会像骡子一样慢。

分布式系统

| 原则 16

无状态系统是可扩展且简单的。应该始终考虑这一点，并且不要提出不可扩展和有状态的东西。这是最低限度。

| 原则 17

除非您想同时控制客户端和服务器，否则无论失败如何，都很难保证消息只传递一次。

尝试使您的系统更轻（使用原则 18）。请注意，大多数 -once- 系统都是精简的。

| 原则 18

使操作尽可能幂等。这样更容易恢复，而且你仍然处于至少一次的状态。

| 原则 19

了解 CAP 理论。可扩展事务（分布式事务）很难。如果可能，尽可能使用补偿机制。RDBMS 事务不可扩展。

| 原则 20

分布式一致性无法扩展，也不允许组通信，也不允许可靠的集群范围内的通信。理想情况下，最大节点限制为 8 个节点。

| 原则 21

在分布式系统中，您永远无法避免延迟和故障。

用户体验

| 原则 22

了解您的用户并明确他们的目标。他们是新手、专家还是普通用户？他们对计算机科学的理解程度。极客喜欢扩展点，开发人员喜欢示例和脚本，普通人喜欢 UI。

| 原则 23

最好的产品不需要产品手册。

| 原则 24

当您无法在两个选项之间做出决定时，请不要通过提供配置选项将问题直接传递给用户。这只会让用户更加困惑。

如果连你这个专家都无法选择，交给比你了解少的人合适吗？

最好的做法是每次都找到一个可行的选择；下一个最佳实践是自动给出选项，第三个最佳实践是添加一个配置参数，然后设置一个合理的默认值。

| 原则 25

始终为配置设置一个合理的默认值。

| 原则 26

设计不佳的配置可能会导致一些麻烦。应始终提供一些示例值用于配置。

| 原则 27

配置值必须通俗易懂，便于用户填写。例如：与其让用户填写缓存条目的最大数量，不如让用户填写可用于缓存的最大内存。

| 原则 28

如果输入了未知的配置，则会引发错误。永远不要默默地忽视。默默地忽略配置错误通常是花费数小时寻找错误的罪魁祸首。

棘手的问题

| 原则 29

梦想一种新的编程语言会让它变得简单明了，但通常很难真正掌握它。不要轻易切换编程语言。

| 原则 30

复杂的拖放界面很难，除非你准备好一个 10 人年的团队，否则不要尝试这个。

最后，说说我的感受吧。在理想的世界中，一个平台将由多个正交组件组成——每个组件负责一个方面（例如， 、 、 、 ）。就好像一个系统被构建成这样完美。

但不幸的是，在现实中，我们很难达到这样的状态。因为在项目的初始状态，很多事情都是不确定的，你不可能有这样的独立性，现在我更喜欢在开始的时候有适当的重复，当你尝试将它们根除时，你会发现一个新的层次引入了复杂性，分发本身就意味着复杂性。

有时愈合过程比疾病本身更糟糕。

总结

作为一名建筑师，你应该像一个园丁，更多的是修剪和除草，而不是定义和建造，你应该计划而不是指导，你应该修剪而不是定义，讨论而不是标签。

虽然在短期内可能感觉很好，但从长远来看，指导团队找到自己的方式将带来回报。

如果你不小心，很容易让建筑成为一个空话。例如，设计师会说他的架构是错误的，但不知道为什么。

避免这种情况的一个好方法是列出一个被广泛接受的原则列表，该列表是人们讨论问题的锚点，也是新手架构师学习的路径。

作者： ，科学家，软件架构师。Axis2 项目的联合创始人，基金会成员，WSO2 流处理器 (/) 的联合架构师。