架构是否会在开发人员和应用之间划出鸿沟？

作者 Sadek Drobi 译者 李剑 发布于 2007年12月16日

领域

过程 & 实践,

架构 & 设计

主题

交付价值 ,

客户及需求 ,

协作 ,

软件工匠 ,

团队工作 ,

反模式 ,

架构 ,

人际沟通 ,

敏捷 ,

模式 ,

可用性

分享到

当今，在软件社区内的众多努力，都旨在帮助软件专业人士和业务人士相互理解，顺畅沟通。有些博客的作者则从另外一个角度来看待这个问题，指出了开发人员和他们所开发的软件之间的一条鸿沟

Jeff Attwood认为，Amazon常常让开发人员参与到客户服务中去的这种做法，对于提高软件质量和可用性是大有裨益的。他相信，“绝大多数时候，软件开发者仅仅是他们自己代码库的过客”。这种状况的出现，是因为他们缺少对软件用户，以及用户的问题和思维的基本理解。这也就是他在之前的博客中所提到的“象牙塔中的软件开发”：

没有任何足以服人的证据，开发人员便假定其它所有人都是开发人员……开发者越孤立，其最终产品也就越糟糕。纵然大多数团队中都有业务分析专家，以充当开发者和用户之间的隔离层为己任，那也是无济于事……想创建一个让开发人员对用户毫无所知的环境是极其危险的。

按照Abhijit Nadgouda的说法，今天的这个行业的特点是层次结构和各层之间的信息隐藏（译者注：请自行翻墙）。他特别指出，这一点简化了管理工作，并让业务变得更加安全，但是对软件质量却有着负面影响：

我们在项目中创建了一个层次结构，每一层都向低层隐藏了一些信息。软件开发团队中有多少人了解他们所开发的软件的价值，或是它对于客户业务的重要性？又有多少人了解他们所工作的代码之外的其它项目组成部分？

……

看上去，在更好的业务与更好的软件开发之间有着断层。这就是为什么我相信我们中的很多人善于经营业务，但是我们这个行业却仍受困于软件开发。

Reg Braithwaite在尝试指出为什么“我们仍受困于软件开发”（译者注：请自行翻墙）时特别提出，我们这种“把经验最少的人置于保护之下以免破环代码”的拆分项目工作的方式也许是错误的。

基于这种工作方式的架构，明显是趋向于通过抽象来简化开发者的工作。如果把它推向极致，开发者的工作就从功能性的环境中脱离开来，变成了纯粹的技术工作，由此便在开发者和他们所开发的软件之间，划出了一道潜在的鸿沟。

你的观点是什么？这种保护性的架构对于软件质量是一种障碍吗？让开发者对项目全景一无所知的架构会是有效的吗？它能够交付软件和价值吗？

译者 李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！

1. 返回顶部

   我觉得你的提问在逻辑上犯了一些错误

   发表人 王 辉

   @这种保护性的架构对于软件质量是一种障碍吗？让开发者对项目全景一无所知的架构会是有效的吗？它能够交付软件和价值吗？
   ----------------
   首先，这的确是‘保护性’架构，但并不代表分层就是封闭；另外，项目成员对项目全景的知晓程度并不在于职责明细化，恰恰相反，这种隐藏一定细节的做法更有利于全局把握；架构设计上确实可能会造成一些开发成员懒于去了解全局，但这一点可以通过其他途径很好的解决。最后一句话没明白，偶鸟文水平有限。

   回复