软件架构的十大错误

作者 Niclas Nilsson 译者 郭晓刚 发布于 2007年10月17日

领域

企业架构

主题

企业架构 ,

架构

标签

检查清单和指南

IASA成员Eoin Woods发表了一篇文章讲述他所认为的十大软件架构错误——常常要碰得头破血流才会得到的一些教训。这十大错误简要总结如下：

1. 不能界定项目范围。“在这种情况发生时，一个简单的出差登记系统结果变成内建了完整的花费报销管理系统，项目费用、时间跨度和质量都留下不可避免的烂摊子……除了简单的登录真的不需要安全措施了？用户登录系统后真的不能够执行任何系统操作吗？”
2. 网撒得不够宽。“我们都曾经犯过的一个错误是，只关注系统所有利益相关者中的一两方——通常受让人（为系统出钱的人）和最终用户得到了全部的关注。”
3. 只关注功能。“……除非系统表现出了全面的高质量（诸如性能、安全、可维护性等等），否则不太可能成功。”
4. 用方框和线条来描述。“[一个无所不包的]巨大的Visio图无法成为有效的架构描述，有两个原因：第一，它试图在单一表示中呈现太多信息；第二，没人真正清楚地知道你画的各种符号到底表示什么意思。”
5. 忘了需要培养的过程。“在建造系统的时候常常需要小心的事物包括：开发者和测试者没法真正理解设计，他们不热衷或者没时间学习技术，以及还没有很好的工具支持的新技术，或者新技术会强迫人们以新的不熟悉的方式工作。”
6. 平台定义不精确。“光用‘需要Unix和Oracle’来描述你的平台是不足够的。你需要精确地说明每一部分具体的版本和配置，才能保证得到你所需的平台。不然如果有人好心为平台的某一部分升级了一个库，就可能导致某些东西停止运作。精确定义平台你才能在部署中避免这样的情形。”
7. 对性能和伸缩能力想当然。“及早开始考虑性能和伸缩性，构建性能模型尝试预测关键的性能指标并定位瓶颈，在设计逐渐成型的同时投入到一些实际的验证性工作中去。这会帮助你提高对设计中不存在严重性能和伸缩性缺陷的信心。”
8. 自己发明安全技术。“多年来许多系统所犯的一个错误是试图加入自己发明的安全技术来提高系统安全性。比如定制的加密算法，开发者自己编写的审核系统，甚至完全DIY的访问控制系统。自家开发的安全方案基本上都是不明智的。虽然很多人都以为自己可以马上搞出一些聪明的安全技术，但通常都只是自作聪明。”
9. 没有灾难恢复。“要想得到资源来实现系统的灾难恢复机制，其关键在于在若干真实的场景中，具体衡量系统不可用所导致的损失。如果你还能估算这些场景发生的概率，你就可以用这两组数据去说服人们灾难恢复的重要性，并获得合理的预算去实现它。”
10. 没有撤退计划。“确保无论在系统部署或升级的过程中发生任何事，你都有一份书面的、经过审查的、一致同意的撤退计划，允许你将整个环境恢复到部署之前的状态。”

Eoin Woods是UBS Investment Bank的软件及企业架构师。

查看英文原文：Top Ten Software Architecture Mistakes

译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。

1. 返回顶部

   用方框和线条来描述

   发表人 曹 云飞

   那么用什么来描述架构？UML+ 文档 ?

   回复

2. 返回顶部

   有些错误不仅仅是架构

   发表人 小刀 凉粉

   比如说第一条，这完全是需求、计划等项目管理方面的问题。

   回复

3. 返回顶部

   进一步理解了什么是软件架构师

   发表人 霍 泰稳

   单从这10条来看，做个架构师真的不容易，也明白了一个国内技术专家参加MCA面试的失败经历这个新闻中作者所感慨的内容。一个在国内工作近10年的架构师很容易就在MCA面试官面前俯首称臣，原因是“知识体系不足”。

   回复

4. 返回顶部

   文章很好

   发表人 I TAX

   受教了。

   回复

5. 返回顶部

   的确如此！

   发表人 jong wake

   我们的项目已经无法满足所有的上述说法。

   回复

6. 返回顶部

   类似情况不少

   发表人 lin Liam

   1.不能界定项目范围
   亲身体会过，最后就是一个烂摊子，修修补补，需求不明确
   5.忘了需要培养的过程
   如果是国内IT的小作坊，有几家公司给予培训的时间和有培训新技术的计划？不要陷入项目就可以了...
   6.平台定义不精确
   的确，万一不小心升级，那就挂了。。。
   7.没有灾难恢复
   有多少人想到这个？或者想到了有实际实施

   回复

• 更早的 >