领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
讨论：烦人的细节
作者 Abel Avram 译者 侯伯薇 发布于 2011年11月29日
Bob大叔和Simon Brown关于描述系统架构时基础架构（infrastructure）所起的作用展开了讨论。
在之前标题为 《尖叫的架构（Screaming Architecture）》的文章中，Robert Martin（也就是Bob大叔）阐述了这样的观点：软件产品的架构应该让所有人都很容易了解产品所要达到的目的，并且系统的架构应该反应系统的用例而不是它使用的框架：
架构不是（或者说不应该是）关于框架的内容。架构不应该由框架支持。框架是我们要使用的工具，而不是要符合的架构。如果你的架构基于框架，那么它就无法基于你的用例。
此外，好的架构应该让我们可以推迟那些不确定的，与框架、数据库、web服务器等等相关的决定，Bob大叔如是说：
好的架构让我们直到项目的后期才需要决定使用Rails，或是Spring，或是Hibernate，或是Tomcat，或是MySql等等。好的架构也让我们能够轻松地改变这些决定。好的架构强调的是用例，并把它与周边的关注点解耦。
Bob大叔还谈到了互联网，想知道那是否也应该被认为是边缘关注点，并做出结论，网络也是一种“交付机制”：
网络是一种交付机制，你的应用程序架构应该这么来对待它。你的应用程序是否通过网络交付是一种细节问题，系统结构不应该取决于此。实际上，你的应用程序是否通过网络交付是你应该推迟考虑的事情。你的系统架构应该尽可能地与如何交付无关。你应该可以把它作为控制台应用程序、web应用程序、富客户端应用程序、甚至是web服务应用程序来交付，而不需要让基本的架构过度复杂或者对其做出变更。
Bob大叔文章的结论是：你的架构应该告诉读者与系统相关的内容，而不是你在系统中所使用的框架。
Simon Brown是一位软件架构师，他对Bob大叔关于“交付机制”的观点发表了评论，称之为“烦人的细节”。他同意Bob大叔所说的系统架构不应该是它所使用的框架，但是他还说到，他希望“看到软件架构能够落地，那就需要包括所选择的实现技术。” 关于推迟决定采用何种基础架构，Brown说到：“如果我们需要做出某些关键的技术决定，那么肯定就需要完成，是吧？”，然后他问道：“如果我没有，或者不能推迟做出决定，那就一定意味着我拥有很差的架构吗？ 我们难道不应该把推迟作为一种有意识的决定，而不是一种规则吗？”
Bob大叔在从架构角度考虑的时候只关注系统的核心领域知识，而Brown的方法则与之不同，他认为“交付机制”当前是很大的一块工作，应该整合到总体架构之中，如下图所示：
Brown的结论是：
对我来说，架构不仅仅是包含在“应用程序”中的内容。结构很重要，但是还有很多重要的内容，像非功能性需求、实际的交付机制（技术、框架、工具、API等等）、基础架构服务（例如：记录日志、异常处理、配置等等）、集成服务（内部和外部的）、满足所有环境的限制（例如：运维和支持）等等。对我来说，所有这一切都与架构相关。
讨论并没有就此结束。Bob大叔在另一篇博文《整洁的架构（Clean Architecture）》中对Brown的观点作出响应，他说，不管用户界面和数据库部分有多大，系统的架构都不应该面向这些“较大的元素”，并且“其他部分应该与之解耦”。他继续解释说，将核心领域知识与交付机制解耦非常重要，并说他不会特意地延迟和停止作出与框架相关的决定，但是架构师应该总是可以保持这两部分清晰地分离，即便这两项工作同时进行：
我曾经做出的更尖锐的关于架构的评论是，好的架构让你可以延迟做出一些重要的决定，像用户界面、框架、数据库等等。但有些人指出，客户不希望延迟用户界面方面的工作。DBA也不希望延迟数据库方面的工作。在每次迭代完成的时候，他们都希望看到整个系统可以正常工作，包括用户界面、数据库和框架。他们不希望一次迭代只处理业务规则问题。事实上，好的敏捷实践特别要求对整体架构做“长而薄”的切分。
当然，我完全同意这一点。然而，“长而薄”的内容不需要同时进行。好的架构让你可以延迟做出重要的决定，它并不会强迫你延迟这些工作。然而，如果你可以延迟，那么就意味着你拥有更大的灵活性。例如，你可以在前面的几个sprint中创建临时的简单用户界面，然后再用更完备的用户界面来替换。
Bob大叔做出结论说：“先处理这些烦人的小细节也没什么问题，只要你能够将业务规则与它们解耦。”
Brown在对《整洁的架构》一文的回复中做出响应：他同意Bob大叔关于解耦的观点，但是在处理基础架构方面提出了不同的观点：“交付机制并非是可以延迟到‘世界末日’的烦人细节”，尽管Bob大叔坚持该工作是细节问题。Brown的结论是：
- 将应用程序的代码和技术解耦很不错，而且是我们应该尽力做到的。这样得到的代码更易于做单元测试、易于替代、易于维护、易于修改等等。
- 软件架构是与全局相关的，而应用程序的代码只是全局中的一部分。
- 如果你仍然把“交付机制”这样的重要决定推迟，并且不考虑如何解决重要的非功能性需求和约束，那么就不得不面临软件项目失败的风险。
在讨论中，Bob大叔和Bronw并不真的是处于对立的双方。他们都支持要清晰地分离核心领域知识与支持框架，但是前者更关注于领域知识，而后者认为还需要考虑并重视基础架构。你的方法是怎样的呢？
查看英文原文：Debate: The Annoying Detail译者 侯伯薇 是InfoQ中文站架构社区编辑，有多年对日和国内项目开发经验，目前关注企业中技术与实际业务之间的融合和协作。
吃饱了撑的
发表人
xiu calvin
发表于
菜鸟还是先修炼好各种技术内功，才可以谈得上架构。
发表人
陈 国栋
发表于
无聊的讨论
发表人
Yang Bob
发表于
3 条回复
关注此讨论 回复