|
4. 优化编程 带着目的写代码 复制粘贴代码的人的另一个极端是，只是为了让代码看起来更漂亮（至少对他们而言）而改变代码。虽然有编程审美感是值得赞扬的，但改变代码以便让你觉得漂亮只是浪费时间（无用的冒险）。浏览并改变别人写的代码，让它看起来更漂亮，真是让人生气。 我有一个挑剔的同事，浏览我们的代码库时将所有的附加语都删除了。如果他只是清理了入门级员工写的代码，那可能没人会说什么，但那些附加语是我们团队的技术领导写的，他可是我们公司最出色的人物之一。 不要搞破坏 “代码重构”现在十分流行，但程序员往往以为它是指代码清理或重新设计。这个技巧是指重新组织代码，同时不破坏其他东西。如果你以改进的名义破坏已经存在的功能，那么你的意思就是：要么你的时间比其他人的时间金贵，要么你不破坏就不会整代码。 我有一个特别讨人嫌的同事，他决定重新执行我们系统中的解析器，但结果让代码变成其他所有人都不知道怎么写了。我让他恢复原状，之后发现代码能编写了，却不能运行了—–问他怎么回事，他说“应你的要求”，他移除了整个解析器。真没团队精神。 保持代码运行需要一些耐心和额外的工作——你勤奋地回归测试你的工作，在将函数添加到新代码中时，你可能需要暂时留住老代码和界面。但对于所有与这个代码库有关的人来说，这是必须做的。 找到瓶颈 人们总是谈论“最佳”，但这不是一个正确的词。我们极少将最佳作为目标——相反的，我们的目标是改进和权衡以达到足够好的表现。 在谷歌的电话面试时， 我被问到如何在一组有序的数字中搜索某个数字。显然，提问的人是在问二进制搜索法。但在现实生活中，我可能会做出“错误”的选择——从头找到尾。如果程序 表现足够好了，还花两倍的时间写两倍的、必须维护和调试的代码，那是毫无意义的，特别是如果那段代码并非程序的瓶颈（我严重怀疑如果那个数据是瓶颈部分， 你居然还会将它线性排列）。 如果你确实需要在程序的速度或空间方面达到最佳，折腾除了瓶颈以外的其他任何部分都只是浪费时间。 5. 自我管理 你可能对你那位讨厌的老板有各种抱怨，你的抱怨可能没错。所以你得成为你自己的管理者。即使你的老板人不错，他也不会站在你背后告诉你该写什么、怎么写才会快（尽管我肯定许多老板恨不得这么做）。 估计时间 程序员不能提供有用的时间估计，这是出了名的。但我认为这是无理指责，因为管理层往往作出更差的预测，并且程序员的警告往往被无视（这可能是所有工程的共同灾难）。但是，合理的时间估计对于按时完成项目仍然是关键的。 在一个商业软件项目中，我的有些同事居然乐得忘了产品交付日期——有人问是否已经交付了，另一个人才很惊讶地发现，日子已经过去好几天了。 更糟的也更普遍的是，程序员能给出的时间估计是“只需要几天。”每次我听到这话，或者我自己说出这话，我都感到害臊。 一家图像软件公司的总裁想让产品支持VRML（那时它是下一件大任务），包括我们将在两个月内发行的产品也支持VRML。他可能想到（他是正确的） 我会拒绝开始新项目，所以他问了另一个工程师，得到了他想到的回答：“只需要几天。”两天后，我告诉总裁，我们刚刚浪费了他和我的两天时间，因为有两百多 个更重要的漏洞要修复，他认为我的理由算是充分。（后话：VRML没有太成功。） 另一位程序员完全没有时间估计的概念。但没有必要完全拒绝时间的模糊属性——毕竟只是估计，事实上你应该避免太确切。如果你是一名有经验的工程师，你就知道你以前做类似的工作需要多长时间，如果你不是，那你就问问有经验的人。 我有一个聪明的朋友，经常被指派去开发实验原型，他问我：“你怎么估计时间？”我认为这是一个反问句，但甚至纯研究人员也要估计时间。有人支付他们，希望得到结果，即使它是许多演示样本或某段时间发表的文章。 如果你确实估计不准需要多少时间，那么你就不是做这项任务的合适人选。 有时候程序员不情愿承诺时间是因为他们害怕保证。确实，这个世界没那么美好，经理会在时间上跟你讨价还价，竞争对手可能用严苛或不切实际的安排来挤兑你，希望你失败。在你承诺时间后，你就悲剧了，你别想得到任何你希望的结果。 我曾有个老板问完成时间后会追问一句：“你保证？”但问他硬件条件和其他相关事宜时，他会说：“我尽量。” 我能说的只有，抓紧时间以及给出现实估计。任何让步都应该根据实际的介于产品和资源之间的交易。要根据假设、相关事宜和资源做时间安排，找个地方写下来，这样以后你就不用麻烦你不太给力的记性了。 计划进度 在决定上哪去以前，你不会跳上车的，对吧？你在开车时心里可能就有路线了。相同地，在你开始用电脑写以前，你应该知道你今天想完成什么，有一些想法了。 每天都会遇到分心的事，所以你不可能总是完成你想完成的事。与那些将软件工程团队当作自动贩卖机的人的想法相反的是，有些任务不是一天就能完成的。所以想想你到周五要完成什么，如果你完成了，那么周末你就可以好好过了。 |
