『高效程序员的45个习惯:敏捷开发修炼之道』读书笔记

以下我近些日子的读书笔记。

这本书在我的Pad上也停留了很久,却一直没有毅力将它完整地看完。

原来在微信群里每天发一小段,一方面与同事们分享,另一方面也是把事情挑起来,接受公众的监督。(因为我做事有虎头蛇尾的臭毛病)

电子书见:http://www.amazon.cn/mn/detailApp?asin=B00ALPRKJ8&tag=baiduiclickcn-23&ref=pz_ic_db_j_5bkindle3175

以下切入主题:


第2章:态度决定一切

敏捷团队依赖于人,依赖热情洋溢的你,而不是项目的甘特图和里程表,以及各种各样冷冰冰的需求文档。所以,每个人的态度至关重要。


1、做事:

指责不会修复Bug,所以在敏捷团队中,大家最重要的是做事,出现了问题,应该把重点放在如何解决问题,而不是在指责和抱怨中喋喋不休。

把矛头对准解决问题的方法而不是人,才是有效的正面效应。

如果你没有犯过错误,说明很有可能是你没有努力工作。//很喜欢这个腔调,程序员是个充满挑战的领域,别怕失败和错误。

过程符合标准不意味着结果就是正确的,敏捷团队重结果胜于重过程。//结果导向。


2、欲速则不达:

不要坠入快速的简单修复中,要投入时间和精力来保持代码的整洁和敞亮。只有理解问题才能真正解决问题。


3、对事不对人:

我们评价需求的优先级,往往是根据提出人的身份地位,而不是需求本身的市场价值和利害关系。(心坎里)……让团队中每个人自由表达观点……让我们骄傲的应该是找到了解决问题的正确方法,而不是谁比谁聪明,谁比谁历害。


4、排除万难,奋勇前进:

有时候,绝妙的计划会因为勇气不足而失败,例如“谁去给猫系铃铛”。


第3章:学无止境

敏捷需要持续不断的学习和充电。能否保持步伐前进?只能取决于你自己。


5、跟踪变化:

唯有变化是永恒的。你不需要精通所有技术,但要清楚行业的动向。通过迭代和增量式学习,让自己跟上时代。


6、对团队投资:

团队中每个人都有不同的能力、经验和技术,各有所长。促进成员之间的分享,打造学习型团队。

可以在任何时间,比如午餐的时候讨论你感兴趣的技术问题。

保持每个人对技术的激情。//工程师文化氛围让大家对工作充满激情。


7、懂得丢弃:

拥抱变化,学习和使用新的技术。


8、打破砂锅问到底:

不停地问为什么,直到你明白问题的真正根源。


9、把握开发节奏:

上帝发明了时间,就是为了防止所有事情同时发生。//非常好的一句话,

设定一个时间盒,它的时间长度固定不变,而承载的需求可以灵活安排,这样最大的好处是项目进度可控。

小且可以达到的目标可以让人全速前进。//目标一定要是可达的!


第4章:交付用户想要的软件

没有任何计划在遇敌之后还能继续执行。我们的敌人不是客户、不是用户、不是队友,也不是领导,而是变化!


10、让客户做决定:

开发者不要对业务功能做任何决定。把问题交给业务负责人。

//不过,对于小的团队,我们不做决定,但可以提建议,不是吗?每个人都是产品经理嘛。


11、让设计指导而不是操纵开发:

敏捷建议在项目开始就编码,但并非不要设计,而是在开发的全过程中都有设计。

设计满足实现即可,不必过于详细。世界上没有代码工人,程序员不是打字员。

设计分战略设计和战术设计,战场瞬息万变,把事情交给程序员好了。

好的设计是正确的而不是精确的。//记住这句话!好的设计是因地制宜的,兵无常形水无常势。


12、合理的使用技术:

这个技术框架真的能满足需求吗?它的维护成本是多少?.....不要花时间开发你能下载到的东西,(拥抱开源?我的理解)

//不要过分设计,同时也不要过分玩弄技巧。


13、保持可以发布:

已提交的代码保持随时可以行动……任何时候,只要你没有准备好,那就是敌人进攻你的最佳时刻……


14、提早集成,频繁集成:

代码集成是主要的风险来源。敏捷是一个持续开发的过程,最好能在项目的早期实现集成,并且持续有规律的集成。

//坚持每天集成,每天都能看到效果,利国(领导满意)利民(自己满意)。


15、提早实现自动化布署:

测试人员也要像测试功能一样测试布署过程,可以借助自动化布署工具。但是使用自动化测试和布署,可以让持续集成更容易被接受,必可以让用户更早看到产品。


16、使用演示获得频繁反馈:

需求就象流动着的油墨,不可能被冻结。就象你不可能冻结市场、竞争和知识、成长。让开发的的过程对用户可见,双方都会觉得舒适。

//需求冻结?我的理解需求应该短时间被冻结,至少保证我们有一个冲刺时间,但长期不变,是不可能的。


17、使用短迭代,增量发布:

给我一个详细的长期计划,我给你一个注定完蛋的项目。//哈哈,太喜欢这个腔调了……

关注那些使产品可用且不可缺少的核心功能……尽快把软件交到用户手里。


18、固定的价格就意味着背叛承诺:

软件项目天生就是变化无常,不可重复,无法做出精确的评估,关于工期成本预算等等,都不可能精确估算……

让团队与客户在一起工作,由客户控制他们要的功能和预算。


第5章:敏捷反馈

一步行动,胜过千万砖家的意见!


19、守护天使『单元测试』:

代码在快速变化,你需要能持续获得代码健康状态的反馈,所以要编写能产生反馈的代码……

没有单元测试,就象高空作业没有系安全带一样。……


20、先用它再实现它:

编写代码之前,先写测试。站在代码用户的角度去思考,有助我们去设计一个更有用更一致的接口……

避免过度设计,好的设计并不意味需要更多的类……//简单就是好。

测试驱动(TDD)有助于为我们带来更简单更实效的的设计。//测试真的很重要,即能检查需求是否合理,又能检查设计和代码是否正确。


21、不同环境就有不同问题:

但是它在我的机器上就能正常工作。//程序员经常说的一句话,呵呵……

使用持续集成工具,在所有支持平台和环境下运行单元测试。


22、自动验收测试:

单元测试之外,关键业务逻辑要独立进行严格测试,并且最后需要用户审批。FlT(集成测试框架)可以帮助进行自动化验收测试。


23、度量真实的进度:

不要用进度百分比来度量进度,80%听上去不错,但它仍没有完成任务……//进度百比率就是PM给的一个自欺欺人的东西!

不要评估已完成的工作量占比,要测算还有多少工作量没有完成。评估那些需要完成的待办事项。如SCRUM中的每个Sprint。


24、倾听用户的声音:

任何问题都是开发团队的问题,不是用户的问题。//用户是上帝,怎么可能错?!……

大多数程序员总把问题归结到用户不会用,请耐心地倾听!每一个抱怨后都隐藏一个事实,找到真相,修复真正的问题……

如果代码解决不了问题,可以用文档和培训解决……

没有愚蠢的用户,只有愚蠢自大的程序员。//嗯,是的。


第6章:敏捷编码

任何一个笨蛋都能让事情变得越来越笨重,越来越复杂。


25、代码要清晰地表达意图:

代码清晰,设计简单,没有缺陷。PlE原则,意图清楚且表达明确地编程……

今天的你觉得显而易见的事情,对于其他人可能并不那么认为,对于一年以后的你也可能并不那么认为,所以,请保持代码的可读性吧………


26、用代码沟通:

程序员不要写太详细的WORD文档,不但有违TRY原则,也容易生成让人误解的文档……//错误的文档比没有文档更可怕

也不要依赖注释,只在关键的地方注释即可……注释不是告诉读者代码做了什么,而是要告诉读者为什么这么做……让代码遵循规范,简洁优美……


27、动态评估取舍:

过犹不及……没有适宜所有问题的最佳解决方案,每个设计都是解决特定的问题……让用户帮助你找到他们的痛点……

过早的优化是万恶之源。


28、增量式编程:

在很短的编辑/构建/测试的循环中编写代码,可以创建更加简洁清晰,易于维护的代码……更小的的方法和更具内聚性的类。


29、保持简单:

简单不是简陋……不要强迫自己陷入过度设计,也不要让代码过度复杂化……有节制地使用设计模式……

一个人以为简单的东西,也许对另一个人就觉得复杂。


30、编写内聚的代码:

让类的功能尽量集中,让组件尽量小……内聚性让代码更稳定……单一职责原则,重用发布等价原则。


31、告之,不要询问:

将命令和查询分离开……不要抢其它人的工作,告诉他们做什么,然后盯着自己的职责就好了(做人又何尝不是如此)……类似ObjectC的发送消息……


32、根据契约进行替换:

Liskov替换原则,派生类应该可以替换基类……对于is-a才使用继承,has-a 或uses-a 应该使用委托……


第7章:敏捷调试

真正的高手只是知道如何亡羊补牢。


33、记录问题解決日志:

不要在一个地方跌倒两次……记录你遇到的问题和你的详细的解决方案,以后你得到的帮助……

做一个 Wiki,让知识在团队成员中共享。//这个必须!!!


34、警告就是错误:

嗯,这个很好理解,只要条件许可,把所有警告都消掉吧……让编译结果就只有一个干干净净的Success,多完美!


35、对问题各个击破:

大型系统非常复杂,发生问题可能难以下手,如果有单元测试,有助于我们分离问题模块……如果没有,可以用原型系统来分离问题……


36、报告所有的异常:

即使不向用户展现,但自己人要可看见它们……不要擅自catch掉异常,除非你能处理它,否则就把它抛出去……


37、提供有用的错误信息:

给用户优雅的有建设性的错误提示,同时要在日志中提供详细的错误堆栈……

//多用日志解决问题,不要用System.out,太不优雅了!


第8章 敏捷协作

高效的协作是敏捷开发的基石。


38、定期安排会面时间:

立会(注意是立会,不是例会)……只要三个问题,昨天收获,今天计划和遇到的困难……


39、架构师必须写代码:

新系统的设计者要亲自投入到实现中……积极地编程带来深入的理解,优秀的设计从积极的程序员那里开始演化。

//太对了,不要招聘那些所谓的架构师!不写代码的架构师不是好架构师,不想当架构师的程序员不是好程序员。


40、实行代码的集体所有制:

让程序员轮换完成不同领域的不同模块的不同代码……有助于团队提升整体的知识和技能,提升代码的质量……

但是要保证每个领域有驻留专家……并且也不是意味每个人可以乱改代码。


41、成为指导者:

教学相长……//授人玫瑰手有余香……

分享自己的知识很有趣,付出的同时便有收获……


42、允许大家自己想办法:

接上一个习惯,授人以渔,而非授人以鱼……


43、准备好再共享代码:

决不提交尚未完成的代码,提交未通过编译或未通过单元测试的代码,在项目中是属于玩忽职守的行为……(Git这点做得挺好)。

//非常重要,乱提交代码,损人不利已。


44、做代码复查:

代码复查或许是找到问题并解决问题的最佳办法,比测试更有效……结对编程……所有人的代码都应该被复查……

代码审查的问题:代码是否易读?是否有明显错误?是否对其他模块有不利影响?是否重复?是否可以重构?


45、及时通报进度和问题:

发布进展和状况,新的想法,遇到的困难,不要等到领导来问你。//太对了,领导是一个很可怕的动物,千万不要招惹他。



阅读更多
文章标签: 敏捷开发 敏捷
个人分类: 一家之言
上一篇关于敏捷的一些事儿
下一篇十分钟接入WO+能力共享平台
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭