备注：笔记类帖子只是在看书过程中的结构化树形缓存，以及少量评注，只做以后整理的素材之用。
- 无自我意识的设计和有自我意识的设计
- 德米特里·门捷列夫的元素周期表所产生的最大影响是什么？
- 是为化学家提供了一种方法论，以帮助他们识别物质构造之间的形成模式。
- 还是提供了一种用那些模式预测未知元素属性的方法。
- 【Christopher Alexander】在20世纪60年代提出了两种不同类型的设计体系：
- 无自我意识设计（Unselfconscious)
- 原始文化，举例：房屋设计每次都被完全地复制，学徒们都要确保忠实于原先特定的设计。
- 这些特定设计往往都是成百上千年的尝试所累积的经验升华。
- 被认为是“唯一解决方案”，并在该环境需求下屡次奏效。
- 然而，该设计并没有多少其他适用之处。
- 有自我意识设计（selfconscious）
- 现代化的发明，举例：给定的地点、城市或地区，这种建筑上的自由在现代化建筑风格中随处可见。
- 它们个个都体现了基于自我意识的设计。
- 仅仅靠阅读并遵从建造设计规范并不能实现一个有效的建筑设计工作。
- 因为建造规范都是通用性的，而好的建筑风格往往还必须考虑环境中每个层次的细节。
- 几乎在任何城镇或城市中我们都能看到这种有自我意识的设计成果：
- 有乔治时代风格、有维多利亚风格、也有现代剥离和钢铁做成的建筑
- 甚至还有某种错层式房屋、某种牧场、或任何其他样式、种类、建筑形式、材料和建筑风格
- 在特定环境和背景下的这些设计的解决方案究竟是最优的还是勉强可以的：
- 德克萨斯州的奥斯汀市，可能就不适合建造未遮挡的、以玻璃为覆盖面的建筑物，因为：
- 那里的阳光过于强烈，那种类型的建筑会带来一大笔额外的降温费
- 纽约州北部地区可能不是一个适合建造平顶建筑的地方，因为：
- 在极寒的天气中，几英尺雪的重量会显著增加房屋横梁的负担。
- 环境问题是影响如何建造合适房屋的普遍因素，而这一点却经常被忽视：
- 相关的解决方案通常也只满足了最低限度的要求
- 这些方案将会引起一些不得不去处理的新问题
- 德克萨斯州的奥斯汀市，可能就不适合建造未遮挡的、以玻璃为覆盖面的建筑物，因为：
- 无自我意识设计（Unselfconscious)
- 在软件工程里，同样分无自我意识设计和有自我意识设计
- 我们可以做脑海中灵光乍现的任何事情，其灵活度甚至会超过实体建筑的设计
- 这即是软件设计中最令人惊喜的地方，但同时也是它的软肋
- 对任何事情的整体而言，这些闪光点都只是极小的一部分内容，随之而来的是：
- 项目经常延期，超出预算，并频繁地以大动作或安静的方式失败
- 我们鲜有完成项目的成就感，更多时候是感觉远离了麻烦。
- 我们得反复问自己一个问题，为什么？
- 我们有数十年的团队工作经验
- 每年在专业领域有数百万从业人员
- 然而，每次在临近解决问题时掺败在杂草中呢？
- 无自我意识的设计和有自我意识设计所代理的泥沼之间
- 有些设计者和开发人员已经明白了要在设计中绕开复杂问题，并有效地找出核心问题
- 而其他大部分人似乎依然在不断的挣扎于“因为我被要求这样做” -【Christopher Alexander】的工作就是尝试为建筑物的设计师们缓和这个问题
- 揭示原始文化在设计上的有效性极其与一味尝试所有方法的现代建筑之间的差异
- 这两者之间的某处将会是一个平衡点。
- 我们需要在无自我意识设计的建筑物中找到基本原则和一般性解决方案
- 然后在某种程度上把它们描述成有自我意识的，并在各种背景下对其加以运用。
- 任何解决方案方面的智慧都是在失败和错误中辛苦得来的，需要：
- 将抽象化概念具体化
- 使其能被大众所知晓
- 并能被应用到大部分地方
- 成为设计思想中的一盏明灯
- 我们可以做脑海中灵光乍现的任何事情，其灵活度甚至会超过实体建筑的设计
- 德米特里·门捷列夫的元素周期表所产生的最大影响是什么？
- 部落神话和部落智慧
- 问题：
- 从相关文献和已知的最佳实践中获取经验，对于提高效率是非常重要的，
- 但我们的社区在很大程度上忽视了这样做的必要性
- 我们已经失去了很多杰出人物，还将会失去更多人，他们曾为我们的产业打下了坚实的基础
- 软件产品还有一个独有的特征，即它的存在时间通常会超过它的预期寿命
- 尽管我们知道应该将相关软件文档化，冰始终确保其处于最新版本
- 我们也知道应该用笔或者截屏来记录相关开发动作的起因、过程和结果
- 但我们往往会觉的这非常麻烦。
- 解决：
- 我们要做的就是：
- 将开发者脑海内灵光乍现的想法具体化
- 并将其修改并流传下去
- 然后在必要时仅在需要它的地方进行推广
- 【Grady Booch】将这种信息推广简称为“部落知识”（tribal knowledge）
- 仅仅依靠口头传递知识会有空间和准确度上的局限性
- 一旦形成缺乏真实性和准确性的信息传递习惯就可能会加速社区文化的腐败
- 然而如果我们有一个健壮的口头传递系统，结果就截然不同了。
- 开发者社区原本就有终极口头传递信息系统
- 我们可能会写下自己对某一部分的理解，但：
- 这些理解通常都是不完整的
- 我们也不会对这些文档和系统进行同步升级
- 只有当我们被问及更多的周边信息时才有可能得到修复
- 我们可能会写下自己对某一部分的理解，但：
- 口头传递系统最终会导致整个集体中的部落知识被沦为一种“部落神话”（tribal mythology）
- “为什么”将不再是一个可以回答的问题，“我们之前就是这么做的”。
- 部落神话是一种不需要理解的行为，它只是一种没有基础概念支撑的生搬硬套：
- “因为那就是我被教导的”
- “我不是很清楚，但是Joe说就是那样做的”
- 久而久之，这种理解上的缺失就会导致大量的不确定性以及人们对修改的恐惧
- “部落智慧”（tribal wisdom）则不同于部落神话，他是有效的。
- 它所约定的行为是可以被理解的
- 其中包含了对相关开发的原因和过程的解释
- 它是可以适应新的环境、新的状况和新的问题
- 它超越了简单的重复，为人们提供了相关行为背后的原因讨论。
- 在过去，对于系统中的每个行动或决定，都有人知道它那样做的理由。
- 继续深入研究那些决定，哪怕是微小的决定，也可能成为关键点。
- 正是这些小决定汇聚成了一个大系统
- 小设计构成了一个庞大的设计
- 只要能维持一个稳健的知识解释系统，我们就等于建立了部落智慧的传统。
- 部落智慧就是设计模式所要收集提炼的东西。
- 但不幸的是，人们经常将其理解为部落神话：
- 他们只关心如何使用设计模式
- 而不去理解为什么要用
- 但不幸的是，人们经常将其理解为部落神话：
- 问题：
- 模式和语言
- 开发人员对模式的理解常常和其语言有关
- 一些语言甚至可以轻松实现某模式背后所对应的概念
- 某些语言实现某些模式可能会更容易或自然，但它们实现其他一些模式可能就会很困难
- 在这种情况下没有那种语言是真正优于其他语言的
- 常常存在一种“神话”：认为设计模式能弥补程序语言的缺陷
- 事实并非如此：
- 无论它们是用什么语言实现的，
- 或者相关概念是否被内置成了
- 事实并非如此：