如何改进软件专业人士的职业生涯

 chinaunix.net   2008-01-15 11:53:00  
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  你需要全面理解如何成为一个有效率的专业人员。