每天写出好代码的5个建议
2011-06-28 22:03:00| 分类： program | 标签： |字号大中小 订阅
http://www.makinggoodsoftware.com/；
A blog by Alberto G (Alberto Gutierrez)
每天写出好代码的5个建议
5 Tips for creating good code every day; or how to become a good software developer
成为一个优秀的程序员和成为其他优秀的专业人员一样，需要尽可能多的做一些有质量的工作。有句很流行的话可以总结：做，正确做事，立马就做。（Do it. Do it right. Do it right now）
0. 将一天要做的事情列成清单
完成复杂活动（activity）的最好方法是将其拆分成简单的各项活动。每天早上，将你一天要完成的活动进行拆分，然后制定一个相应的日程安排表，这样能够帮助你：
更好的理解这个活动。
每天都有一个集中的目标。
提高你的估计能力，几天之后，你会发现你能预测一天的工作量。
1. 一次只做一件事
集中于一项任务比同时做多项任务更多产，不同的研究已经证明这个观点，并且发布在不同的媒体上（例如CNN）。
集中精力工作25分钟，休息5到10分钟。你可以用诸如“番茄工作法”这种流行的技术来帮助你管理时间。还有工具能帮助你测量你花在各项不同任务上的时间，我最喜欢的是CoolTimer，这里也有10个不错的时间追踪应用程序。
2. 正确做事
以下两个是考察事情是否正确完成的关键：
要为解决方法感到到自豪，因为这不仅仅只是个普通的解决方法，这是个好的方法。遵循“软件质量金字塔”的原则
解决方法至少要经过一次检查。在你的同事中，请一位你尊敬的优秀开发人员检查你的方法，并接受他的真诚建议。
3. 不要半途而废
众所周知，若仍有一个玻璃杯需要清洗，则不能说已经洗完了。粉刷墙壁或驱车前往某处这些事情上我们也认可同样的道理，但在软件开发上我们却不这么认为 了。即便我们没有完成所有的单元测试，或者我们没有核实实现方式是否符合用户的需要，我们也说完成了任务。这是典型来自Hope Driven Development的行为，是非常有害的。
需求没有更改时，只有当你百分之百确认再也没有必要改善那个解决方法时，才能算完成任务。
4. 与其道歉，不如补救，而放弃最不可取。
如果你要花额外的时间来完成一些代码的测试，或者重构不可读的类，那么就去做，因为这是为将来投资时间。但是如果你在某件事上面卡住了或者将项目拖延 的太久，那么寻找一个更容易的方案。它可能不如你目前正在实现的方案优雅，但至少你有方案。确保记录下来以应对这个项目将来的风险，并且有些东西需要重新 审查。
译文出处：伯乐在线 - 职场博客 - 程序员
译文链接：http://www.jobbole.com/entry.php/971
翻译：敏捷翻译 - 唐瑭
原文：Alberto Gutierrez 5 tips for creating good code every day
5 Tips for creating good code every day; or how to become a good software developer
Written by Alberto G
May 15th, 2009 at 10:36 am
Being a good developer is like being any other good professional, it’s all it’s about doing as much quality work as
possible. There is a popular sentence that summarises it: “Do it. Do it right. Do it right now”.
1.- Have your own to do list for the day.
The best approach to complete complex activities is to break them down into simple activities. Do this every morning by
breaking down the different activities you would like to complete for the day and assign them a schedule. This will help you
to:
Have a better understanding of the activity.
Have a focused goal for the day
Improve your estimating skills. After a few days you will find that you can predict how much work you can do in a day.
2.- Do one thing at a time.
It’s been proven by different studies and published in different media (ie CNN) that it is more productive to be focus only
on one task than to do multitasking.
Work in short batches of intense work of about 25 minutes with a 5-10 minutes rest. There are popular techniques like the
pomodoro technique to help you manage the time. There are also tools to help you measure the time you spent on the different
tasks, my favorite one is CoolTimer.
3.- Do it right.
There are two keys to know if something is done right
To be proud of the solution; it is not just any solution, it is a good solution. It follows the principles of the “Pyramid
of the software quality“.
The solution passes at least one review. Ask one of your colleagues that you respect as a good developer to review your
solution and for his sincere opinion.
4.- Don’t finish something until it’s completely done.
We all know that if there’s still a glass to wash, we cannot say that we have done the dishes, the same applies for painting
a wall or driving to a destination but in software development we don’t do that, we say that we are done even when we haven’t completed all the unit tests or when we haven’t checked if the implementation is correct with the customer, that’s a
typical behavior from Hope Driven Development and that’s evil.
Something is only done when you are 100% sure that it won’t be necessary to work at all on that solution unless the
requirements change.
5.- Better late than sorry BUT better sorry than never.
If it’s going to take you an extra day to complete the testing of some code, or to refactor a class which is unreadable, do
it, that’s an investment in time for the future, but if you are stuck with something and you are delaying the project too
much, just find an easier solution. It may not be as elegant as the one you are implementing, but at least you will have a
solution. Make sure to document it as future risk for the project and something that will probably need to be revisited.