作为软件工程师， 你希望从工作中获得的是：稳定的薪水、参与好项目的机会、好工作的跳板或只是和其他程序员成为好基友。这里的“高效”，我指的是按时完符合要求的项目的能 力。经历过不少软件编写工作后，我相信以下实践会帮助你学会“高效”，同时提高专业声望、拉长职业寿命，和获得个人满足 1. 理解你的需求 成为高效程序员的第一步是，保证时间的合理分配。没有什么比将时间花在完全没有前途的工作上更浪费的了。 尽快开工 尽快完成一个直观的系统。这意味着先创建界面，无论是程序界面还是用户界面，然后生成内部功能的存根代码（如果有必要的话）。这么做便于“客户”查 看，通过执行用户界面或编写程序界面的代码，可以发现最初代码存在的矛盾或遗漏。甚至在第一次交付以前，你有可能会注意到问题或可改进的地方。 有一个经典观念认为，如果你提前设计好所有东西，那么之后你要做的就只剩写代码了。如果你之前做过完全相同的项目，那么这个说法当然正确。但如果不是，你很可能会陷入死角，也就是你只是在猜想或执行一个可疑的假设。 很早以前在一家无线网络的新公司工作时，我们开了两个月的会来设计一个将在6个月内发布的无线门户和网关。最终，我们厌烦了开会，开始编写代码。头两周内，我负责的部分与原始设计不符，两个月后的第一个无线连接测试表明，我完全误解了无线协议。 这不是说设计是没必要的。但在一定程度上，设计只是一种猜想。设计应该通实执行来确认，并且早执行总是比晚执行好。 即使原始设计是充分的，只要你发现可以调整的地方，你就要改进它。硬件产品、建筑和大型软件项目等会受到僵死的“预制”的损害，但对于软件，你可以在项目早期提炼项目要求，然后制作适合的界面。但是，这必须尽早完成。 尽早开工有利于树立你的职业形象。如果能向你的老板展示一些成果，他会很高兴的。另一方面，提早开工有助于缓解焦虑。 经常交付 一旦你完成一些可用的东西了，不要只是把它留作“概念实证”。要让其他人试执行它、看看他们的反应，然后让它指导开发过程的优先次序。观察人们如何 使用你的软件，这是无可代替的方法。客户问卷调查和焦点研究可能会提供一些有用的意见，但有可能会让开发者的设计决定和特点被客户牵着鼻子走，这是一种冒险。 特别是要尽快将软件交付QA人员，经常提交成果，最好是按预定的时间间隔。让他们测试每天的成果，或至少是每周的成果也是好的。这会让QA人员觉得 自己全程参与项目开发，从而培养职业责任感，更乐意发现和报告问题。最需要优先解决的是导致产品失效的问题，如崩溃或死循环——让问题尽可能涵盖多方面， 熟悉整个产品，这样才有可能提早发现设计问题。 在一个小型3D软件公司，我负责移植从SGI出品的龙头产品到Windows NT。6个月后，移植没完成，倒有了崩溃的倾向，我很不情愿地将第一轮成果交付测试团队。幸运的是，因为漏洞太多，QA经理坚持要我立刻解决导致测试人员 无法有意义地使用程序的问题。如果是我自己测试，我应该会忙于看起来更困难更重要的核心3D问题，可能会怠慢看来起比较普通的问题，如用户界面、载入-保 存功能和与计划支持的硬件之间的兼容性。 程序员常常不想过早将代码交付测试人员——他们不想听到自己已经知道的漏洞；而测试人员极有可能不想测试基本上行不通的东西。但测试人员的工作就是找到这些问题。如果程序员想尽快看到成果的话，应该把漏洞报告当成好东西。 2. 把工作当真 将软件放在尽可能接近完工的状态下运行。你永远不知道你什么时候得演示系统、发送评估备份或甚至交付。 使用真实数据 如果你只用作为着冰山一角的样本数据作测试，那么，你的程序可能一撞上真实数据的大冰山就沉了。 我曾参与开发一种用于评估先进的半导体绝对值的供应链管理产品。跨过交付这道大坎后，我们接到消息说他们输入的第一批真实数据仍然在处理中——已经两天了。我同情主程序员，他不得不在管理人员和客户的催促之下忙活了两周。很高兴遇上这事的人不是我。 使用正式版本 记住，用你自己的机器创建的东西不是正式的。 在最近的一个游戏开发项目中，我负责用户界面，我陆续从QA那接到报告说有些颜色不对。最后，我发现问题只出现在交付版本中，另一位程序员使用专门 的主机调试工具找到了漏洞。结果竟是一个我在两个月前犯下的愚蠢错误，没有指定初始颜色值。调试版本总是选择特定的默认值，但是交付版本会更改，最终结果 是不太确定的。如果我注意经常地运行交付版本，我会立刻发现问题的，而不是损失大量的时间。 经常合并 及时将你的代码并入主代码库中——你拖得越久，这项工作就越累。 我曾与一名程序员共事，他觉得每天数据库中出现的所有新代码和数据变化都“很麻烦”。确实，这让所有其他程序员每天都要花一定时间合并，他才能够只 扫视一下代码和数据就开始运行一些不错的独立样本。但每一次阶段{敏感词}付时，我们都要花好几天再次把单独的代码接到当前的代码库中，有时候甚至得拖延交付或 冒着损失整个项目的风险。 将你的代码与正式版本分开意味着程序员不能评估你的代码，以及测试员不能尽早发现漏洞。可能你并不想其他人挑剔你的代码，但早发现问题总是比晚发现好的——所以，忍了罢。 |
