《高效程序员45个习惯》-敏捷开发有感

《高效程序员的45个习惯》  ----敏捷开发修炼之道

“Standing on shoulders of Giants” –“站在巨人的肩膀上”

 

创建时间:2014920日星期六

创建作者:H

 

该书一共用了两天时间通读完,简单的翻看其中的道理,把其中有用的好的道理和哲理摘录和用自己的话说出来,引以为用。希望对看过该文的人有所帮助。

 

在写该书有关内容之前,我一直认为,看书是一种能够帮助人提升境界和阅历的最好方式之一。它不是直接的在教给你武功,更多的是在传授给你内功心法。金庸武侠里,天下武功极高的前辈不是那些招式很硬气的江湖大佬,而是内功高深之士。练武者,如果仅仅是练习一招一式,也仅仅是做一个武痴,而如果能够对内功有一定的造诣,往往能悟出其中的道理。

 

 

1、不管路走了多远,错了就要重新返回。

这句话相信做过软件开发的人都有感触。代码已经写了几百行或者几千行,突然程序在往下写就会出现重大的bug,怎么调试都有问题。坚持了半天没有解决,坚持了一天没有解决,坚持了三天还是没有解决,这时你就慌了,心想,妈的,这让哥如何是好?!重新设计架构和打码,不忍心,不重头开始吧问题又得不到解决。这种情况是开发者常见的情况,也是比较郁闷的时候,我就多次遇到过这种情况。比如我本科毕设做的控制板卡,画的一块pcb电路板,第一遍一共飞了4根线,凑凑合合算是画完了,以为就这样吧,四根线在外面连吧,无所谓的,拿给指导老师(霍老师)看,就是不行,很多问题,我现在依然记得这些问题是什么(虽然不画板子很久很久了),比如液晶的固定孔尺寸大小不对,电源电路滤波电容放的位置不对,不符合电容摆放的几个原则,电源线和底线没有加粗,走线不好,要交叉,减少走线长度等等,说了一些问题后回来重新画,第二遍拿过去以为可以了,但还是不行,就这样来来回回一共画了15遍,最后的效果,按我的老师话讲,还可以更好,那块板子我认为已经非常好了,没有飞一根线,所以你就知道其中花费的精力了。

前段时间做基于linux环境下的C的开发,也是遇到同样的问题,代码已经写了5、6百行了,编译运行就出现错误了,让我很是不解,最后还是经过调试发现了指针偏移出了问题,通过修改偏移量,才算解决了问题。避免了一场精神浩劫。

所以遇到这种情况,肯定前面的基础没有铺垫好,如果对后面的架构产生严重的影响,需要重新返工。

 

 

2、成为指导者

我们有时会发现自己在某些方面,比其他团队成员知道的更多,那要怎么对待这种新发现的“权威地位”呢,可以分享自己的知识,让身边的人变得更好。

好的想法不会因为被许多人了解而削弱,当我听到你的主意时,我得到了知识,你的主意也还是很棒。同样的道理,如果你用你的蜡烛点燃我的,我在得到光明的同时,也没有让你的周围更暗。好主意就像火,可以引领这个世界,同时不削弱自己。

与团队其他人一起共事是很好的学习机会。知识有一些很独特的属性。假设你给别人钱的话,最后你的钱会变少,而他们的财富会变多。但如果是去教育别人,那双方都可以获得更多的知识。

通过详细的解释自己知道的东西,可以使自己的理解更深入。当别人提出问题时,也可以发现不同的角度。也许可以发现一些新技巧----听到一个声音这样告诉自己:“我以前还没有这样思考过这个问题”。

与别人共事,激励他们变得更出色,同时可以提升团队的整体实力。遇到无法回答的问题时,说明这个领域的知识还不够完善,需要在这方面加强。

成为指导者---意味着要分享,而不是固守自己的知识,经验和体会。意味着要对别人的所学和工作感兴趣,同时愿意为团队增加价值。一切为了提高队友和你的能力和水平,而不是为了毁掉团队。

---Knowlodgegrows when given.

 

 

3、架构师必须要写代码

“只有一张蔬菜图无法做出好的咖喱饭”.

现在it行业最顶级的人就是架构师了,他是一座灯塔,指引着一切行动。然后架构师不可以只会纸上谈兵。必要的时候,也要能够加入团队,参与代码实现过程。这里我觉得更多的是一个团队负责人所起的作用。负责人要做的工作除了安排整个项目进度和每个人的分工,更重要的一点就是把握项目的进度和明确每个人的任务是什么。如果说一个项目主要是由团队的工程师来完成的话,那么负责人的身份首先应该是一个工程师。站在工程师的角度,要能够放到水里会游,放到路上就跑,有这样说干就干的能力和魄力。那就是要对整个项目的架构和思路有所了解和掌握。知道怎么去实施怎么写代码,这是非常重要的。负责人首先要是工程师。

 

 

4、增量式编程

不要把敲代码比作长途旅行。时时测试下自己的程序,保证没有问题。

 

 

5、不要用注释包裹你的代码

尝试用代码沟通。

终于又回到了编程这个问题,曾经有个大三的本科生说我写的代码很烂,这是大概的意识。对此,我没有理由。主要一个问题就是变量名,所以说不要企图用注释来解释你的代码,代码本本身就是最好的注释。

 

 

6、迭代式开发

迭代式开发是项目开发中的一个术语。意思就是当开发自己的程序时,要时时的调试和测试自己的模块是否是健康的、健壮性良好的、安全的代码。现在很多人都会写一两行代码,但严格意义来说,会写代码不意味就能够成为一个良好的程序员。你要扪心自问,自己的代码是否是健壮性良好的,安全的,可测试的代码。这是成为一名合格程序员的关键。

 

 

7、写能够具有反馈的代码

如何做到让自己的代码具有良好的测试性呢?

书上大致意思是:写具有反馈的代码

比如我写如下的代码:

int main()

{

Int rep = 0;

Char writebuff[10]= {“hello”};

FILE *fp =fopen(“1”,”r”);

If(fp == NULL)

{

Perror(“file failed”);
}

       rep= fwrite(writebuff,sizeof(char),10,fp);

if(rep< 0)

{

Printf(“writefailed\n”);

exit(0);
}

   printf(“write %d bytes\n”,rep);

   return 0;

}

 

Rep就是一个反馈值,用来检测函数的返回

 

 

8、需求就像是流动着的油墨

所以我们在做开发的时候,一定要把所有的API留有一定的余地,不要全部做死,就好像我们说话办事不要那么的绝,给别人也给自己留个台阶

 

 

 

9、学会投资

这句话的意思和前面的差不多,就是要学会与人分享,不要把学到的知识固步自封,知识是没有任何价值的,今年的知识明年可能就陈旧了,学会利用知识才是最重要的。

 

10、态度决定一切

这句话我看过多次了,希望自己的努力能够有所收获。

 

第1章 敏捷——高效软件开发之道 第2章 态度决定一切 1. 做事 2. 欲速则不达 3. 对事不对人 4. 排除万难,奋勇前进 第3章 学无止境 5. 跟踪变化 6. 对团队投资 7. 懂得丢弃 8. 打破砂锅问到底 9. 把握开发节奏 第4章 交付用户想要的软件 10. 让客户做决定 11. 让设计指导而不是操纵开发 12. 合理地使用技术 13. 保持可以发布 14. 提早集成,频繁集成 15. 提早实现自动化部署 16. 使用演示获得频繁反馈 17. 使用短迭代,增量发布 18. 固定的价格就意味着背叛承诺 第5章 敏捷反馈 19. 守护天使 20. 先用它再实现它 21. 不同环境,就有不同问题 22. 自动验收测试 23. 度量真实的进度 24. 倾听用户的声音 第6章 敏捷编码 25. 代码要清晰地表达意图 26. 用代码沟通 27. 动态评估取舍 28. 增量式编程 29. 保持简单 30. 编写内聚的代码 31. 告知,不要询问 32. 根据契约进行替换 第7章 敏捷调试 33. 记录问题解决日志 34. 警告就是错误 35. 对问题各个击破 36. 报告所有的异常 37. 提供有用的错误信息 第8章 敏捷协作 38. 定期安排会面时间 39. 架构师必须写代码 40. 实行代码集体所有制 41. 成为指导者 42. 允许大家自己想办法 43. 准备好后再共享代码 44. 做代码复查 45. 及时通报进展与问题 第9章 尾声:走向敏捷 9.1 只要一个新的习惯 9.2 拯救濒临失败的项目 9.3 引入敏捷:管理者指南 9.4 引入敏捷:程序员指南 9.5 结束了吗 附录A 资源 索引
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值