我国传统文化上，要做成一件事，讲究三个方面：明道，优术，取势。在软件架构设计方面而言，也是类似的道理：遵循自然规律以明确大的方向，使用优秀的实操战术，再根据实际情况落地。
这是个快餐年代，几乎所有人都只做一件事 -“取势”。 几乎没有多少人会去理解一个Servlet的工作原理，去理解一次HTTP请求的完整流程，因为有超多框架帮你屏蔽了这里的细节。询问一个人会什么技术，回答也往往是我会Hibernate、Spring、Ibatis、会PullToRefresh组件、会使用SDWebimage。不过这些框架（Framework）其实并不是软件架构。软件架构是一所有生命力的房子，而这些框架只是大一点的板砖。
因为笔者水平有限，这里只提一些普遍准则，也就是”正确的废话“，以飨视听。不会深入到实操战术上，比如怎么用Spring实施MVC架构，怎么使用Maven管理依赖，Redis的常用操作，怎么搭建一个负载均衡的集群，如何使用阿里巴巴的Dubbo框架进行服务化等等。如果大家有兴趣，可以自行搜索，有很多优秀的文章可供参考。
不幸的“程序猿”和“程序媛”各有各的痛苦，幸福的程序员都是相似的。其实说幸福有点言过其实，下面就说说怎么让他们不那么痛苦。
“At the bottom of every person's dependency, there is always pain, Discovering the pain and healing it is an essential step in ending dependency.” --Chris Prentiss
他们都在一个相对稳定的软件架构里编码，自己的代码不会依赖很多模块，不会因为自己微小的改动造成全局的失败。正如"1984"中的老大哥说的，Ignorance is strength（”对外界的“无知就是一种力量）. 任何一个模块都不能有太强的存在感。
曾经在一个大型互联网公司里面，任何人只要用到一个核心模块的功能，就必须依赖一个部署在某远程服务器的库，而且还有IP限制，只能把代码部署到指定网段才能运行起来。导致基本上没法在本地进行单元测试或者简单调试。这个核心库的存在感太强，就成了开发的瓶颈，严重的降低了生产力和码农的幸福程度。
在“风语者客服+”的架构中，每个码农都可以很方便的在本地把服务启动起来，一分钟up and running，随便做一些改动就可以立竿见影的看到效果。这里要归功于几个东西：
1. Git代码管理
在团队作战中，每个程序员可以取下来完整的最新代码库，也可以在本地分支上尽情挥毫泼墨，而不担心影响别人的工作。也可以把本地修改先stash起来，review一下别人的代码，再unstash恢复回来。要想提高团队效率，代码仓库管理建议尽快迁移到Git上。
2. Maven、Gradle、Cocopods等依赖管理
Maven是一个管理依赖（Dependency）的工具，现在在Java社区应该是比较普及的，无法想象现在还有团队直接拷贝jar包来管理依赖。虽然早期没有Maven的时候，都是拷贝jar包这么过来的，碰到的问题也是显而易见的，依赖的jar包作者改了某个bug，没能及时传导到调用方。多个调用方使用不一致的jar包，导致各种奇异bug。对应的在安卓社区，使用gradle的比较多，iOS的Objective-C开发中，多采用CocoaPods。
