SoftEng 版 (精华区)

发信人: Sun (大灯泡), 信区: SoftEng
标  题: 千年决心
发信站: 哈工大紫丁香 (2000年09月03日11:19:44 星期天), 站内信件

千年决心

在新前年的开始,让我们花点时间为自己的事业下点决心。
by Scott Ambler 
翻译 BUG

在2000年1月1号的零点。不管在1999如何如何，依然有电，水还在流，世界上的金
融系统仍在加加减减的正常运行。]这已经是新千年的开始，但你仍要作些新年誓
言。是的，你可以发誓减肥或是更多的在外工作，但你是否可以持续一到两周？不
如作些承诺改进做为软件专业人士的职业生涯吧。请仔细想想以下的一些决定:

我不妨碍他人。
你不应只想玩玩，就使用技术。你用技术，因为这合情合理，或对
解决在手边的问题有用。许多开发者仅仅为了获取经验而建议使用如EJB（
Enterprise Java Beans）或COM+等流行的技术。这你是在浪费你老板的时间与金
钱来实现自己的目标。另外，不要为了揭示你的单位软件结构的弱点而引入病毒，
或删除数据或程序。如果真的有弱点，通知管理层，不要造成任何损害。

我会适当的重用任何可重用的东西. 
因为大家喜欢从零开始，而不是重用已有的成
果，这些年，软件专业人士的生产率并没有显著的提高。有很多的软件成果可以被
重用，如原代码、部件、文档、文档模板、模型甚至通过应用模式重用其他人的技
术。只要可以，就去致力重用其他人好的工作成果，而不是假象你可以从零开始做
事，并比其他人更好（不幸的是，这正是许多一般开发员的心态）。现在，重新发
明"轮子"，并不是一件荣耀的事。

我只开发基于实际需求的软件。
如果你没有需求，你不需要开发任何东西。无论什
么类型的系统，你总可以从为它定义需求开始。人们或其他系统如何使用你的系统
？它需要怎样好的执行？它必须具有什么样的使用特点？它必须在什么平台下运行
？不管你的系统使用什么技术，它是什么样的业务类型，你总可以先确定它的需求
。其他都是干咳。

我会在编码前先建模. 
最有效率的开发员会首先建模，并只有在他们认为完全理解
了要做什么了后，才会开始编码。你在建模上的精力或许简单如只是在餐巾纸上画
几幅简图，或是复杂如使用业界领先的CASE工具画出一整套图形。其中的含义，非
常简单：先想，后做（运筹帷幄）

你要能够辩明你的工作. 
你为什么正在开发你的系统或相关部分？你是否知道它技
术上的可行性？是否其他人做过该类原型，显示出你正在做正确的工作。你的软件
在经济上有意义吗？它是否值得去做，是否可保持你的组织的竞争力或打开新的市
场？一旦你开发的产品完成后，是否你的组织能够操作它？你是否有一些人可以操
作并维护该系统？是否可以得到操作规程和文档？是否有支持计划？如果你不能辩
明你的工作，为什么你还在做它呢？

我会停止重复教条. 
给予项目组最大损害的是那些相信如：数据至上，编码最重要
，或是我们是用例驱动等一些小教条的人。软件开发非常复杂，这些教条只是覆盖
了对于过程的缺乏理解问题。实际上，数据只是整个过程的一个小部分；而为了使
软件成功，需要的不仅仅使原代码；对描述需求来讲，仅有用例是不够。教条只是
在人们之间建立了阻碍，并减小了小组的成功机会。

我会从不同的角度来看工作. 
不管你在项目中的角色，你应总是同时针对几个相关
部件。业务分析员在调查问题域时可以开发用户界面、用例和领域模型。建模者在
设计软件时可以开发顺序图、类模型、部件模型、状态图和数据存储模型。程序员
在实现软件时可以编写代码、测试用例和编写原代码文档。只关心一个产品部分，
或是项目进度、或是用户界面原型、或是原代码或数据模型，将经常导致发布结果
达不到软件总体需求。

我不仅仅关注软件的执行. 
成功开发不只是做出执行速度快的软件。根据项目的类
型、级别不同,创建可扩展、可理解、可维护、可用或重用的软件也许更为重要。
软件执行速度仅仅只是软件评价标准的一方面，但是太多的开发员只注重该项，而
影响了他们整个的工作质量。

我会尊重客户并同他们紧密协作. 
你开发软件的唯一理由是为了支持客户。只有客
户能够告诉你他们需要什么，因为他们是业务领域的专家。为了保证你建立正确的
系统，与客户紧密工作难道不是非常有道理吗？ 

我只接受符合实际的项目计划. 
组织或市场的压力经常导致项目计划不符合实际。
无论何时，只要使用"如果每件事都按我们估计的方式发展，而且我们足够幸运的
化，我们就可以将项目作好"来阐明计划的话，那你就有麻烦了。事情不总是按你
想象的方式进行，不管多少人力投入一个项目，许多软件的开发的不同工作都会耗
费非常大量的时间来完成。记住，九个女人也不能在一个月里生一个孩子。如果你
迫于压力，接受了一个不切实际的项目计划，那么你必须回去向老板阐明计划不实
际的原因。你的理由也许不被接受，你还得执行该计划，但至少你为项目进行了争
取。有不现实计划的项目组常常时采取了捷径，但却导致项目在远远落后于进度时
，项目仍在停步不前。

我会持续改善我的沟通技巧. 
如果你不能与其他人有效沟通，好点子又有什么用呢
？你也许可以写出世界上最好的原程序，但是，你不能写一封E-MAIL来告诉你的老
板与小组成员你所做的，那么你的杰作可能根本得不到承认。

我会养成学习的习惯. 
在你躺在你的荣誉上时，软件工业的技术与技巧在飞速改变
。试着每月读几本相关杂志或至少一本技术书籍。我曾经接受到的一些最好的建议
是扩展视野，并读一些商业杂志。商业相关的阅读使你具有同用户联系的背景知识
，它是成功的一个关键因素，因为软件是为支持用户的使用而开发的。参加与工作
有关的课程或会议也应是你学习过程的一部分。

我要测试所有我开发的. 
如果你可以构建，你也可以测试。你可以通过查看需求文
档、设计、并执行多次测试来检测代码。如果一件事不值得测试的话，那么为什么
还要做它呢？

我要文档化所有我开发的. 
现代软件开发模式是你做为一个小组成员进行工作，如
果没别人能够理解你的工作，那你就没有对工作做出任何贡献。很明显，好的文档
能使你的工作容易被理解。实际上，简而言之，好的程序员在开始编码之前，会文
档化他们的代码。

我认同软件不仅仅是技术. 
技术是有趣的，但它只是开发软件过程中的很小一部分
。不管是好是坏，你的工作需要你熟练地与用户、经理、同事、卖主或操作人员打
交道。 

我认为软件不仅仅是开发. 
你必须牢牢记住，你的用户，或是你的上层经理，在你
开始工作前，很可能已经花费了极大的精力来挑选和识别软件开发项目。一旦你将
软件发布给用户，该软件必须要被维护、使用和支持。你需要全面理解如何成为一
个有效率的专业人员。

你正在新前年的开始，一个独一无二的历史时期，几乎每个人都在迷惑如何看日历
。你可以或是以头撞墙来向其他人解释，2000年是千年的最后一年，不是新千年的
第一年，或是放弃解释，将注意力转向改进你的软件开发技巧。
 
依从我这里的一条或几条建议将给你带来成功，同时需要指明，经常去去体育馆也
是个不错的注意。 


--
    太阳就是个大灯泡。
    那灯泡是什么呢？
    是光光！

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: sunner.hit.edu.cn]