摘要：
软件架构不是一成不变的。需要时就改变它。要想做到可以修改，架构就必须保持简单。牺牲简单性的修改要抵制。 XP原则 -- YAGNI(如果你不是马上需要，就不需要去做) 延迟设计决定，知道你必须做出这些决定为止。不要在你还不知道需求的时候就做出架构决定。不要猜测。 必须保持架构品质。只有当开发者们相信 阅读全文
摘要：
1. 基本没有重复的代码2. 独立的模块，单元测试，迫使结构走向高内聚，低耦合的状态。另外一个，说不上是失败的系统，但是有一些特点是明显需要改进的地方：1. 对新成员，没有完整的系统结构文档可以理解2. 对于一个MVC式的结构，数据传递要经过很多层，特别是底层处理部分，新成员一般了解不到。如果一个模 阅读全文
摘要：
1. 新代码的定位一开始就有系统结构清晰的总体视图，所以，新的功能单元可以添加到正确的功能区域，而不是为了一时方便，代码随意添加。（这样，有的时候开发者的工作会需要动写脑筋，但是在系统维护和扩展时，就变得容易了）2. 系统的一致性顶层设计的良好风格和决定，为底层代理好处，代码是统一、整洁的。清晰的定 阅读全文
摘要：
一个好的架构的形成不仅是架构师功劳，还有团队集体合作，主要因素有：确实进行有意为之的前端设计；设计者有很好的素质经验；在开发过程中，保持清晰设计观点；授权团队负责软件整体设计；不要害怕改变设计；让合适的人加入到团队，让团队保持健康工作关系；在合适时候做出决定；好的项目管理和合适最后期限。 在后来介绍 阅读全文
摘要：
今天我选择《架构之美》作为课外读物。在本科学习阶段没有接触过架构这些东西，总觉得那都是大牛级别的任务需要考虑的问题，离我们很遥远。但在看了《架构之美》这本书之后，对架构有了一个大致的认识（总觉得那些东西有些抽象，没有真正做过很多项目，积累过一定经验的人要想理解透彻还是有难度的）。下面就说说我读了这本 阅读全文
摘要：
有空再说 阅读全文