架构师作为团队中的最高技术战力，不单单需要提升自己的技术深度和能力，还需要站在更高的层次考虑技术和架构问题。这篇文章介绍了 Salesforce 架构师需要遵循的 10 个基本原则，理解这些原则可以帮助我们成为更好的架构师。原文：10 Principles for Architecture at Salesforce[1]
软件工程不能被简化为一套规则，相反，它需要我们理解试图解决的问题，并在相互竞争的优先事项之间做出权衡。这是一项细致入微的工作，需要经验和大量清晰的沟通[2]。
换句话说，我们认为有些事情具有普适性，某些原则适用于我们做出的所有决定。我们在这里列举了 10 条原则，鼓励软件架构师们拥抱并遵守这些原则。例举这些原则并不是因为这些原则比较容易，而是因为它们都很难（就像肯尼迪 1962 年关于登月的演讲[3]），不是因为这些是规矩，而是因为它们能够指导我们开发的软件取得更大的成功。
这些原则是：
- 基于信任的沟通（Speak for Trust）：信任是 Salesforce 的第一价值观，对于曾在 Salesforce 工作过的人应该都知道这一点。在做决定的时候，我们经常需要考虑如何向客户更快交付新功能，虽然这很重要，但那些事关与客户建立持久信任的声音也需要被听到。对于资深个人贡献者（如架构师）来说，这是重要的考虑因素，即使面临产品截止日期，也需要考虑以正确的方式构建系统。
- 技术为客户服务（Technology Serves Customers）：在我们和客户之间通常有许多层级，层级对于这种规模的公司很有必要，但也有缺点。因为当真正的客户在使用我们的软件的时候，想要弄清楚他们的情况就像在玩电话游戏一样。即使需要通过所有这些层级，我们的架构师也需要去了解客户的痛点。
- 支持长期价值（Champion Long-term Value）：软件架构师有时是团队里唯一知道我们的行动在 5 年或 10 年后产生可能的结果的人。要依靠这一点！避免陷入短期行为中，要考虑现在所做决定的长期影响。
- 复杂性即债务（Complexity is Debt）：我们的系统很复杂，内部比外部表现的更复杂，一定要对添加到系统中的每一点复杂性都保持高度警觉。
- 让架构成为平等的合作伙伴（Make Architecture An Equal Partner）：通常情况下，个人贡献者（ICs，Individual Contributors）认为，当做出重要决策时，他们被排除在外，由管理层和产品团队负责解决问题。但这是错误的，而且对决策毫无帮助，正如我们在前面几条原则中所阐述的，架构师在这里带来了一个真正独特的视角：从长远考虑，并将技术理念纳入考虑范围。架构师需要努力让别人知道自己的存在。
- 沟通“为什么”（Communicate the “Why”）：例如把“为什么”写下来！软件的寿命往往比我们想象的要长得多。一旦意识到大部分成功的软件工程实际上更像考古学，就会更倾向于为后代留下更好的思想记录。未来的自己以及团队里的其他人，都会因此感谢你的。（请在我们的播客“为什么写作对工程师很重要”[2]中获取更多关于这个话题的内容）
- 克服竖井（Overcome Silos）：大公司并不总是有建立共享价值的正确激励机制，但架构师的工作之一就是要克服这一点。这通常需要在全局利益和局部利益之间做出权衡，并努力建立跨组织的关系和资源的复用。
- 设计仍然重要（Design Still Matters）：现代软件交付当然是敏捷的，但这并不是不做计划和设计的借口！我们仍然需要回答主要的问题，并阐述清楚系统的底层逻辑。如果不断动摇系统的底层架构，就会得到一堆不匹配的隐喻、部分实现的抽象和不成熟的解决方案。节省几个小时的计划带来的后果就是要多花几个月的时间编写代码。
- 一切都在发展（Everything Evolves）：构建系统不仅仅是设想最终的完美方案，而必须考虑从当前到达目标的路径，这通常是任何项目中最困难、最尴尬的部分。不要只考虑最终状态，还要考虑可分解性、灵活性、分段性和实现路径。
- 不要做笨蛋（Don’t Be a Jerk）：在软件工程中，常识可以让事情平稳运行。如果没有人喜欢和你一起工作，一切都会变得更加困难。软件工程的“人”方面与技术方面同样重要，甚至更重要。
改变个人行为很难，改变公司文化更难。我们希望这 10 条原则能够提供思考软件工程的方法，帮助我们在两者之间取得进展。
References:
[1] 10 Principles for Architecture at Salesforce: https://engineering.salesforce.com/10-principles-for-architecture-at-salesforce-82105d5399a8
[2] Why Writing Matters for Engineers: https://engineering.salesforce.com/118-why-writing-matters-for-engineers-8ffdeaa40e68
[3] We choose to go to the Moon: https://en.wikipedia.org/wiki/We_choose_to_go_to_the_Moon
