注重实效的程序员，能够越出直接的问题去思考，总是设法把问题放在更大的语境中，总是设法注意更大的场景。注重实效的程序员不满足于只解决客户的问题，而且更关注如何为客户带来价值。注重实效的程序员，倾向于把需求搜集、设计、以及实现视为同一个过程——交付高质量的系统——的不同方面。
0.注重实效的途径
注重实效的程序员，从培养良好的习惯开始，因为坏习惯是能够传染的。
->DRY-Don't Repeat Yourself
人是有惰性的，程序员亦然。要避免重复，首先要有避免重复的意识，理解重复的危害。
没有意识到自己在重复coding是比较少的，至少你知道自己copy&paste了，你在无耐的重复。因为那样的工作更容易，copy&paste就可以开始l回家玩游戏或者带孩子了。程序员的懒惰，让copy&paste的危害留给下一个软件的开发者。
开发者间重复是比较常见的。你没能很好了解Team中代码资产，就开始心安理得的创造“轮子”了。为了避免开发者间的重复，Team间的交流是很重要的。
->正交性——解耦、松耦合、内聚的模块
我们都想拿到一个易于测试、扩展、维护的模块。所以我们自己得鞭策自己，写一个足够“正交”的模块。
所谓正交，即两个或者多个模块中的一个变化，不会影响其他模块。不正交的模块是不可测的模块。
职责单一，隔离变化，不要让你的模块处于“软件熵”的混乱中迭代。
->曳光弹
不要想着一蹴而就。敏捷开发告诉我们，我们不可能一次掌握所有需求，我们不可能开发足够完美的软件。
所以，及早开始编码。在流程迭代中前进。
->估算
借鉴他人的经验；建立对问题的理解。解决问题不是急切的寻找答案。深入理解问题本身，比答案更重要。
良好的估算，从来不是拍脑袋拍出来，需要经验积累，需要Team级别估算数据，需要个人估算数据。积累估算数据，让估算可控。
->知识资产
掌握了若干门语言，熟悉了“设计模式”，了解敏捷开发，就能安枕无忧了吗？
须知，程序员的知识是有时效性的资产。没有工程实践的架构，是空中楼阁。
1.项目开始之前
敏捷项目开始之前，需要搭建源代码版本控制系统，如svn、TFS、git；需要搭建持续集成环境；需要...收集需求。
->挖掘需求
亨利·福特一句被引用无数次的名言——“如果我问顾客想要什么，他们可能会说自己想要一匹快马。"
“不要搜集需求——挖掘它们。”
找出用户为何要做特定事情的原因，而不只是他们目前做这件事情的方式。
开发需要解决顾客的商业问题，而不只是满足用户陈述的需求。
深入了解用户需求的有效手段是——成为用户。与用户一同工作，像用户一样的思考。
->收集需求的方式
敏捷开发说：客户的合作胜过合同和谈判。“胜过”，不是“略过”。
跟客户坐下来，从他们那里探问真实的需求。不会要在客户面前挥洒UML图吧？冗长的文档呢？程序员讨厌文档！
新的知识、新的环境往往让人紧张，所以采用计算机工具，不如采用User Story卡。
->控制需求
在有限的时间内，所能deliver的东西是有限的。敏捷的“拥抱变化”，不是让需求盲目的篡改和增长。
有个段子：有人问Team采用敏捷开发后，有什么变化？答曰：加班明显增多了！
->记录需求的方式
Word、Excel是常用的记录方式，而文档经常是有滞后性的，及时更新和版本控制很重要(SharePoint站点挺好的)。
把需求文档发布成超文本文档或者发布到内部网上，以方便所有参与者访问。
2.编码进行时
甩开膀子，开始编代码吧。
从一开始编码，就让代码可测。不一定需要TDD，但是如果你写的代码要设计Test Case，无法入手，那这段代码该是多么的糟糕？
->按合约设计
通过合约进行设计。
设计时，简单地列举输入域的范围是什么、边界条件是什么、方法(函数)允许交付什么。
->用好异常
大多数高级语言都有异常机制——try..catch
异常处理中不应该包含代码逻辑。如果移走异常处理，代码不能执行，那么这段异常的设计是有问题的。
当你的代码发现，某件被认为不可能发生的事情发生，你的程序就不再有存活的能力，程序该崩溃或者重启。
->Code Review
每个check in都有人来review吗？
关键代码能够有人review已经不错了。开一个review会议也不错，可以统一一下Team间的编程风格。
->该重构就重构
Smell code smell.
重构发生在开发后期，或者在接手原有的代码的时候。当你发现你的改动已经变得困难，果断重构。
但是重构表面上不会带来商业价值，或许你得跟老板进行重构谈判。
3.编码之外(题外话)
->敏捷开发流程
Product Plan、Story Time、Sprint Plan、Sprint Review、Sprint Retrospective、Release Plan
作为一个敏捷的Team成员，应该明白Team的目标。
Team成员为了共同的目标而奋斗，而不只是为了完成自己手头的task。
->关键实践
Code Review、结对编程、测试驱动开发
结对编程需要一个人力资源，比较浪费，大概在老人带新人的时候比较有用。
->无处不在的自动化
自动化构建、自动化测试、自动化部署。
一个良好的持续集成环境里面，应该是可以包括上面三个方面的。
4.丰富工具箱
Windows开发人员拥有丰富的IDE，总被Linux开发人员耻笑。
注重实效的程序员，需要脱离IDE的束缚，丰富自己的工具箱。
Linux：vim、vim、vim... bash shell、Source Insight(Windows)、SecureCRT/Putty(Windows)、gcc/g++、make、sed/grep/awk等等小工具
Windows：Visual Studio、Visual Studio、Visual Studio...PowerShell、notepad++、UE、WinMerge(diff)、Eclipse(optional)...
源代码管理：cvs/svn/TeamFoundationServer/GIT...
转载于:https://www.cnblogs.com/ahomer/archive/2012/03/20/2409022.html