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