高效程序员的45个习惯：敏捷开发修炼之道之主题建议翻译1-10

高效程序员的45个习惯：敏捷开发修炼之道1-10

 

   阅读本书时，总共有45个建议，每个建议有一个主题，并且每个建议有2段话，第一段话是一般人的思维，之后作者对这种思维现象进行剖析，最后得出作者自己的结论，第二段话就是作者的观点。

本次翻译，主要分为5篇来完成，前四篇每篇为10个建议，最后一个为5个建议。每次翻译的中文在上面，原版英文在最下面展示，已方便大家的对照学习。

由于个人能力有限，如有翻译不恰当之处，还请大家多多指教，给我留言，给出建议，我会更新文章，让看到文章的人员有所裨益。

后续的剩余翻译，正在进行中------

意见征询：恳请看本章的人员，能给出建议，我接下来的翻译方式，是采用本文的方式好呢？还是让每个建议的中英文放在一起好呢，放在一起的好处，可以方便大家对照着看，请大家在评论中，给出建议，不胜感激！谢谢！

1. 做事

在解决一个问题时，最重要的是确定引起问题的根源。找出那个傻瓜，一旦你确定了是它的错误，那么你就可以保证不在发生同样的错误。

责备不能够修复bug。我们应该针对解决问题的办法，而不是人。这样的结果才是积极、重要的。

2. 欲速则不达

你不需要读懂每一段代码。它只要能够正常运行就行了。哦，如果仅仅是需要一些小的改动，那就再添加上几行代码，就可以了。就这样做，它将会很好的运行。

不要陷入这种简单的修修补补。要在代码的整洁和可扩展性上多下工夫。

3. 对事不对人

你应该在你的设计上多下点工夫。当你花费了很多工夫之后，你坚信你比其他人设计的都要好。不要对他们的想法感兴趣，那样只会给你带来困惑。

对事不对人，我们应该以找到好的解决方案而自豪，而不是比较谁的方案好。

4. 做正确的事情

当你在其他人的代码中发现了错误，请保持沉默。毕竟，你不想伤害他们，或者引起麻烦。如果不凑巧发生在你老板身上，你要格外的谨慎，只要按照他的命令执行就行了。

做正确的事情。诚实，要有勇气说出实情。这样做有时候很困难，那就是为什么我们需要更多的勇气。

5.  跟上科技的步伐

科技发展的如此之快，势不可挡。这是它的本性。用你熟悉的语音，继续做你现在的工作吧。你不可能跟上科技发展的脚步。

跟上新技术的变化。你不需要成为一个样样精通的专家，但是你要知道行业的前沿动态，你就可以更好地规划你的项目和职业生涯。

6. 懂得分享

不要和别人分享你的知识--自己留着。这是你在团队中的核心竞争力。只要你自己厉害就行了，可以不去管其他的菜鸟。

给你以及你的团队提供一个好的平台。通过饭桌交流，来增加每个人的知识和技能，并帮助大家共同进步。激发团队对知识和技能的激情，将会对项目大有裨益。

7. 保持进步

这是你长期积累一贯的做法。这种方式往往对你有很大的作用。你一开始就学会了这种方式，并且它确实很不错。真的，到目前为止，你都没有做过改变。

学习新的东西，丢弃旧的。当你学习一种新的知识时，你将要丢弃一切阻拦你进步的坏习惯。毕竟，新式汽车要比老式汽车包含更多的东西。

8. 追根究底

接受别人给你的建议。如果别人给出了你所找问题的根源，就不需要浪费时间去追根究底了。

凡事问个为什么。不要满足于别人告诉你的表面现象，要不停地提问，直到你弄清楚了事情的本质。

9. 定期清查代码

我们很久都没有进行过代码审查了，所以，本周我们将审查所有的代码。此外，我们需要做一个发布版本计划，所以从星期二开始，用3周的时间来发布这个版本。

在事情变成一团糟之前，我们要好好的处理一下。经常并且稳定的去做处理，将会更好的解决一些公共的问题。

10．客户做出决定

开发者富有创造力和智慧，并且最了解应用。因此，关键的决定应该由开发者来定夺。只要业务人员一介入，就会搞的一团糟，他们不懂得我们做事的逻辑。

让你们的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用一种业务人员能够理解的语音，告诉他们详细的问题，并让他们自己做出决定。

 

1. “The first and most important step in addressing a problem is to determine who caused it. Find that moron! Once you’ve established fault, then you can make sure the problem doesn’t happen again. Ever.” 
Blame doesn’t fix bugs. Instead of pointing fingers, point to possible solutions. It’s the positive outcome that counts. 
 
2. “You don’t need to really understand that piece of code; it seems to work OK as is. Oh, but it just needs one small tweak. Just add one to the result, and it works. Go ahead and put that in; it’s probably fine.” 
Don’t fall for the quick hack. Invest the energy to keep code clean and out in the open.

3. “You have a lot invested in your design. You’ve put your heart and soul into it. You know it’s better than anyone else’s. Don’t even bother listening to their ideas; they’ll just confuse the issue.” 
Criticize ideas, not people. Take pride in arriving at a solution rather than proving whose idea is better. 
 
4. “When you discover a problem in someone else’s code, just keep it to yourself. After all, you wouldn’t want to hurt their feelings or cause trouble. And if that someone else happens to be your boss, be extra careful, and just follow orders.” 
Do what’s right. Be honest, and have the courage to communicate the truth. It may be difficult at times; that’s why it takes courage. 
 
5. “Technology changes so fast it’s overwhelming. That’s just the nature of it. Stick to your old job with the language you know; you can’t possibly keep up.” 
Keep up with changing technology. You don’t have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects Accordingly. 
 
6. “Don’t share what you know—keep it to yourself. It’s to your advantage to be the Smart One on the team. As long as you’re smart, you can forget about those other losers.” 
Raise the bar for you and your team. Use brown-bag sessions to increase everyone’s knowledge and skills and help bring people together. Get the team excited about technologies or techniques that will benefit your project. 

7.“That’s the way you’ve always done it, and with good reason. It usually works for you just fine. The ways you learned when you first started are clearly the best ways. Not much has changedsince then, really.” 
Learn the new; unlearn the old. When learning a new technology, unlearn any old habits that might hold you back. After all, there’s much more to a car than just a horseless carriage. 
 
8. “Accept the explanation you’ve been given. If you’re told where the problem lies, that’s where you look. Don’t waste your time chasing ghosts.” 
Keep asking Why. Don’t just accept what you’re told at face value. Keep questioning until you understand the root of the issue. 
 
9. “We haven’t had a code review in a long time, so we’re going to review everything all this week. Also, it’s probably about time we made a release as well, so we picked three weeks from Tuesday for a next release.” 
Tackle tasks before they bunch up. It’s easier to tackle common recurring tasks when you maintain steady, repeatable intervals between events. 
 
10. “Developers are creative and intelligent and know the most about the application. Therefore, developers should be making all the critical decisions. Anytime the business people butt in, they just make a mess of things; they don’t understand logic the way we do.” 
Let your customers decide. Developers, managers, or business analysts shouldn’t make business-critical decisions. Present details to business owners in a language they can understand, and let them make the decision.