论架构

架构是一个过程,而非一个结果.

系统总是遵循从无到有,从简单到复杂,再到简单这样的过程.

从代码逻辑到物理网络,从单机到分布式,无数的技术可供架构师选择,如分层,组件化,服务化,标准化,缓存,分离,队列,复制,冗余,代理等,不过它们仍然只是术的范畴,而何时何地如何恰到好处地使用它们才是"道"的范畴.

架构师玩的是折中的游戏,没有唯一正确的架构和唯一的"正确答案".

什么是建筑师? 分别问三个正在敲碎石头的工人这个问题:"你在做什么?" 第一个说:"我在敲碎石头"; 第二个说:"我在为谋生而工作";第三个说:"我在建一座大教堂";第三个就是建筑师!

不好的公司结构和不健康的开发过程将在糟糕的软件架构中得到反映.

坏的设计确实会招致在它上面叠加坏的设计(实际上,它简直就是迫使你那样做).

重要的是保持软件设计的品质,坏的架构设计会招致更坏的架构设计.

开发团队中健康的工作关系将直接有益于软件设计,不健康的关系和个性膨胀会导致不健康的软件.

软件设计的关键品质是内聚和耦合.要保持高内聚和低耦合.

高内聚:

相关的功能如何聚集在一起,模块内的各部分作为一个整体工作的如何.内聚性是将模块粘成一个整体的胶水.

低耦合:

耦合是模块之间独立性的测量指标--它们之间进出"电线"的数量.好的软件设计会限制通信的线路,只提供那些绝对需要的.

因为没有通用的设计,也没有整体项目"风格",所以也没有人关心共同的编码标准,使用共同的库,或采用共同的惯例.

松弛而模糊的架构将导致每个代码组建编写的不好,并且相互之间匹配的不好,它也会导致重复的代码和工作.

不良架构的影响不仅限于代码.它会进一步影响到人,团队,过程和时间表.

软件架构不是一成不变的,需要时就改变它.要想做到可以修改,架构就必须保持简单.牺牲简单性的修改要抵制.

不要在你还不知道需求的时候就做出架构决定.不要猜测.