读《程序员修炼之道——从小工到专家》

　　注重实效的程序员，能够越出直接的问题去思考，总是设法把问题放在更大的语境中，总是设法注意更大的场景。注重实效的程序员不满足于只解决客户的问题，而且更关注如何为客户带来价值。注重实效的程序员，倾向于把需求搜集、设计、以及实现视为同一个过程——交付高质量的系统——的不同方面。

 

　　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...