作者  Srinath 软件架构师 Apache Axis2 项目联合创始人，Apache Software 基金会成员


基本原则

原则1 KISS Keep it simple,sutpid
原则2 YAGNI  You aren’t gonna need it  不要去搞一些不需要的东西，需要的时候再搞
原则3 爬，走，跑。先保证跑通，然后再优化变得更好，然后继续优化让其变得伟大。迭代，敏捷开发。
原则4 创建稳定、高质量的产品的唯一方法就是自动化测试。（自动化也要考虑ROI，比如对于易变的UI层）
原则5 时刻要想投入产出比（ROI）
原则6 了解用户。不要花了几个月时间做了一个devops用户界面，最后发现那些人只喜欢命令行。
原则7 设计和测试一个功能尽可能的独立
原则8 不要搞花哨的 （老板就喜欢PPT咋办？）

功能选择

原则9  不可能预测到用户将会如何使用产品。拥抱MVP（Minimal Viable Product），最小可运行版本。
原则10 尽可能的做较少的功能。
原则11 等到有人提出再说（除非是影响核心流程，否则就等到需要的时候再去做）
原则12 要有勇气和客户说不。你是专家，要去引导,去做正确的事情，而不是流行的事情 。如果问客户需要什么，他们会说需要一匹速度更快的马 ，你要提供给他们汽车。

服务端设计和并发

原则13 要知道一个server是如何运行的，从硬件到操作系统，直到编程语言。优化IO调用的数量是通往最好架构的首选之路。
原则14 要了解Amdhal同步定律。在线程之间共享可变数据会让程序变慢。只在必要的时候才去使用并发的数据结构，只在必须使用同步（synchronization）的时候才去使用同步。如果要用锁，也要确保尽可能少的时间去hold住锁。如果要在加锁后做一些事情，要确保自己在锁内会做哪些事情。
原则15 如果设计的是一个无阻塞且事件驱动的架构，千万不要阻塞线程 

分布式系统

原则16 无状态的系统的是可扩展的和直接的。
原则17 保证消息只被传递一次，不管失败，这很难，除非在客户端和服务端都做控制。
原则18 实现一个操作尽可能的幂等，这样的话就比较好恢复，且还处于至少一次传递（at least once delivery）的状态。
原则19 了解CAP理论。分布式事务是很难扩展的。
原则20 分布式一致性无法扩展，也无法进行组通信，也无法进行集群范围内的可靠通信。
原则21 分布式系统中，永远无法避免延迟和失败。


用户体验

原则22 了解用户和清楚他们的目标。他们是新手、专家还是偶然的用户？他们了解计算机科学的程度。极客喜欢扩展点，开发者喜欢示例和脚本，而普通人则喜欢UI。
原则23 最好的产品是不需要产品手册的
原则24 不要把选择留给用户。最好的做法的是每次都找到一个可行的选项；次好的做法是自动的给出选项，第三好的做法是增加一个配置参数，然后设置一个合理的默认值。
原则25 总是要为配置设置一个合理的默认值。
原则26 设计不良的配置会造成一些困扰。应该总是为配置提供一些示例值。
原则27 配置值必须是用户能够理解和直接填写的。比如：不能让用户填写最大缓存条目的数量，而是应该让用户填写可被用于缓存的最大内存。
原则28 如果输入了未知的配置要抛出错误。 

艰难的问题

原则29 不要轻易换编程语言。梦想着新的编程语言就会变得简单和明了，但往往要想真正掌握会很难。
原则30 复杂的拖拉拽的界面是艰难的，不要去尝试这样的效果，除非你准备好了10人年的团队。