架构之美

按有用程度 按页码先后 最新笔记

• 

  第1页

  lzh_ctl

  架构之美 什么是架构？ 架构：建造的艺术或科学。同时考虑到美学因素和实用因素，是洞见系统内在结构、规律、原则和逻辑的过程。 为什么需要架构（正反）？ 不考虑架构，一个产品也可以做成一个单一的满足功能的软件，可以是个巨无霸。 但它无任何品质上的考虑，可维护性极差，运维成本高，这是极端的情况。 架构有助于增删改功能，任何一段代码，放在架构的哪一层，都是由架构设计好的。任何一点变更，都要遵循从上到下的.. (更多)

  架构之美

  什么是架构？

  架构：建造的艺术或科学。同时考虑到美学因素和实用因素，是洞见系统内在结构、规律、原则和逻辑的过程。

  为什么需要架构（正反）？

  不考虑架构，一个产品也可以做成一个单一的满足功能的软件，可以是个巨无霸。

  但它无任何品质上的考虑，可维护性极差，运维成本高，这是极端的情况。

  架构有助于增删改功能，任何一段代码，放在架构的哪一层，都是由架构设计好的。任何一点变更，都要遵循从上到下的原则，先考虑到架构，再考虑到底层代码，而不是一上来就改代码，加代码。

  不好的架构，在系统大了之后，后面维护起来会非常痛苦，让员工工作郁闷，导致人员流失。相反，好的架构应该是越做越爽才对。

  它与＊＊有什么关系？

  与设计的关系

  是系统设计的一部分，突出某些细节，省略某些细节。因此它是设计的子集

  怎么从无到有设计一个架构？

  1、让利益相关方参与，同时考虑品质（可维护性，伸缩性）。

  2、得到各利益方的关注点后，架构师需要考虑这些关注点的优先级，

  并在这些关注点上做一些折中（关注点的矛盾）。

  好的架构要注意哪些点？

  整个系统需要有概念一致性：相同的设计哲学，相同的设计模式，处理问题的一致性。

  好处是让开发人员/测试人员熟了系统的一块后，能很快上手别的模块。就像MS的视窗系统。

  架构不是一蹴而就的。无法一开始就提供完美的架构，他应该随着 用户的增长而可扩展。它的好处是，能避免系统的过度设计。

  高内聚，低耦合：内聚关注的是一个软件模块内部的相关性，而耦合关注的是不同软件模块之间的相关性，或者说依赖性。所谓高内聚是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。所谓低耦合是指不同软件模块之间通过稳定的接口交互，而不需要关心模块内部的实现。高内聚和低耦合是相互矛盾的，分解粒度越粗的系统耦合性越低，分解粒度越细的系统内聚性越高，过度低耦合的软件系统，软件模块内部不可能高内聚，而过度高内聚的软件模块之间必然是高度依赖的。因为它把能从一个模块中拆出来的代码都拆出来了，因此，必然涉及模块与模块间的调用，可能改动A模块导致B模块出错（因为B用到了A模块的产出）。因此如何兼顾高内聚和低耦合是软件架构师功力的体现。

  敏捷架构：核心仍然是短周期迭代交付，可视化，自适应调整。对应老的瀑布模式，即需求，开发，完全做完后，交用户使用。 (收起)

  2011-11-08 19:14:34   回应

  收藏

  推荐
• 

  第165页

  cawyly

  “计算机科学中的任何问题都可以用另外的间接层解决，但是这通常会引发另一个问题。”虚拟化也是如此。 (更多)

  “计算机科学中的任何问题都可以用另外的间接层解决，但是这通常会引发另一个问题。”虚拟化也是如此。 (收起)

  2011-10-10 10:04:32   回应

  收藏

  推荐
• 

  第84页

  cawyly

  关于数据库迁移：第一次听说自动化数据库更新，确实在某些情况下挺有用处的。书里说“想到知道他们输入命令时要从‘现在输入mysqladmin -u root -p...’开始，我就感到背脊发凉”，很形象生动啊。有的时候，在现实工作之，为了查明是不是网络的问题，我们也会让用户在运行里输入cmd，然后ping一长串的ip地址。每次都很让人抓狂。有的时候，对于变化，要在一开始就考虑清楚如何处理。以不变应万变，在某些情况下是完全行不通的。 ... (更多)

  关于数据库迁移：第一次听说自动化数据库更新，确实在某些情况下挺有用处的。书里说“想到知道他们输入命令时要从‘现在输入mysqladmin -u root -p...’开始，我就感到背脊发凉”，很形象生动啊。有的时候，在现实工作之，为了查明是不是网络的问题，我们也会让用户在运行里输入cmd，然后ping一长串的ip地址。每次都很让人抓狂。有的时候，对于变化，要在一开始就考虑清楚如何处理。以不变应万变，在某些情况下是完全行不通的。

  关于不可修改的数据：考虑哪些数据是不能修改的，一定要做好“存档”处理，保留副本是很重要的。在工作中，这样的教训已经不少了。 (收起)

  2011-09-28 09:28:55   回应

  收藏

  推荐

• 

  第1页

  lzh_ctl

  架构之美 什么是架构？ 架构：建造的艺术或科学。同时考虑到美学因素和实用因素，是洞见系统内在结构、规律、原则和逻辑的过程。 为什么需要架构（正反）？ 不考虑架构，一个产品也可以做成一个单一的满足功能的软件，可以是个巨无霸。 但它无任何品质上的考虑，可维护性极差，运维成本高，这是极端的情况。 架构有助于增删改功能，任何一段代码，放在架构的哪一层，都是由架构设计好的。任何一点变更，都要遵循从上到下的.. (更多)

  架构之美

  什么是架构？

  架构：建造的艺术或科学。同时考虑到美学因素和实用因素，是洞见系统内在结构、规律、原则和逻辑的过程。

  为什么需要架构（正反）？

  不考虑架构，一个产品也可以做成一个单一的满足功能的软件，可以是个巨无霸。

  但它无任何品质上的考虑，可维护性极差，运维成本高，这是极端的情况。

  架构有助于增删改功能，任何一段代码，放在架构的哪一层，都是由架构设计好的。任何一点变更，都要遵循从上到下的原则，先考虑到架构，再考虑到底层代码，而不是一上来就改代码，加代码。

  不好的架构，在系统大了之后，后面维护起来会非常痛苦，让员工工作郁闷，导致人员流失。相反，好的架构应该是越做越爽才对。

  它与＊＊有什么关系？

  与设计的关系

  是系统设计的一部分，突出某些细节，省略某些细节。因此它是设计的子集

  怎么从无到有设计一个架构？

  1、让利益相关方参与，同时考虑品质（可维护性，伸缩性）。

  2、得到各利益方的关注点后，架构师需要考虑这些关注点的优先级，

  并在这些关注点上做一些折中（关注点的矛盾）。

  好的架构要注意哪些点？

  整个系统需要有概念一致性：相同的设计哲学，相同的设计模式，处理问题的一致性。

  好处是让开发人员/测试人员熟了系统的一块后，能很快上手别的模块。就像MS的视窗系统。

  架构不是一蹴而就的。无法一开始就提供完美的架构，他应该随着 用户的增长而可扩展。它的好处是，能避免系统的过度设计。

  高内聚，低耦合：内聚关注的是一个软件模块内部的相关性，而耦合关注的是不同软件模块之间的相关性，或者说依赖性。所谓高内聚是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。所谓低耦合是指不同软件模块之间通过稳定的接口交互，而不需要关心模块内部的实现。高内聚和低耦合是相互矛盾的，分解粒度越粗的系统耦合性越低，分解粒度越细的系统内聚性越高，过度低耦合的软件系统，软件模块内部不可能高内聚，而过度高内聚的软件模块之间必然是高度依赖的。因为它把能从一个模块中拆出来的代码都拆出来了，因此，必然涉及模块与模块间的调用，可能改动A模块导致B模块出错（因为B用到了A模块的产出）。因此如何兼顾高内聚和低耦合是软件架构师功力的体现。

  敏捷架构：核心仍然是短周期迭代交付，可视化，自适应调整。对应老的瀑布模式，即需求，开发，完全做完后，交用户使用。 (收起)

  2011-11-08 19:14:34   回应

  收藏

  推荐
• 

  第44页

  cawyly

  “如果你不是马上需要就不要做”这是极限编程的YAGNI原则，在设计中也是适用的。三思而后行，在没有理解之前是不要贸然行动的，一旦先入为主了，就很麻烦了。 (更多)

  “如果你不是马上需要就不要做”这是极限编程的YAGNI原则，在设计中也是适用的。三思而后行，在没有理解之前是不要贸然行动的，一旦先入为主了，就很麻烦了。 (收起)

  2011-09-26 14:59:44   回应

  收藏

  推荐
• 

  第51页

  cawyly

  “在设计系统架构时，一个比较有趣的问题就是确保系统在伸缩式的弹性。”很多情况下，系统用户的并发变化是很大的，尤其是在上一个新系统时，没有历史数据可供参考，很难估计用户对系统的偏好。怎么办？只能靠常规判断了，但是人的直觉有时候也是错误的。那么，系统架构设计时，需要考虑这种伸缩性。一个好的架构不至于在高并发时死亡，也不至于低并发时耗费过多的资源。但是能兼顾太难了。第三章用了Darkstar的例子来说明。没看太... (更多)

  “在设计系统架构时，一个比较有趣的问题就是确保系统在伸缩式的弹性。”很多情况下，系统用户的并发变化是很大的，尤其是在上一个新系统时，没有历史数据可供参考，很难估计用户对系统的偏好。怎么办？只能靠常规判断了，但是人的直觉有时候也是错误的。那么，系统架构设计时，需要考虑这种伸缩性。一个好的架构不至于在高并发时死亡，也不至于低并发时耗费过多的资源。但是能兼顾太难了。第三章用了Darkstar的例子来说明。没看太明白，但是了解了个大概，主要是分而治之的思想。 (收起)

  2011-09-27 09:57:23   回应

  收藏

  推荐

• 

  第1页

  lzh_ctl

  架构之美 什么是架构？ 架构：建造的艺术或科学。同时考虑到美学因素和实用因素，是洞见系统内在结构、规律、原则和逻辑的过程。 为什么需要架构（正反）？ 不考虑架构，一个产品也可以做成一个单一的满足功能的软件，可以是个巨无霸。 但它无任何品质上的考虑，可维护性极差，运维成本高，这是极端的情况。 架构有助于增删改功能，任何一段代码，放在架构的哪一层，都是由架构设计好的。任何一点变更，都要遵循从上到下的.. (更多)

  架构之美

  什么是架构？

  架构：建造的艺术或科学。同时考虑到美学因素和实用因素，是洞见系统内在结构、规律、原则和逻辑的过程。

  为什么需要架构（正反）？

  不考虑架构，一个产品也可以做成一个单一的满足功能的软件，可以是个巨无霸。

  但它无任何品质上的考虑，可维护性极差，运维成本高，这是极端的情况。

  架构有助于增删改功能，任何一段代码，放在架构的哪一层，都是由架构设计好的。任何一点变更，都要遵循从上到下的原则，先考虑到架构，再考虑到底层代码，而不是一上来就改代码，加代码。

  不好的架构，在系统大了之后，后面维护起来会非常痛苦，让员工工作郁闷，导致人员流失。相反，好的架构应该是越做越爽才对。

  它与＊＊有什么关系？

  与设计的关系

  是系统设计的一部分，突出某些细节，省略某些细节。因此它是设计的子集

  怎么从无到有设计一个架构？

  1、让利益相关方参与，同时考虑品质（可维护性，伸缩性）。

  2、得到各利益方的关注点后，架构师需要考虑这些关注点的优先级，

  并在这些关注点上做一些折中（关注点的矛盾）。

  好的架构要注意哪些点？

  整个系统需要有概念一致性：相同的设计哲学，相同的设计模式，处理问题的一致性。

  好处是让开发人员/测试人员熟了系统的一块后，能很快上手别的模块。就像MS的视窗系统。

  架构不是一蹴而就的。无法一开始就提供完美的架构，他应该随着 用户的增长而可扩展。它的好处是，能避免系统的过度设计。

  高内聚，低耦合：内聚关注的是一个软件模块内部的相关性，而耦合关注的是不同软件模块之间的相关性，或者说依赖性。所谓高内聚是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。所谓低耦合是指不同软件模块之间通过稳定的接口交互，而不需要关心模块内部的实现。高内聚和低耦合是相互矛盾的，分解粒度越粗的系统耦合性越低，分解粒度越细的系统内聚性越高，过度低耦合的软件系统，软件模块内部不可能高内聚，而过度高内聚的软件模块之间必然是高度依赖的。因为它把能从一个模块中拆出来的代码都拆出来了，因此，必然涉及模块与模块间的调用，可能改动A模块导致B模块出错（因为B用到了A模块的产出）。因此如何兼顾高内聚和低耦合是软件架构师功力的体现。

  敏捷架构：核心仍然是短周期迭代交付，可视化，自适应调整。对应老的瀑布模式，即需求，开发，完全做完后，交用户使用。 (收起)

  2011-11-08 19:14:34   回应

  收藏

  推荐
• 

  第165页

  cawyly

  “计算机科学中的任何问题都可以用另外的间接层解决，但是这通常会引发另一个问题。”虚拟化也是如此。 (更多)

  “计算机科学中的任何问题都可以用另外的间接层解决，但是这通常会引发另一个问题。”虚拟化也是如此。 (收起)

  2011-10-10 10:04:32   回应

  收藏

  推荐
• 

  第84页

  cawyly

  关于数据库迁移：第一次听说自动化数据库更新，确实在某些情况下挺有用处的。书里说“想到知道他们输入命令时要从‘现在输入mysqladmin -u root -p...’开始，我就感到背脊发凉”，很形象生动啊。有的时候，在现实工作之，为了查明是不是网络的问题，我们也会让用户在运行里输入cmd，然后ping一长串的ip地址。每次都很让人抓狂。有的时候，对于变化，要在一开始就考虑清楚如何处理。以不变应万变，在某些情况下是完全行不通的。 ... (更多)

  关于数据库迁移：第一次听说自动化数据库更新，确实在某些情况下挺有用处的。书里说“想到知道他们输入命令时要从‘现在输入mysqladmin -u root -p...’开始，我就感到背脊发凉”，很形象生动啊。有的时候，在现实工作之，为了查明是不是网络的问题，我们也会让用户在运行里输入cmd，然后ping一长串的ip地址。每次都很让人抓狂。有的时候，对于变化，要在一开始就考虑清楚如何处理。以不变应万变，在某些情况下是完全行不通的。

  关于不可修改的数据：考虑哪些数据是不能修改的，一定要做好“存档”处理，保留副本是很重要的。在工作中，这样的教训已经不少了。 (收起)

  2011-09-28 09:28:55   回应

  收藏

  推荐