论编程的最后期限.docxVIP

论编程的最后期限　英文原文：On Programming Deadlines　普通编程与专业编程之间有很多差别，而最为显著的就是截止日期。　截止日期 / 最后期限　当你给自己写程序的时候，只要你愿意，就可以用很多（或者很少）的时间来完成，但是当你给别人写程序的时候，你就只有一点有限的时间和资源来完成任务。而根据我的经验，一般会导致以下两种情况之一：　1. 你必须延长时间以妥善完成任务；　2. 你必须写些不严谨的代码来应付过关。　如果你做过专业编程，你会明白我的意思。只有极少数灵活的项目能够给予足够的时间和资源来完成任务。这就使得程序员必须做出艰难的抉择。　任何一个有自尊的程序员都不愿意提交不合格的代码。但是当交易中伴随有超时违约金时，想要始终提交高质量的代码是很困难的，尤其是在专业环境下，与那些不需要理解技术违约概念的非技术员交易。　幸好，这里有几条准则供你参考，可以在临近截止日期时，帮你把不严谨的代码总数最小化。它们不一定能够快速修复问题，但毫无疑问将有助于那些需要日复一日，始终写出一流代码的人。　准则一：编码之前设置连续部署　这是我从《The Pragmatic Programmer / 程序员修炼之道》一书（绝对是程序员的必读之书）中找出的小窍门。总是，我是说总是，在编码之前设置你的连续部署系统。　我所说的连续部署是什么意思？好的，在你开始编写你的项目之前，你应该有一个能部署你的项目代码为产品的系统（最好对于演示和开发环境也是如此）。这样，当你编码时，你就会有一个平和的心态，因为你知道你可以随时部署你的项目。　在很多开发流程中，这一点能节约相当多的开发时间。相比于在测试环境中部署/调试代码（或者更糟，直接在生产服务器上），你可以直接把代码推送至你所用的源代码控制系统中，然后让你的连续部署系统负责接下来的事情。这也许看起来不像个节约时间的方法，但是如果你考虑一下每天都要把你的代码复制过去并手动测试所浪费的时间，你就知道这样做能快速完成并在每月中节约数小时。　准则二：先写测试　如果你从没听说过测试驱动开发（TDD），请立刻看看维基百科的解释。如果有人付钱让你编写软件，并且规定了截止日期，你就要随时练习 TDD。　测试驱动开发的基本概念是，在写项目代码之前，你写一段简单的代码来测试你假设的项目代码，以获得预期的反应。例如：你的项目需要你写一个函数，把两个数相加，并返回和。在写这段代码之前，你应该写一个测试函数，test_add_two_numbers，它调用你的 add_two_numbers 函数来验证不同的输入值所返回的结果都是正确的。　这看起来很麻烦，但是它有许多好处：写测试首先能帮你明确你的应用程序架构。你将有一个平和的心态，因为你知道你的代码是可运行的。你能够轻易的重构项目，而不用担心破坏代码。你可以避免放出低质量的代码，以免玷污你的声誉。　准则三：透明（Be Transparent）　透明很难实现（取决于你的工作环境），但却非常有益处。　为了达到透明，你需要确保与接收代码的客户之间保持一条清晰的沟通途径。你需要保持定期更新，这样才能看出来工作正在进行，并且进展到哪里。更好的一点是，你能一直部署代码到演示系统，从而让客户够看到未完成的项目和它一天天的改变。　如果你能跟你的老板（们）保持透明化，他们就很有可能了解是否需要推迟截止日期。非技术人员通常不懂软件开发，视它为黑盒技术。通过与客户保持清晰的沟通和透明化，并让他们参与到开发进程中，客户可以更了解你的工作，使得对将要开发出来的产品更青睐。　规则四：维持日常计划表（Todo list）　时间管理问题肯定是超出本文谈论的范围，但是我仍要指出，为确保事情一直向前进展，作为一名程序员你所能做的最好的事情之一就是维持一份日常计划表。另外，一个得力的时间追踪工具也能帮上大忙。（老外推荐的/10-terrific-apps-to-help-you-track-your-time/10个时间追踪工具）　软件开发是极为复杂的事情。成为一名优秀的程序员要求有多年的实践，耐心和锻炼，并且学无止境。当需要在截止日期内开发软件时，往往你正在编写一个复杂的系统。为保持思路清晰，并且确保发挥你编程的最大能力，你应该维持一份由每日需要完成（编码方向）的单独的任务组成的日常计划表。　不要写过于空泛的计划表，像“调试声音问题”这样的，而是要真正地想一遍，并且写出事情的几个步骤。例如：写一个音乐文件加载功能的单元测试，检查 mp3 是否能够播放。写一个音乐文件加载功能的单元测试，检查加载 wav 文件时是否崩溃。创建新的特性分支，设计升级，适用于新的网页设计模板。使用网页设计新模板升级 style.css。　有一个明确的可操作的事件列表可以使你集中力量在一段时间内解决一个单独的任务。这样就不用时刻平衡分