time 
设为首页】【收藏本站
当前位置: 主页 > 软件工程 > 软件过程 > 软件工程的25条建议

软件工程的25条建议

时间:2009-12-04 22:56 点击:1148次 字体:[ ]




  1. 人远比技术重要

  你开发软件是为了供别人使用,没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平,因为他们那时侯将主要精力都集中在技术上。显然,构件(components),EJB(Enterprise Java Beans)和代理(agent)是很有趣的东西。但是对于用户来说,如果你设计的软件很难使用或者不能满足他们的需求,后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。

  2. 理解你要实现的东西

  好的软件设计人员把大多数时间花费在建立系统模型上,偶尔写一些源代码,但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。

  3. 谦虚是必须的品格

  你不可能知道一切,你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作,因为软件开发所用到的工具和技术是在不断更新的。而且,一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说,每天可以学习很多新东西(如果愿意的话)。

  4. 需求就是需求

  如果你没有任何需求,你就不要动手开发任何软件。成功的软件取决于时间(在用户要求的时间内完成)、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么,或者软件的需求定义,那么你的工程注定会失败。

  5. 需求其实很少改变,改变的是你对需求的理解

  Object ToolSmiths公司(www.objecttoolsmiths.com)的Doug Smith常喜欢说:“分析是一门科学,设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要(我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注)。

  如果需求经常改动,很可能是你没有作好需求分析,并不是需求真的改变了。

  你可以抱怨用户不能告诉你他们想得到什么,但是不要忘记,收集需求信息是你工作。

  你可以说是新来的开发人员把事情搞得一团糟,但是,你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。

  如果你觉得公司不让你与用户充分接触,那只能说明公司的管理层并不是真正支持你的项目。

  你可以抱怨公司有关软件工程的管理制度不合理,但你必须了解大多同行公司是怎么做的。

  你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念,但是为什么你没先想到呢?

  需求真正改变的情况很少,但是没有做好需求分析工作的理由却很多。

  6. 经常阅读

  在这个每日都在发生变化的产业中,你不可能在已取得的成就上陶醉太久。

  每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱,但会使你成为一个很有实力的竞争者。

  7. 降低软件模块间的耦合度

  高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

  你可以通过以下方法降低程序的耦合度:隐藏实现细节,强制构件接口定义,不使用公用数据结构,不让应用程序直接操作数据库(我的经验法则是:当应用程序员在写SQL代码的时候,你的程序的耦合度就已经很高了)。

  耦合度低的软件可以很容易被重用、维护和扩充。

  8. 提高软件的内聚性

  如果一个软件的模块只实现一个功能,那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

  判断一个模块是否有高的内聚性,看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词,则说明你需要将该模块细化。

  只有高内聚性的模块才可能被重用。



本文地址 : http://www.fengfly.com/plus/view-159860-1.html
标签: 模型 设计 软件工程 软件 需求 建议
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码: