|
http://jianchen./blog/695314 2010 之前主管推荐过这本书，主管买了几本，20多个同事大家共享着看。端午节放假期间去书店溜达了下，看看价格也不贵，才35块，就买了。冲动的是同时买了《重构-改善既有既有代码的设计》这本书。今天在卓越上看到便宜17块多。觉得是好书就本着收藏的想法，本已所剩不多的钱袋又多了一笔开销。这个月剩下的日子花钱可得悠着点了。
这两天迅速的把《高效程序员的45个习惯》这本书翻完了。这本书读起来还是挺流畅的，翻译的质量不错。将一些敏捷的理念和时间款款道来。写的还是很好的，不是那么教条，读起来轻松愉快。说实话，很多概念在没看这本书之前就有所了解了。总体感受是，提出的方法实践还是靠谱的，如果真能说实施起来，对平时的工作绝对是有益处的。
真正的难点是实施起来不太容易。但在敏捷越发得到认可的今天，公司里已近有些项目团队开始进行实践，虽然不是很成功，但是终归是个开始，会向真正的敏捷靠拢的。
书中提出了45个习惯，抑或是手段。从团队的管理，到个人的提升，以及项目的完成，多角度的进行阐述。
1， 做事 强调做事的重要性，每当出了问题，不是找出导致出现问题的人是谁去抱怨，打击对方，优先做的是大家共同将该问题解决。
2， 欲速则不达 在实际的工作中，一个新手接到一个问题，面对不熟悉的代码，往往会迅速的定位问题，然后加上自己自认为可以解决的方法，而没能很好的理解上下文，就贸然加上相关代码， 可能看起来问题的确得到了解决。之前就讨论过这个问题，一个项目为什么代码越写越烂。往往是不敢动被人的代码，我们需要的是一种勇气，敢于跟老大提出，给我一周的时间，将这段代码重构。如此每个人都能做到，代码会越来越好，而不会smell bad。
3， 对事不对人 面对比起来无论是经验还是实际技能上多远不如你的人，需要保持一颗谦逊的心。在某个会议上，他提出的问题和想法也许会很愚蠢，但是没有必要嘲笑别人。想想看，自己当年何尝不是这样过来的呢。况且他的想法未必没有道理，看起来很简单的问题往往会促使你做出思考，得到新的结论。打击别人让自己显得很聪明，绝对没有必要。这样只会让你的同事感觉很气馁，以后他发言就不会很积极了。你要做的是鼓励他，跟他积极的探讨，久而久之，他就会成长起来。
4， 注重团队的投资。 内部经常性的交流分享，可以比较有效的提升大家的技能，激发大家的学习兴趣。“三人行，必有我师”，别人总有你可以学习的地方。可以让团队成员定期的做分享，技术，人生，主题不限。分享者会积极的准备，强化他这方面的知识，提高他的演讲能力。要知道，经常跟代码打交道的人往往沉默呐言，不善于沟通。还可以增进团队的合作氛围。哎呀，好处太多了。新人前期主要是听别人的分享，慢慢的可以自己分享一些东西出来，已分享促进学习，良性循环。
5， 敏捷强调小步前进，增量迭代式开发。 面对用户善变的需求，需要的是经常跟用户沟通，让用户参与进来，让用户做决定，你需要做的是帮他们分析这样做的好处，以及不这样做带来的后果，进行多方面的比较。让用户深刻的体会到，你是跟他们一伙的。呵呵。迭代周期中，定期的发布版本，给用户进行demo演示，让客户看到你的成果，频繁获得反馈，以进一步确认需求，一步一步的接近用户想要的结果。
6， 敏捷强调不能过分设计。 前期的设计只要在战略上正确即可。真正详细的设计是面对开发过程中需要解决的问题进行的战术调整。书中提出的“让设计指导开发而不是操作开发”，与后面的“架构师必须写代码”，因为前期的设计往往无法预料到实际出现的问题。如果一开始就定死了代码的设计，让一群代码编写人员岂不很无聊。这样可以在每次迭代中大家集体参与设计，真正得到满足当前需要的最好的设计方案。我在之前参与的项目中，每个人负责相应的模块，自己设计自己的，虽然满足要求，但是未必是最好的，如果几个人共同参与，一方面可以提升设计的质量，还可以提高成员的设计能力。同是大家都能了解对方模块的设计理念（因为我也参与了），有书中后面提到“代码共同所有制”有异曲同工之妙。这样任何一个人都可以完全接手别人写的代码，这样后期的维护成本不会因为某个成员不在而几何级的增加。结合代码复审，一个人可以把一段代码发给大家，让大家帮忙看看写的是否有问题。当然根据实际情况，可以每周花固定的时间大家做在一起探讨。面不要铺的太宽，选取比较核心或有相关人员提出的代码就可以了。
7， 对于开发人员，也提出了比较好的实践指导。 别对警告视而不见，觉得不影响程序的运行。将警告当做错误，力求没有警告。项目中经常看到未使用泛型的警告，未使用的局部变量等警告，虽然你的程序可以跑，但是代码的质量不能算高。真正的编程人员不容许代码存在坏的味道。自己写的代码就是自己的作品，一个人的脸面，力求让别人觉得你的代码亲切，觉得似曾相识，一下看懂你这个“人”，了解你这个“人”。代码要清晰的表达意图，注释不需要太多，敏捷追求的就是代码即文档。程序员间用代码可以轻松的沟通，那才厉害。具体的有很多良好实践：增量式编程，保持简单，编写内聚的代码，告知对方，不需要询问，根据契约进行替换。
8， 越来越多的人认可单元测试的重要性。 但是做好单元测试却不是那么容易的事情。我自己在写代码的时候，往往就觉得写单元测试，造数据很麻烦。还好现在有很多开源的框架可以利用，很大程度上减轻的工作量。单元测试不应该是一次性的，良好的单元测试可以作为代码文档。测试驱动开发，这个有点高级，通过一个个失败的测试，不断的编写代码，完善自己的设计。TDD暂时还没见到比较好的时间，但是基本的单元测试还是写的比较多了。对象之间的依赖可以用mock对象解决，数据库层，web层的代码都可已进行相应的测试了，编写测试是项目的成本，前期自己的代码会写的比较慢，但是越往后，就越会发现些单元测试的好处。需要修改代码的时候，跑一下单元测试，如果出现了红条，迅速的定位问题，可以明显的提高效率。对于一个新接触这段代码的人来说，单元测试同样会提供很大的帮助，他可以轻松的了解代码的逻辑，需要注意的地方。
9， 提倡比较高频率的提交代码，但是代码必须是准备好的。 不能因为你提交的代码导致程序无法编译，或者报错导致别人无法继续工作。所以就和上面的单元测试有关系了，代码必须自己本地自测通过后再提交。提交需要单元测试却没做的代码是不负责任的行为。这一点我们要坚决抵制。
10，不得不提的还有持续集成。 自动构建，跑单元测试，失败后立即通知，迅速发现问题。像hudson持续集成平台，提供单元测试的覆盖率报告等其他有用信息。要提早集成，不要大爆炸式的最后集成。当早期集成的时候，你会看到系统之间的交互和影响，就可估算他们之间通信和共享的信息数据。代码提交后自动的构建部署，不得不说这样很酷。一切都帮你搞定，你需要做的只是收到报告即可。成功的报告当然很爽，失败也没关系，因为目前一切都可控，影响范围不大。
作者用几句歌诀简明的进行了概述：
迭代开发，价值优先 分解任务，真实进度 站立会议，交流通畅 用户参与，调整方向 结对编程，代码质量 测试驱动，安全可靠 持续集成，尽早反馈 自动部署，一键安装 定期回顾，持续改进 不断学习，提高能力
看完这本书对敏捷的理解貌似不是很多，就是感觉对你书中的观点挺赞同的，好像理所应当这么做似的。现在公司里QA已近慢慢的在推这些事情了。包括现在的代码质量管理，使用类似findbug，checkstyle之类的工具进行简单的改进。要真正的把敏捷搞好，将项目的质量做好，首先要做的是必须大家认可才行，在大家支持的情况下去做这件事就会比较顺利。之前听过scrum的分享，大概的了解的一些新鲜词语。什么sprint，backlog等。等看完《轻松scrum之旅----敏捷开发故事》，我想会对敏捷有更多的认识和理解吧。
|
|
|
来自： 心不留意外尘 > 《topcoder》
