几条架构原则

一、KISS原则：keep it simple,stupid

原则细说：保持每件事情尽可能的简单，用最简单的解决方案来解决问题。

二、YAGNI：you aren`t gonna need it

原则细说：不要搞一些不需要的东西，需要的时候再去写。不要写一些用不到的东西，最后导致代码包又大又冗余。

三、爬，走，跑。

原则细说：先保证功能能跑通，然后再去优化细节变得更好，然后再继续优化。迭代开发，敏捷开发。比如说第一个里程碑要什么时候完成，需要什么样的功能点，下一个里程碑是什么样的，不断的迭代。

四、创建稳定、高质量的产品的唯一方法就是自动化测试。所有的东西都可以自动化。

五、时刻想着投入产出比，投入时间精力去做的这个事情值不值得。

六、了解用户，基于用户的需求来平衡需要做的事情。

原则细说：了解用户的需求，想着投入产出比，不要一股脑的花几个月去开发一个用户需求不大的事情。

七、设计和测试一个功能要尽可能的独立。

原则细说：设计的时候，从长远的去考虑，把这个功能尽可能的独立，不受别的模块影响，这样就可以完成这一功能的时候进行单元测试，并且不受别的功能模块变化而影响。

八、不要搞花里胡哨的

原则细说：不要做一些看起来很酷炫，实际上没啥实际用途的。

九、用户的使用是不可预测的。

原则细说：不可能完全预测到用户将如何使用我们的产品，所以我们一开始就先挑几个常见的业务场景，实现后上线给用户使用，基于埋点数据分析用户的使用习惯和用户反馈再决定下一步要做什么。

十、尽可能的做较小的功能

十一、等到有人提出再说，除非影响核心流程，否则一些功能等到需要的时候再去做。

十二、有勇气说不

原则细说：对一些你不想做的功能，你可以说不。但是要提供一个更好的解决办法，记住你自己是专家，要去引导和领导。要去做正确的事情，而不是流行的事情，

十三、了解一个server是如何运行，从硬件到操作系统再到变成语言，优化IO调用的数量

十四、在线程之间共享数据会让程序变慢（线程通信会额外消耗资源），只在必须使用同步的时候才去使用同步。如果要用锁，也要确保尽可能少的时间去hold住所，要确保自己用到锁，必须明确在锁内的事情。

十五、如果设计的架构是一个无阻塞且事件驱动的，千万不要阻塞线程，或者在线程中做一些IO操作。

十六、了解用户和清除他们的目标

原则细说：了解用户群体是什么样的用户，比如运动产品，使用的是运动小白，还是运动员。目标群体不一样，使用习惯也不一样、对产品的需求也不一样。

十七、最好的产品是不需要产品手册的。

十八、当无法在两个选择中做决定的时候，更不要直接把这个问题通过配置选项的方式提供给用户进行选择。

原则细说：你作为专家都没办法做出更好的选择，用户更不知道。最好的方法是每次找到一个可行的选项，次好的是自动给出一个选择，再者就是增加一个配置参数，设置一个合理的默认值。

十九、设计不良的配置会造成一个困扰，要为配置提供一些示例值。

二十、配置值是用户能够理解和直接填写的

二十一、如果输入了位置的配置要抛出错误，不要忽略，否则会花更多的时间去找bug。

二十二、不要轻易的切换变成语言

二十三、复杂的拖拉拽的界面是艰难的。