在IT技术圈，每一个被问到将来职业规划的程序员，基本都会说我的目标是当一名架构师。

尽管“架构师”这个词在程序员眼中是如此熟悉，但架构师却有很多种，而且我们发现，一些想要做架构师的程序员们，其实根本不清楚成为架构师的条件是什么，工作职责又有哪些，想往这个方向发展吧，又不知道该从哪里着手。

也有很多人可能会觉得，架构还需要入门？代码写得好顺理成章就可以做架构师啊！其实，并不然，架构师确实需要很强的编程能力，但架构思维才是决定你能否成为优秀架构师的关键。

那么，如何成为一名优秀的架构师呢？

基本原则

架构师要遵循KISS（保持简单）原则和YAGNI（你不需要它）原则 ，尽可用最简单的解决方案完成工作，避免做徒劳工作，只在需要时构建。

使用迭代开发，采用敏捷开发模式。聚焦最重要的地方，为每个功能制定一个开发周期（最多2周），然后不断迭代。通过自动化测试提升创造力，所有一切都可以自动化!在设计时应当好好考虑自动化。

功能的设计和测试尽可能独立。只有一切构建完成时你才可以开始测试整个系统。此外，遵循这个原则，版本发布也会更加顺利。

选择功能

想要准确知道用户如何使用我们的产品是很难的。所以我们要推行MVP（最小可行产品）。该理念的核心在于：先制定一些用例，完成用例所涉及的相关功能，立即发布产品，然后根据反馈和经验对产品进行优化。

尽可能减少功能，如有疑问则将其删除。许多功能可能从未使用，你只需为其留一个扩展接口即可。

当客户要求的功能影响到其他模块时，要勇于和客户辩论。从大局出发，尝试找到另一种方法来处理问题。就像 Fords 所说的那样“每当我问顾客需要什么的时候,他们总是会说需要跑得更快的马”。请记住，你才是专家。你应该主导一切，做出正确和专业的决定。虽然用户可能当时有些疑惑，但最终他们会感谢你的。

服务器设计与并发

从硬件、操作系统到你使用的编程语言等多方面深入了解服务器的工作原理。优化 IO 操作的效率是一个良好架构的首要任务。遵循 Amdhal 的同步定律。

线程之间共享的可变数据会降低程序速度。如果可以，请使用并发数据结构，并且仅在必要时使用同步。尽可能少地使用锁。如果你打算在线程锁期间阻塞，请确保自己足够了解具体细节，因为这里存在极大的隐患。

如果你的设计是基于事件驱动的非阻塞架构，那就不要阻塞线程或者在线程中执行 IO 操作。一旦这样做，系统将慢如蜗牛。

分布式系统

无状态系统具有良好的扩展性，我们要尽可能了解和使用无分享架构。除非你能够掌控客户端和服务器的所有代码，否则消息传递失败的情况在所难免。

尽量减少你的系统依赖的因素，尽可能实施幂等操作。这样它就很容易恢复，你至少可以保证交付没问题。

了解 CAP 定理。扩展事务很难。尽可能使用补偿，基于 RDBMS 的事务很难扩展。分布式系统共识不支持扩展，也无法进行组通信，不支持群集范围内的可靠消息传递。其最大节点限制大约是八个节点。你很难隐藏分布式系统中的延迟和故障。

用户体验

了解你的用户以及他们的目标：他是新手、专家还是临时用户？他对计算机科学了解多少？极客看重扩展功能，开发人员关注示例和脚本，普通人则更在乎界面。最好的产品应当不需要用户手册，用户应该一看就会用。

当你无法在两个选项之间做出决定时，请不要通过配置选项的方式来呈现问题。这会给用户和架构师带来麻烦。对于系统如何运作的细节，他们没有你了解，他们怎么能做出决定呢？最好的方案是找到一个每次都有效的选择；其次是自动做出选择；第三个方案是添加配置参数并设置合理的默认值。始终具有合理的配置默认值。

设计不良的配置会制造麻烦。始终配置几个示例值。询问用户配置值的时候，注意选择用户无需即可设置的值（例如，不要问用户需要的最大缓存条目数量，而是要问他想要用于缓存的内存数量）。

如果发现未知配置，则抛出错误。永远不要忽视它。在调试过程中，无提示的配置错误会浪费我们很多调式时间。

结论

一名优秀的架构师应该具备思考、塑造、策划的能力。同时，还要懂得调动团队的力量，发挥团队的最大价值。除此之外，要避免成为只能指出错误，但是不道明错误原因的决策者。