写在前面
这篇文章为翻译文，原作者Srinath，翻译原因主要有
-
文章内容总体很实用，看了之后受益良多
-
文章中列出的某些点，困惑了我很久，希望看看大家有没有不同的声音
-
这里不止是架构，还有产品逻辑，希望产品同学也可以看看。开发和产品有时候脑回路的确不大一样。求同存异。
4. 绿色部分为个人解读，欢迎探讨指正
备注：名字也是翻译的，不确定真实性。。。求轻锤。
概述
the role of the architect should be played by the development team itself , Instead of having a dedicated team of architects or departments .
架构的角色应该由团队成员自己来扮演，而不是拥有一个专门的架构师团队或部门。
The role that the architect should play is a guide , Discussion initiator , Plant builders , Not definers and builders . In order to solve the structure disputes and choices within the team , The following is formulated 30 Article principle , These principles are widely accepted by members , It has also become a learning path for novice architects .
架构师应该扮演的角色是指导者、讨论发起者、计划制定者，而不是定义者或者建造者。
解读：团队成员人人都是‘架构师’，都要参与原始的问题讨论，共同定义和解决问题，达成理论一致。
为了解决团队内部的结构分歧和选择，下面列出了30条原则，这些原则被广泛接手。
基本原理-The basic principle of
principle 1：KISS(Keep it simple,sutpid) And keep everything as simple as possible . Solve problems with the simplest solution .
-
KISS，让一切尽可能简单，用最简单的方案解决问题。
--> 避免过渡设计
principle 2：YAGNI(You aren’t gonna need it)- Don't do something you don't need , Do it when you need it .
-
不要做你当下不需要的事情，当你需要的时候才做。
--> 不要为了做而做
principle 3： climb , go , run . In other words, make sure you get through first , And then optimize to get better , And then continue to optimize to make it great . Iterate to do things , Agile development ideas . For each function point , Create milestones （ Up to two weeks ）, And then iterate .
-
爬、走、跑。换句话说，先运行起来，然后优化，再继续优化直到变得更好。迭代做事，走敏捷开发思路。
--> 敏捷+迭代的工作方式
principle 4： Create stability 、 The only way to produce high quality products is to automate testing . Everything can be automated , When you design , Think about this .
-
创造稳定性、高质量的软件产品的唯一方式是自动化测试。一切都可以自动化，当你设计时，请考虑这点。
--> 单元测试+系统测试+集成测试。 自动化测试，解放资源，代替人为的不准确的影响面评估和单点测试。
principle 5： Always think about the input-output ratio （ROI）. It's worth it. No .
-
时刻考虑投入产出比 。
principle 6： Know your users , And then balance that with what you need to do . Don't spend months making one devops The user interface , In the end, you only find that people like the command line . This principle is principle 5 A concrete manifestation of .
-
了解你的用户，然后平衡你需要做什么。不要花费大量时间做用户不喜欢的产品。
principle 7： Design and test a function as independent as possible . When you do design , Think about this one . In the long run, it can solve a lot of problems for you , Otherwise, your function can only be tested after all other functions of the system are ready , It's obviously not good . With this principle , Your version will be smoother .
-
尽可能独立的设计和测试一个功能。设计时，多考虑这一点。长远来看，它可以为你解决很多问题，否则只能等全部完成了才能测试。
--> 敏捷开发思想
principle 8： Don't make fancy . We all like high-end cool design . Finally, we put a lot of functions and solutions into our architecture , And then these things won't be used at all .
-
不要花里胡哨。 我们都喜欢炫酷的设计。最后，我们把很多功能和解决方案都放进了这些架构中，然后这些东西就完全不用了。
--> 解决问题为第一要义，不要随便引入更高的复杂性。不要每开发一个功能都想着给全世界开发共用，很多是一次性代码。
产品功能选择-Functional selection
principle 9： It's impossible to predict how users will use our products . So embrace MVP（Minimal Viable Product）, Minimum runnable version . The main idea of this point of view is that you can pick out a few very few usage scenarios , And get it out , And then release it online for users to use , Then decide what to do next based on the experience and user feedback .
-
我们无法预测用户将如何使用我们的产品。所以需要拥抱MVP，及最小可用/运行原则。这个观点的主要思路是，挑选出几个场景，发布给用户使用，然后根据用户体验和反馈决定下一步做什么。
--> 互联网时代更要拒绝主观臆测，以用户实际需求为准，多次小功能迭代+灰度/AB测试。
当你不能明确这么做的价值时，那就不要想当然的去做，只要要考虑下ROI。
principle 10： Do as few functions as possible . When in doubt , Don't do it , Even kill . Many features are never used . At most, an extension point is enough .
-
尽量少做功能。当有疑问时，就不要做，甚至杀人（这里应该指产品经理，）。很多功能从未使用过，最多一个扩展点即可。
--> 产品功能要少而精，尽量保证每一个功能都是用户切实需要的。不要轻易妥协，除非你也认同了这个功能的价值。
principle 11： Wait until someone asks （ Unless it's affecting the core process , Or wait until you need to ）.
-
直到实在有这个真实需求了，才去做。不要靠臆想来主观判断。
--> 洞察客户需求，不要想当然。
principle 12： Sometimes you have to have the courage to say no to the client . At this point, you need to find a better solution to solve . Remember what Henry Ford once said ：” If I ask people what they need , They would say I need a faster horse ”. remember ： You're the expert , You have to guide and lead . To do the right thing , It's not a popular thing . End users will thank you for providing them with a car .
-
有时候需要勇敢对用户说不。你需要找到更到的解决方案。记住亨利福特曾经说过的话：“如果我问人们他们需要什么，他们会说我需要一匹更快的马”。记住：”你是专家，你需要引导和领导，来做正确的事，而不是流行的事“。最终用户会感谢你为他们提供了一辆汽车。
--> 学会变通，面对问题，不能一层不变的思考解决方案。有时候需要换位思考
服务端设计和并发-Server design and concurrency
principle 13： You need to know one server How it works , From hardware to operating system , Until the programming language . Optimize IO The number of calls is your preferred path to the best architecture .
-
你需要知道一台服务器是如何工作的，从硬件到操作系统，直到编程语言。优化 IO 调用次数是您获得最佳架构的首选路径。
principle 14： To understand Amdhal The law of synchronization . Sharing variable data between threads can slow down your program . Use concurrent data structures only when necessary , Only when you have to use synchronization （synchronization） When you use synchronization . If you want to use a lock , Also make sure you have as little time as possible to hold Lock . If you want to do something after locking , Make sure you do what you do inside the lock .
-
了解Amdhal同步定律。在线程之间共享可变数据会减慢您的程序。仅在必要时使用并发数据结构，仅在必须使用同步（synchronization）时使用同步。如果你想使用锁，还要确保你有尽可能少的时间来持有锁。如果您想在锁定后做某事，请确保您做您在锁内所做的事情。
principle 15： If your design is a non blocking, event driven architecture , Then never block threads or do something in them IO operation , If you do , Your system will slow down like a mule .
-
如果你的设计是非阻塞的、事件驱动的架构，那么永远不要阻塞线程或者在其中做一些IO操作，如果你这样做了，你的系统就会像骡子一样慢下来。
分布式系统-Distributed systems
principle 16： Stateless systems are scalable and direct . Think about it all the time , Don't make it extensible , Come out of the state , It's the minimum .
-
无状态系统具有可扩展性和直观性。任何时候都不要做一个不可扩展的，有状态的系统，这是基本原则。
--> 架构一定要考虑扩展性，因为要考虑扩展性，所以系统必须是无状态。
principle 17： Make sure the message is delivered only once , Regardless of failure , It's very hard. , Unless you want to control both the client and the server . Try to make your system lighter （ Usage principle 18）. You need to know most of the promises exactly-once-delivery The system is streamlined .
17. 保证消息只被传递一次，不管是否失败。这很难，除非你要在客户端和服务端都做控制。试着让你的系统更轻便（使用原则18）。你要知道大部分的承诺exactly-once-delivery的系统都是做了精简的。
--> 这个实际使用的应该比较少，除非消息不重要的场景。
principle 18： Implement an operation as idempotent as possible . It's better to recover in this way , And you're still in at least one pass （at least once delivery） The state of . The problem of distributed lock and idempotency , How to solve ？ It's recommended to have a look at .
18. 尽可能实现成幂等操作。这样容易进行故障恢复，当你处于至少一个pass（至少一次delivery）的状态。
--> 实际上很多系统都是at least once + 幂等的设计。比如metaq（消费者可以使用消息id做幂等）。
principle 19： know CAP theory . Scalable transactions （ Distributed transactions ） It's hard . If possible , Use compensation mechanisms as much as possible .RDBMS Transactions are not scalable .
19. 了解CAP理论。可扩展事务（分布式事务）很难。如果可能，尽可能使用补偿机制。RDBMS 事务不可扩展
principle 20： Distributed consistency cannot be extended , Group communication is also not possible , It is also impossible for reliable communication within the cluster . Ideally, the maximum node limit is 8 Nodes .
20. 分布式一致性无法扩展，组通信也不可能，集群内部也不可能进行可靠通信。理想情况下，最大节点限制为 8 Nodes。
--> 分布式集群的一些限制，比如zookeeper这种基于paxos协议的集群，集群间是需要保持数据一致的。节点过多肯定会因为同步带来一些延迟，而且出错概率更大（虽然很多错误可以被集群自消化）。
principle 21： In distributed systems , You can never avoid delays and failures .
21. 在分布式系统中，你永远无法避免延迟和失败。
--> YYDS。 根据实践经验：任何理论上可能发生的问题，在实际长期运行过程中，迟早会发生。参见：墨菲定律。
用户体验-User experience
principle 22： Get to know your users and know their goals . They're new 、 Experts or casual users ？ The extent to which they understand computer science . Geeks like to expand , Developers love examples and scripts , Ordinary people like UI.
22. 了解你的用户，了解他们的目标。他们是新人、专家还是临时用户？他们对计算机科学的了解程度。极客喜欢扩展，开发者喜欢示例和脚本，普通人喜欢 UI。
principle 23： The best products don't need a manual .
23. 最好的产品不需要说明书。
--> 这个目前感觉就很hard。阿里的一些产品，我自己都用不明白。
principle 24： When you can't decide between two choices , Please do not pass this problem directly to users by providing configuration options . This can only make users more confused . If you're an expert, you can't choose , Is it appropriate to give it to someone less than you know ？ The best thing to do is to find a workable option every time ; The next best thing to do is to give the options Automatically , The third best way is to add a configuration parameter , Then set a reasonable default value .
24. 当你无法在两种选择之间做出选择时，请不要通过提供配置选项将这个问题直接传递给用户。这只能让用户更加困惑。如果你是专家，你不能选择，把它交给比你不认识的人合适吗？最好的办法是每次都找到一个可行的选择；下一个最好的办法是自动给出选项，第三个最好的方法是添加一个配置参数，然后设置一个合理的默认值。
principle 25： Always set a reasonable default value for the configuration .
25. 始终为配置设置合理的默认值。
principle 26： Poorly designed configurations can cause some problems . You should always provide some sample values for the configuration .
26. 设计不好的配置会导致一些问题。您应该始终为配置提供一些示例值。
principle 27： The configuration value must be understandable and directly filled in by the user . such as ： The user cannot be asked to fill in the maximum number of cache entries , Instead, the user should be asked to fill in the maximum memory that can be used for caching .
27. 配置值必须是用户可以理解并直接填写的。如：不能要求用户填写缓存项的最大数量，而应要求用户填写可用于缓存的最大内存。
principle 28： If an unknown configuration is entered, an error is thrown . Never ignore . Quietly ignoring configuration errors is often to find bug The culprit who spent hours .
28. 如果输入了未知的配置，就会抛出错误。永远不要忽视。悄悄地忽略配置错误，往往是寻找 bug 花费数小时的罪魁祸首。
--> 第一时间反馈错误，不要将就。这样可能会拖垮系统。另外，也要求系统有明确的正确与错误的定义。
这里有一个很好地例子就是当年oracle与mysql的区别。 不懂的可以自行google。虽然我不确定现在是否还是这样。。。
棘手的问题-Tough questions
principle 29： Dream of a new programming language that will be simple and clear , But it's often hard to really master . Don't change programming language easily .
29. 梦想一门简单明了的新编程语言，但往往很难真正掌握。不要轻易改变编程语言。
principle 30： The complex drag and drop interface is tough , Don't try this effect , Unless you're ready to 10 The team in the year of man .
30. 这里应该说的是低代码。
Last , Tell me how I feel . In an ideal world , A platform should be composed of multiple orthogonal components - Each component is responsible for one aspect （ such as ,security,messaging,registry,mdidation,analytics）. It's like a system built like this is perfect . But unfortunately , In reality, it's hard for us to achieve such a state . Because in the initial state of the project , Many things are uncertain , You can't do that independence , Now I'm more inclined to start with a proper repetition , When you try to get rid of them , You'll find that new complexity is introduced , Distribution itself means complexity . Sometimes the healing process is worse than the disease itself .
最后，说说我的感受。在理想的世界中，一个平台应该由多个正交组件组成——每个组件负责一个方面（例如，安全性、消息传递、注册表、管理、分析）。就像这样构建的系统是完美的。但不幸的是，在现实中，我们很难达到这样的状态。因为在项目的初始状态，很多事情是不确定的，你做不到那种独立性，现在我更倾向于从适当的重复开始，当你试图摆脱它们时，你会发现引入新的复杂性，分发本身就意味着复杂性。有时愈合过程比疾病本身更糟糕。
