高效程序猿的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.