【原】高效程序员的45个习惯-读书笔记

 

最近阅读了《高效程序员的45个习惯》，看完后整体的感受是：

目前很多方法我们已经在使用了，有的一些已经成为项目以及日常的流程了，非常欣慰，有一些习惯个人感觉不是很合适使用，例如结对编程，这个我感觉貌似没法付诸于实践，首先是人力的时间成本，结对来搞一个事情，沟通成本会相对大一点，另外一点是，自己写代码的时候旁边有人看着，这个我估计很多程序员都接受不了吧，会感觉很不自在的。

         其实比起敏捷来说，更加喜欢高效这两个字，一名程序员完成一项任务后，当再有相同的任务出现时，能否高效率的完成，我指的高效包括代码质量、时间成本等等方面，假如和第一次做时间相同，我觉得是失败的，长远发展下去肯定对自己不利。如此，在日常工作中寻找高效率的方法显得格外重要。

         在目前人力资源成本日渐增长的今天，提高开发测试软件的效率显得格外重要。

         （1）态度决定一切

“软件出现了问题，第一重要就是找出元凶，找到那个白痴。”这个明显是不对的，第一时间就是解决问题。

         一个重大的错误应该被当做是一次学习二不是指责他人的机会，团队成员在一起，应该是混响帮助，而不是互相指责。

指责不会修复bug，把矛头对准问题的解决办法，而不是人，这是真正有用处的正面效应。

在项目中，代码应该是很亮堂的，不应该有哦黑暗死角，也许你不知道每块代码的每个细节或者算法的每个步骤，但是你对整体的相关知识要有很好的了解。

分享并融合各种不同的想法和观点，远远胜于单个想法为项目带来的价值。

有一句话比较给力：“你不需要很出色才能起步，但是你必须起步才能变的很出色”。

如果你在压力下对代码质量作出妥协，你可以指出，作为一个开发者，你没有权利毁坏公司的资产。

         （2）学无止境

一个活力十足的敏捷开发团队需要有规律的反复做很多事情，一旦项目开始运作，你就需要把握开发节奏。

         迭代和增量的学习，每天计划用一段时间来学习新技术，不需要很长时间，但需要经常进行。

         了解最新行情，通过亲阅读最新的技术网站即可呵呵。

         参加本地的用户组活动，例如培训活动等，这个貌似淘宝比较给力，有不定期的培训。

         参加研讨会议。多多参与技术方案的评审，这个比较给力。

         如饥似渴阅读。阅读技术方案，阅读源码等。

你需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。

对团队进行投资，增加团队之间的交流活动，长远来看是很有益处的。

不停的问为什么，不能只满足于别人告诉你的表面现象，要不停的问直到你明白问题的根源。

项目开发需要有一致和稳定的节奏，编辑、运行测试，代码复审。然后发布。

         （3）交付用户想要的软件

         这个感觉是大家有点疑问的，我们做的不就是用户想要的吗，但是事实不是这样的，由于对于食事物的看法和见解不同，导致对于同一件事情的理解可能会有偏差。

这样的结果机会出现，我们程序员苦逼的写出来的程序不是用户想要的，其实是我们觉得是他们想要的。这种情况在产品是自己公司业务方用的时候问题不大，顶大大家多交流几遍，但是在

那种靠卖这个产品的公司来说，这个是致命的了，有可能用户就不给你钱了。

那既然这个问题存在，该怎么避免呢？

我的建议是：多交流，频繁的交流，在开发功能稳定后，提交测试人员进行测试之前，来一次冒烟的功能演示，喊上业务方的成员，大家就一些功能达成一致，有问题赶紧提出来，

在没有进入测试前，修改的成本还是不大的。经过这个过程的演示基本上问题就不大了呵呵。

         记录客户的决定，并注明原因，好记性不如烂笔头。

         不用低级别和没有价值的问题打扰繁忙的业务人员。

         不要随意假设低级别的问题不会影响他们的业务。

         让设计指导而不是操纵开发，这个确实是这样的，个人认为好的架构师进化出来的，而不是设计出来的。

         新技术就应该想是新的工具，可以帮助你更好的工作，它自己不应该成为你的工作。

         时刻保持你的代码可以发布，这个可以通过持续化回归测试来保证。

         提早集成，频繁的集成，这个对于大型系统多人员开发显得格外重要，我在项目中做的一个尝试是通过hudson来进行自动化部署，hudson每隔一段时间来检测代码是否又提交，如果有提交，则自动进行打包编译，出现问题，通过一些方式反馈出来。

         提早实现自动化部署和运维，这一点觉得淘宝做的还是比较不错的，基本上部署应用都可以通过页面点击来完成，比较高效，最主要的一个问题就是能够减少人员操作带来的失误呵呵，不过这个要求运维系统需要比较问题啊。

         使用演示来频繁的获取反馈，这个认为是一个很给力的环节了。

                  

         （4）反馈、编码、调试、协作

使用单元测试，如果代码没有经过测试，你会觉得不舒服，就像在高空作业没有系安全带一样呵呵。

倾听用户的声音，每一个抱怨的背后，都隐藏了了一个问题，找出并解决他。

       使代码保持可阅读，通过代码来进行沟通，添加必要的注释。

       增量式编程，进行阶段 性的测试，能够避免集中性测试导致的问题。

       对于问题进行各个击破，将问题进行隔离，特别是在大型应用中。

提供有效的错误信息，反馈出需要的异常信息，对于异常不能简单粗暴的解决，要进行合理的控制。

       代码在本地测试没有问题后再进行提交，避免自己没有测试就进行提交，这样会导致别人协作的时候还需要排查你遗留的问题。

         不定期的进行代码review，这个虽然有点耽误时间，但是确实很有必要。         

         个人综合来看，提高编码测试效率，进行持续化回归测试，交付用户想要的软件，在过程中团队成员有效的沟通，最终的效果：用户满意，团队成员有所成长。