作者：Randall Degges
翻译：Robbie Fan
Year 2011
http://rdegges.com/on-programming-deadlines
Random thoughts of a happy programmer.
某个乐呵呵的程序员之随想。
On Programming Deadlines
有关编程的截止期限
There are a lot of differences between programming, and programming professionally. The most notorious of which, is deadlines.
在“编程”与“职业的编程工作”之间有着很多的区别。其中最明显的一点，就是截止期限。
Deadlines
截止期限
When you're writing code for yourself, you can spend as much (or as little time) on it as you please--but when you're writing code for other people, you've got only a limited amount of time and resources to get the job done. In my experience, this typically leads to one of two situations:
当你为自己写代码的时候，你可以想搞多久就搞多久，或者想马马虎虎能用就草草了事也可以。但是当你在为他人写代码时，你只有有限的时间和资源来完成任务。在我的经验里，这通常导致两种情形：
* You've got to extend the deadline to finish the job properly.
* You've got to write some dirty hacks to finish the job.
* 你必须延后截止期限才能将工作做得妥善
* 你必须用一些难看的、有不良副作用的代码来快速完成工作
If you've ever done professional programming, you know what I mean. Very few projects are agile enough to allow for both sufficient time and resources to get the job done. This leads to tough decisions for programmers.
如果你做过职业的编程工作，你就知道我说的是什么。很少有项目是灵活到允许有足够的时间和资源来完成的。这样，程序员就必须面对艰难的选择。
No self-respecting programmer wants to deliver sub-par code; but it's difficult to consistently deliver high-quality code when dealing with time obligations, especially in professional environments where you're dealing with non-engineers who don't necessarily understand the concept of technical debt.
没有一个有自尊的程序员愿意交付质量比标准要求还低的代码；但是要持续不断地交付高品质的代码，同时又要应对时间上的要求时是很难做好的，特别是在专职工作中应对那些并不懂得什么叫“技术负债”的非专业人员的时候就更困难了。
Luckily, there are some guidelines you can follow to help minimize the amount of hackery you have to do when writing code on a deadline. They aren't necessarily quick-fixes, but can certainly be helpful to anyone who needs to consistently push out top-notch code, day after day.
幸运的是，有一些准则你可以遵循，以期尽可能地避免在有截止期限的编程过程中不得不做的“不良代码”。它们并不都是立竿见影的，但一定能对需要稳定地按时交付高质量代码的人有所帮助。
Rule 1: Setup Continuous Deployment Before Writing ANY Code
规则一：在写任何代码之前，建立持续部署的环境
This is a tip I picked up from The Pragmatic Programmer book (definitely required reading for any programmer). Always, and I mean always, setup your continuous deployment system before writing code.
这个是我从《The Pragmatic Programmer》（中文名《程序员修炼之道》——译者注）一书中学到的技巧（毫无疑问这是一本每一个程序员的必读的书）。总是，我说总是，在你开始写代码之前建立持续部署的环境。
What do I mean by continuous deployment? Well, before you start coding your project, you should have a system set up that lets you deploy your project code into production (and preferably staging and development environments as well). This way, as you write your code, you'll have the peace of mind that comes with knowing your project can be deployed at any moment.
我所说的持续部署是什么意思呢？唔，在你开始为你的项目写代码之前，你应该有一个系统，在这个系统里可以把你的代码变成最终的成品（如同用户见到的，可运行的形式——译者注）（而且最好同时是一个阶段性发布以及开发也都在上面进行的平台）。这样一来，当你写你的代码的时候，你就会有一份平和的心情，因为你知道你的项目可以随时被部署。
In a lot of programming workflows, this can save tons of development time. Instead of scp'ing your project to some testing environment (or worse, coding directly on a live server), you can just push your code to your preferred source control system, and let your continuous deployment system take care of the rest. It may not seem like much of a time saver--but if you consider the amount of time it takes, day after day, to copy your code over and do testing manually, it can quickly add up and save hours of time each month.
在很多的程序开发工作流程中，这会节约数以吨计的开发时间。不要说手工地用 scp 命令（一个 Unix 下的支持加密传输的拷贝命令——译者注）把你的项目拷贝到一些测试环境中（或者更坏，在一个远端服务器上直接编程），你可以只需要把你的代码更新到你喜好的源代码管理系统中，然后让你的持续部署系统自动地处理其余的事情。这可能看上去并没节省多少时间——但是你考虑一下，每次都手动拷贝代码并手动测试，一天天累积下来算的话，它能在一个月内节省几个小时的时间。
Rule 2: Write Tests First
规则 2：先写测试
If you've never heard of test-driven development (TDD), please read the wikipedia article on it immediately. If someone is paying you to write software, and you've got a deadline, then you need to be practicing TDD at all times.
如果你从未听说过测试驱动开发（TDD）的话，请马上阅读有关它的 wikipedia 文章。如果某人付钱请你写软件，并且给你一个截止期限，那你应该不停地采用 TDD。
The basic concept of test-driven development is that before writing project code, you write a simple piece of code that tests your hypothetical project code for desired behavior. For example, let's say your project requires you to write a function that adds two numbers, and returns the sum of these numbers. Before writing that piece of code, you should write a test function, test_add_two_numbers, that calls your add_two_numbers function with various inputs, and verifies through assertions that the results you get back are proper.
测试驱动开发的基本概念是你在写代码之前，你先写一小块代码，用于测试你假想的项目代码是否实现了预期的行为。比如说，假设你的项目要求你写一个函数把两个数字相加，并返回两个数字的和。在写这段代码之前，你应该先写一个测试函数，test_add_two_numbers，它用多种不同的参数调用你的 add_two_numbers 函数，并通过断言（assertions）来验证你得到的结果是正确的。
This may seem like a bit of a hassle, but it has numerous benefits:
这看起来有一些麻烦，但是它有几点好处：
* Writing tests first help you clarify your application architecture.
* You have the peace of mind that comes with knowing your code is operational.
* You're able to easily refactor parts of your project without worrying about breaking code.
* You can avoid releasing low-quality code, and tarnishing your reputation.
* 写测试能帮助你明了你的应用程序架构
* 你将会有一份平和的心境，因为知道了你的代码能工作
* 你能轻易地重构你项目中的部分代码，而不必担心不小心把它搞坏
* 你可以避免发布低质量的代码，从而维护你的名誉
Writing tests certainly takes time and effort, but can save time in the long run by avoiding emergency bug-fixes, system crashes, etc. Especially when you're on tight deadlines, you don't want the added stress and worry of buggy code.
写测试自然会占用时间和精力，但是能在长期来看能节省时间，比如能避免紧急补丁的必要、避免系统崩溃等等。特别当你在紧迫的截止期限下，你不想再为有缺陷的代码而紧张费神。
（不过，在使用 TDD 之前，请确认领导层的支持；否则，领导层会认为编写测试代码的时间是浪费掉的。此外，使用了 TDD 之后，不要忘记人工的测试，特别是 ad hoc 测试（随机、自由的测试）的重要性。另外，测试本身也将成为项目维护的一部分，会增加维护成本。参见 http://en.wikipedia.org/wiki/Test-driven_development。——译者注）
Rule 3: Be Transparent
规则 3：让工作透明
Transparency can be difficult to achieve (depending on your work environment), but can be greatly beneficial.
透明这一点可能难以做到（依赖于你的工作环境），但会有很大的助益。
In order to be transparent, you need to make sure that you have a clear line of communication with the clients receiving your code. You need to keep them updated reguarly as to what is being worked on, and how far along progress is. Bonus points if you can continuously deploy your code to a staging system where clients can view the unfinished project and see how it is changing day after day.
为了让工作透明，你需要确保你和接受你代码的客户之间有一条清晰的沟通渠道。你需要定期地告知他们你最近的工作情况，以及在整个工作项目中大致已完成了多少比例。能给你额外加分的一个做法是，你能够持续地发布你的代码到一个阶段性发布系统，而这个系统能被你的客户用来查看未完成的项目，以及查看这项目是如何一天天地改变的。
If you're able to maintain transparency with your boss(es), they're much more likely to be understanding if deadlines need to be pushed back. Non-engineers often don't understand software development, and view it as a black-box art. By maintaing clear communication and transparency with your clients, and getting them involved in the process, they'll be more understanding of your work, and they'll feel happier about the product they're getting developed.
如果你能够维护你和你领导之间的透明度，他们将会更容易理解为什么有时候截止期限必须被延后。非工程师往往不理解软件开发的过程，并且把它视为一个暗箱操作的艺术。通过维护你和你客户之间的透明沟通，并让他们参与到整个过程中来，他们将更好地理解你的工作，并且他们会对他们将接受的这个产品更感到高兴。
Rule 4: Maintain Daily TODO Lists
规则 4：维护每天待完成工作的列表
Time management is definitely out of the scope of this article, but I will mention that maintaining a daily TODO list is one of the best things you can do as a programmer to ensure things are progressing forward at all times.
时间管理肯定不能被这篇文章所涵盖，但是我要说，维护每天待完成工作的列表（TODO List）是你作为一个程序员为了确保工作随时都在继续进行而做的最好的一件事。
Software development is an immensely complex task. It requires years of practice, patience, and discipline to become a good programmer, and you are never finished learning. When writing software on a deadline, more often than not, you're writing a complex system. In order to keep your head clear, and allow you the maximum amount of programming power, you should maintain a daily TODO list consisting of each individual task that needs to be accomplished (code-wise) in the day.
软件开发是极为复杂的任务。你需要数年的实践，耐心和原则性才能成为一名好的程序员，而且你将总是要学习新的东西。在有截止期限的情况下写软件时，大部分情况下你是在做一个复杂的系统。为了让你的头脑清晰，并且让你有最大的编程能量，你应该维护一个每天的待完成工作列表，它包含一天中每一个需要单独完成的任务。
Don't make overly vague TODO items such as "debug sound problem", really think it through, and write out the full task in numerous steps. For example:
不要写下过于笼统的待完成项，如“调试声音问题”；把它想清楚，并写下完整的步骤，比如：
* Write a unit test for the load_soundfile function that checks to see if mp3s are playable.
* Write a unit test for the load_soundfile function that checks to see if wav files crash when loading.
* Create new feature branch, design_update, to hold the new web design templates.
* Update style.css using the new web design templates.
* 写一个 load_soundfile 函数的单元测试，它检查 mp3 文件是不是可以播放。
* 写一个 load_soundfile 函数的单元测试，它检查 wav 文件在被加载时是否会崩溃。
* 创建新的功能分支，design_update，以支持新的网页设计模板。
* 用新的设计模板来更新 style.css 文件。
Having a clear list of actionable items gives you the power to focus on a single task at a time, without having to balance 100 or so next-steps in your head. Writing software is complex enough already, don't make your life more difficult!
拥有一个清晰、可完成的项目列表让你有能力在每一时刻集中注意力于单个任务，不需要在脑子里权衡下一步到底做哪个将要做的 100 个左右的步骤。写软件已经够复杂了，不要把你的生活弄得更困难！
Rule 5: Do the Right Thing
规则 5：做正确的事情
There will undoubtedly be circumstances that arise which make you nervous and uncomfortable. Did you procrastinate yesterday and skip writing the unit tests for your new features? When these situations arise, don't go with your instinct. Instead--do the right thing.
在你的工作中早晚有一天会有一些情况让你感到紧张和不适。你是否在昨天耽搁了，而没有为你的新功能写单元测试？当这些情形发生时，不要跟着感觉走。而是——做正确的事。
Whether you need to double back and revisit some old code, write some more test cases, or even delay a deadline--do it. As a professional engineer, it's your job to deliver working code consistently, even if that means you've got to make tough choices.
无论你是否需要后退两步复查一些老代码，写更多的测试用例，或者甚至是推迟一个截止期限——做下去。作为一个专业的工程师，稳定地交付能正确工作的代码是你的职责，就算这意味着让你作艰难的选择。
（译者注：还有一些本人遇到过的特殊情况，现举例如下：
一、遇到进展非常缓慢的情况，原因是自己缺乏某方面的技能或知识。解决方案：一旦发现这种情况，与你的直接领导讨论解决方案。这种情况不是因为个人能力的问题，而是因为知识不够的缘故，让你的领导安排给你相关的培训，或者让别的有此知识的人来帮助你。
二、由于工作性质的关系，如做软件维护，需要维护极大量的代码，比如百万行甚至更多的代码，从而在解决大多数问题的时候需要功能开发人员的帮助，但相关人等却很少提供足够的帮助。解决方案：与你的直接领导讨论，是否能让他帮助你与他人交流，或者让他提供一些交流的技巧。再有就是将维护工作分块交给更多的人做，让每个人主要维护某一块以提高效率，并彼此之间保持紧密的合作。
三、与他人有交流，但是交流效率由于技术手段限制而有点低。解决方法：使用更快速的交流手段，但是也要避免突然打断他人的工作。比如，如果坐在同一个办公室，可以口头交流而不必打电话或发电邮。如果坐在不同的办公室，优先考虑打电话，除非交流一些不紧急的信息。但是，在即时交流的开头，要问一下对方是否忙碌，不要贸然打断他人。一次交流尽可能问多个问题，以提高效率，而不是频繁地打断他人；先准备好要问的问题，而不要拖着别人来看自己的与问题无关的操作过程。
四、领导给出不合理的指示。此时应跟领导讲道理。如果是好的领导，一定会试图理解并改进其指示内容。如果是不好的领导嘛……看着办吧，反正做坏掉也是他的责任，虽然吃亏的很可能是你，乃至被炒鱿鱼，但是从 Karma 的角度说嘛，吃一亏也是消一障，而且吃一堑还长一智呢，又增加一个人生的阅历。同时也提醒一下，从 Karma 的角度说，防人之心不可无，害人之心也不可有。面对他人的辱骂，菩萨会欣然接受——因为他人的辱骂并非会伤自己一根毫毛，而且就算愤恨也只是伤自己的心，不如欣然接受；如此做还会积累功德，因为众生乃是佛陀最爱护的，让他们快乐是有功德的。如果辱骂的内容有理则改自己的过失。如果辱骂的内容非理，则忘掉便是。不要试图去改变他人；他人只能被感化。）
Conclusion
结论
Being a software developer is no easy task. Our world is filled with constant challenge and hardship, and only our discipline and preparedness can help us push through the hard times, and prosper in the good times. Always use your best judgement, and beat the deadlines by using steadfast engineering practices, and never giving in to anything less.
做一个软件开发人员不是一件容易的事。我们的世界一直有着挑战和困难，而只有用我们的原则性和为之而作的准备才能帮助我们渡过困难，并在将来繁荣昌盛。总是用你最好的判断力，并用坚定的工程实践来克服截止期限的问题，从不投降。
You can do it.
你一定能做到。
翻译：Robbie Fan
Year 2011
http://rdegges.com/on-programming-deadlines
Random thoughts of a happy programmer.
某个乐呵呵的程序员之随想。
On Programming Deadlines
有关编程的截止期限
There are a lot of differences between programming, and programming professionally. The most notorious of which, is deadlines.
在“编程”与“职业的编程工作”之间有着很多的区别。其中最明显的一点，就是截止期限。
Deadlines
截止期限
When you're writing code for yourself, you can spend as much (or as little time) on it as you please--but when you're writing code for other people, you've got only a limited amount of time and resources to get the job done. In my experience, this typically leads to one of two situations:
当你为自己写代码的时候，你可以想搞多久就搞多久，或者想马马虎虎能用就草草了事也可以。但是当你在为他人写代码时，你只有有限的时间和资源来完成任务。在我的经验里，这通常导致两种情形：
* You've got to extend the deadline to finish the job properly.
* You've got to write some dirty hacks to finish the job.
* 你必须延后截止期限才能将工作做得妥善
* 你必须用一些难看的、有不良副作用的代码来快速完成工作
If you've ever done professional programming, you know what I mean. Very few projects are agile enough to allow for both sufficient time and resources to get the job done. This leads to tough decisions for programmers.
如果你做过职业的编程工作，你就知道我说的是什么。很少有项目是灵活到允许有足够的时间和资源来完成的。这样，程序员就必须面对艰难的选择。
No self-respecting programmer wants to deliver sub-par code; but it's difficult to consistently deliver high-quality code when dealing with time obligations, especially in professional environments where you're dealing with non-engineers who don't necessarily understand the concept of technical debt.
没有一个有自尊的程序员愿意交付质量比标准要求还低的代码；但是要持续不断地交付高品质的代码，同时又要应对时间上的要求时是很难做好的，特别是在专职工作中应对那些并不懂得什么叫“技术负债”的非专业人员的时候就更困难了。
Luckily, there are some guidelines you can follow to help minimize the amount of hackery you have to do when writing code on a deadline. They aren't necessarily quick-fixes, but can certainly be helpful to anyone who needs to consistently push out top-notch code, day after day.
幸运的是，有一些准则你可以遵循，以期尽可能地避免在有截止期限的编程过程中不得不做的“不良代码”。它们并不都是立竿见影的，但一定能对需要稳定地按时交付高质量代码的人有所帮助。
Rule 1: Setup Continuous Deployment Before Writing ANY Code
规则一：在写任何代码之前，建立持续部署的环境
This is a tip I picked up from The Pragmatic Programmer book (definitely required reading for any programmer). Always, and I mean always, setup your continuous deployment system before writing code.
这个是我从《The Pragmatic Programmer》（中文名《程序员修炼之道》——译者注）一书中学到的技巧（毫无疑问这是一本每一个程序员的必读的书）。总是，我说总是，在你开始写代码之前建立持续部署的环境。
What do I mean by continuous deployment? Well, before you start coding your project, you should have a system set up that lets you deploy your project code into production (and preferably staging and development environments as well). This way, as you write your code, you'll have the peace of mind that comes with knowing your project can be deployed at any moment.
我所说的持续部署是什么意思呢？唔，在你开始为你的项目写代码之前，你应该有一个系统，在这个系统里可以把你的代码变成最终的成品（如同用户见到的，可运行的形式——译者注）（而且最好同时是一个阶段性发布以及开发也都在上面进行的平台）。这样一来，当你写你的代码的时候，你就会有一份平和的心情，因为你知道你的项目可以随时被部署。
In a lot of programming workflows, this can save tons of development time. Instead of scp'ing your project to some testing environment (or worse, coding directly on a live server), you can just push your code to your preferred source control system, and let your continuous deployment system take care of the rest. It may not seem like much of a time saver--but if you consider the amount of time it takes, day after day, to copy your code over and do testing manually, it can quickly add up and save hours of time each month.
在很多的程序开发工作流程中，这会节约数以吨计的开发时间。不要说手工地用 scp 命令（一个 Unix 下的支持加密传输的拷贝命令——译者注）把你的项目拷贝到一些测试环境中（或者更坏，在一个远端服务器上直接编程），你可以只需要把你的代码更新到你喜好的源代码管理系统中，然后让你的持续部署系统自动地处理其余的事情。这可能看上去并没节省多少时间——但是你考虑一下，每次都手动拷贝代码并手动测试，一天天累积下来算的话，它能在一个月内节省几个小时的时间。
Rule 2: Write Tests First
规则 2：先写测试
If you've never heard of test-driven development (TDD), please read the wikipedia article on it immediately. If someone is paying you to write software, and you've got a deadline, then you need to be practicing TDD at all times.
如果你从未听说过测试驱动开发（TDD）的话，请马上阅读有关它的 wikipedia 文章。如果某人付钱请你写软件，并且给你一个截止期限，那你应该不停地采用 TDD。
The basic concept of test-driven development is that before writing project code, you write a simple piece of code that tests your hypothetical project code for desired behavior. For example, let's say your project requires you to write a function that adds two numbers, and returns the sum of these numbers. Before writing that piece of code, you should write a test function, test_add_two_numbers, that calls your add_two_numbers function with various inputs, and verifies through assertions that the results you get back are proper.
测试驱动开发的基本概念是你在写代码之前，你先写一小块代码，用于测试你假想的项目代码是否实现了预期的行为。比如说，假设你的项目要求你写一个函数把两个数字相加，并返回两个数字的和。在写这段代码之前，你应该先写一个测试函数，test_add_two_numbers，它用多种不同的参数调用你的 add_two_numbers 函数，并通过断言（assertions）来验证你得到的结果是正确的。
This may seem like a bit of a hassle, but it has numerous benefits:
这看起来有一些麻烦，但是它有几点好处：
* Writing tests first help you clarify your application architecture.
* You have the peace of mind that comes with knowing your code is operational.
* You're able to easily refactor parts of your project without worrying about breaking code.
* You can avoid releasing low-quality code, and tarnishing your reputation.
* 写测试能帮助你明了你的应用程序架构
* 你将会有一份平和的心境，因为知道了你的代码能工作
* 你能轻易地重构你项目中的部分代码，而不必担心不小心把它搞坏
* 你可以避免发布低质量的代码，从而维护你的名誉
Writing tests certainly takes time and effort, but can save time in the long run by avoiding emergency bug-fixes, system crashes, etc. Especially when you're on tight deadlines, you don't want the added stress and worry of buggy code.
写测试自然会占用时间和精力，但是能在长期来看能节省时间，比如能避免紧急补丁的必要、避免系统崩溃等等。特别当你在紧迫的截止期限下，你不想再为有缺陷的代码而紧张费神。
（不过，在使用 TDD 之前，请确认领导层的支持；否则，领导层会认为编写测试代码的时间是浪费掉的。此外，使用了 TDD 之后，不要忘记人工的测试，特别是 ad hoc 测试（随机、自由的测试）的重要性。另外，测试本身也将成为项目维护的一部分，会增加维护成本。参见 http://en.wikipedia.org/wiki/Test-driven_development。——译者注）
Rule 3: Be Transparent
规则 3：让工作透明
Transparency can be difficult to achieve (depending on your work environment), but can be greatly beneficial.
透明这一点可能难以做到（依赖于你的工作环境），但会有很大的助益。
In order to be transparent, you need to make sure that you have a clear line of communication with the clients receiving your code. You need to keep them updated reguarly as to what is being worked on, and how far along progress is. Bonus points if you can continuously deploy your code to a staging system where clients can view the unfinished project and see how it is changing day after day.
为了让工作透明，你需要确保你和接受你代码的客户之间有一条清晰的沟通渠道。你需要定期地告知他们你最近的工作情况，以及在整个工作项目中大致已完成了多少比例。能给你额外加分的一个做法是，你能够持续地发布你的代码到一个阶段性发布系统，而这个系统能被你的客户用来查看未完成的项目，以及查看这项目是如何一天天地改变的。
If you're able to maintain transparency with your boss(es), they're much more likely to be understanding if deadlines need to be pushed back. Non-engineers often don't understand software development, and view it as a black-box art. By maintaing clear communication and transparency with your clients, and getting them involved in the process, they'll be more understanding of your work, and they'll feel happier about the product they're getting developed.
如果你能够维护你和你领导之间的透明度，他们将会更容易理解为什么有时候截止期限必须被延后。非工程师往往不理解软件开发的过程，并且把它视为一个暗箱操作的艺术。通过维护你和你客户之间的透明沟通，并让他们参与到整个过程中来，他们将更好地理解你的工作，并且他们会对他们将接受的这个产品更感到高兴。
Rule 4: Maintain Daily TODO Lists
规则 4：维护每天待完成工作的列表
Time management is definitely out of the scope of this article, but I will mention that maintaining a daily TODO list is one of the best things you can do as a programmer to ensure things are progressing forward at all times.
时间管理肯定不能被这篇文章所涵盖，但是我要说，维护每天待完成工作的列表（TODO List）是你作为一个程序员为了确保工作随时都在继续进行而做的最好的一件事。
Software development is an immensely complex task. It requires years of practice, patience, and discipline to become a good programmer, and you are never finished learning. When writing software on a deadline, more often than not, you're writing a complex system. In order to keep your head clear, and allow you the maximum amount of programming power, you should maintain a daily TODO list consisting of each individual task that needs to be accomplished (code-wise) in the day.
软件开发是极为复杂的任务。你需要数年的实践，耐心和原则性才能成为一名好的程序员，而且你将总是要学习新的东西。在有截止期限的情况下写软件时，大部分情况下你是在做一个复杂的系统。为了让你的头脑清晰，并且让你有最大的编程能量，你应该维护一个每天的待完成工作列表，它包含一天中每一个需要单独完成的任务。
Don't make overly vague TODO items such as "debug sound problem", really think it through, and write out the full task in numerous steps. For example:
不要写下过于笼统的待完成项，如“调试声音问题”；把它想清楚，并写下完整的步骤，比如：
* Write a unit test for the load_soundfile function that checks to see if mp3s are playable.
* Write a unit test for the load_soundfile function that checks to see if wav files crash when loading.
* Create new feature branch, design_update, to hold the new web design templates.
* Update style.css using the new web design templates.
* 写一个 load_soundfile 函数的单元测试，它检查 mp3 文件是不是可以播放。
* 写一个 load_soundfile 函数的单元测试，它检查 wav 文件在被加载时是否会崩溃。
* 创建新的功能分支，design_update，以支持新的网页设计模板。
* 用新的设计模板来更新 style.css 文件。
Having a clear list of actionable items gives you the power to focus on a single task at a time, without having to balance 100 or so next-steps in your head. Writing software is complex enough already, don't make your life more difficult!
拥有一个清晰、可完成的项目列表让你有能力在每一时刻集中注意力于单个任务，不需要在脑子里权衡下一步到底做哪个将要做的 100 个左右的步骤。写软件已经够复杂了，不要把你的生活弄得更困难！
Rule 5: Do the Right Thing
规则 5：做正确的事情
There will undoubtedly be circumstances that arise which make you nervous and uncomfortable. Did you procrastinate yesterday and skip writing the unit tests for your new features? When these situations arise, don't go with your instinct. Instead--do the right thing.
在你的工作中早晚有一天会有一些情况让你感到紧张和不适。你是否在昨天耽搁了，而没有为你的新功能写单元测试？当这些情形发生时，不要跟着感觉走。而是——做正确的事。
Whether you need to double back and revisit some old code, write some more test cases, or even delay a deadline--do it. As a professional engineer, it's your job to deliver working code consistently, even if that means you've got to make tough choices.
无论你是否需要后退两步复查一些老代码，写更多的测试用例，或者甚至是推迟一个截止期限——做下去。作为一个专业的工程师，稳定地交付能正确工作的代码是你的职责，就算这意味着让你作艰难的选择。
（译者注：还有一些本人遇到过的特殊情况，现举例如下：
一、遇到进展非常缓慢的情况，原因是自己缺乏某方面的技能或知识。解决方案：一旦发现这种情况，与你的直接领导讨论解决方案。这种情况不是因为个人能力的问题，而是因为知识不够的缘故，让你的领导安排给你相关的培训，或者让别的有此知识的人来帮助你。
二、由于工作性质的关系，如做软件维护，需要维护极大量的代码，比如百万行甚至更多的代码，从而在解决大多数问题的时候需要功能开发人员的帮助，但相关人等却很少提供足够的帮助。解决方案：与你的直接领导讨论，是否能让他帮助你与他人交流，或者让他提供一些交流的技巧。再有就是将维护工作分块交给更多的人做，让每个人主要维护某一块以提高效率，并彼此之间保持紧密的合作。
三、与他人有交流，但是交流效率由于技术手段限制而有点低。解决方法：使用更快速的交流手段，但是也要避免突然打断他人的工作。比如，如果坐在同一个办公室，可以口头交流而不必打电话或发电邮。如果坐在不同的办公室，优先考虑打电话，除非交流一些不紧急的信息。但是，在即时交流的开头，要问一下对方是否忙碌，不要贸然打断他人。一次交流尽可能问多个问题，以提高效率，而不是频繁地打断他人；先准备好要问的问题，而不要拖着别人来看自己的与问题无关的操作过程。
四、领导给出不合理的指示。此时应跟领导讲道理。如果是好的领导，一定会试图理解并改进其指示内容。如果是不好的领导嘛……看着办吧，反正做坏掉也是他的责任，虽然吃亏的很可能是你，乃至被炒鱿鱼，但是从 Karma 的角度说嘛，吃一亏也是消一障，而且吃一堑还长一智呢，又增加一个人生的阅历。同时也提醒一下，从 Karma 的角度说，防人之心不可无，害人之心也不可有。面对他人的辱骂，菩萨会欣然接受——因为他人的辱骂并非会伤自己一根毫毛，而且就算愤恨也只是伤自己的心，不如欣然接受；如此做还会积累功德，因为众生乃是佛陀最爱护的，让他们快乐是有功德的。如果辱骂的内容有理则改自己的过失。如果辱骂的内容非理，则忘掉便是。不要试图去改变他人；他人只能被感化。）
Conclusion
结论
Being a software developer is no easy task. Our world is filled with constant challenge and hardship, and only our discipline and preparedness can help us push through the hard times, and prosper in the good times. Always use your best judgement, and beat the deadlines by using steadfast engineering practices, and never giving in to anything less.
做一个软件开发人员不是一件容易的事。我们的世界一直有着挑战和困难，而只有用我们的原则性和为之而作的准备才能帮助我们渡过困难，并在将来繁荣昌盛。总是用你最好的判断力，并用坚定的工程实践来克服截止期限的问题，从不投降。
You can do it.
你一定能做到。
514
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
