高效程序员的45个习惯
dongxie548
IT民工一枚
展开
-
高效程序员的45个习惯之敏捷协作
高效程序员的第三十八个习惯:定期安排会面时间 使用立会。立会可以让团队达成共识。保证会议短小精悍而不跑题。 此处的立会指的是高效程序员的第三十九个习惯:架构师必须写代码 优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿编程的架构师–不知道系统的真实情况,是无法展开设计的。高效程序员的第四十个习惯:实行代码集体所有制 要强调代码的集体所有制。让开发人员轮换完成系原创 2015-05-04 21:57:43 · 820 阅读 · 0 评论 -
高效程序员的45个习惯之敏捷,高效软件开发之道
近几年,极限编程、敏捷开发等词大热,那么什么才是敏捷开发呢? 在venkat subramaniam和andy hunt合著的《practices of an agile developer》一书中对敏捷开发给出了如下定义: 敏捷开发就是在一个高度协作的环境中,不断的使用反馈进行自我调整和完善。 接下来,这本书从下面几个章节详细的探讨了敏捷开发: 1、态度决定一切; 2、学无止境; 3原创 2015-05-03 19:55:18 · 550 阅读 · 0 评论 -
高效程序员的45个习惯之学无止境
高效程序员的第五个习惯:跟踪变化 跟踪技术变化,你不需要精通所有的技术,但需要知道行业的动向,从而规划你的项目和职业生涯。 高效程序员的第六个习惯:对团队投资 提供你和团队学习的更好的平台,通过午餐会议可以增进每个人的知识和技能,并帮助大家聚集在一起进行沟通交流。唤起人们对技术和技巧的热情,将对项目大有裨益。 文中提到的午餐会议是指:在一周之中挑选一天,要求团队中的一个人主持讲座。他可原创 2015-05-03 20:08:30 · 626 阅读 · 0 评论 -
高效程序员的45个习惯之态度决定一切
高效程序员的第一个习惯:做事 可以用一句话概括这个习惯,即指责不能修复bug(blame does'nt fix bugs):把矛头对准解决问题的方案,而不是人,这是真正有用处的正面效应。 高效程序员的第二个习惯:欲速则不达 不要坠入快速的简单修复中,要投入时间和精力保持代码的整洁、敞亮。 高效程序员的第三个习惯:对事不对人 对事不对人,我们骄傲的应该是解决了问题,而原创 2015-05-03 20:06:36 · 583 阅读 · 0 评论 -
高效程序员的45个习惯之交付用户想要的软件
高效程序员的第十个习惯:让客户做决定 让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言,向他们详细解释遇到的问题,并让他们做决定。高效程序员的第十一个习惯:让设计指导而不是操纵开发 好的设计是一张地图,它也会进化。设计指引你像正确的方向前进,它不是殖民地,它不应该标识具体的路线,你不要被设计操纵。高效程序员的第十二个习惯:根据需要选择技术 首先决定原创 2015-05-03 23:52:14 · 601 阅读 · 0 评论 -
高效程序员的45个习惯之敏捷反馈
高效程序员的第十九个习惯:守护天使 使用自动化的单元测试。好的单元测试能为你的代码问题提供及时的警报。如果没有到位的单元测试,不要进行任何设计和代码修改。高效程序员的第二十个习惯:先用它再实现它 将TDD(测试驱动开发)作为设计工具,它会为你带来更简单更有实效的设计。高效程序员的第二十一个习惯:不同环境,就有不同问题 使用持续集成工具,在每一种支持的平台和环境中运行单元测试。要积极的寻找问题,原创 2015-05-04 21:09:30 · 480 阅读 · 0 评论 -
高效程序员的45个习惯之敏捷编码
高效程序员的第二十五个习惯:代码要清晰的表达意图 软件设计有两种方式,一种是设计得尽量简单,并且明显没有缺陷。另外一种是设计得尽量复杂,并且没有缺陷。 遵循PIE(program intently and expressively)原则。 要编写清晰而不是讨巧的代码。向代码阅读者明确表明你的意图。可读性差的代码一点都不聪明。高效程序员的第二十六个习惯:用代码沟通 用注释沟通。使用细心选择的、原创 2015-05-04 21:32:23 · 576 阅读 · 0 评论 -
高效程序员的45个习惯之敏捷调试
高效程序员的第三十三个习惯:记录问题解决日志 维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分,以后发生相同或者类似问题时,就可以很快找到并使用了。高效程序员的第三十四个习惯:警告就是错误 将警告视为错误。签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。高效程序员的第三十五个习惯:对问题各个击破 在解决原创 2015-05-04 21:45:01 · 580 阅读 · 0 评论 -
什么时候用委托,什么时候用继承?
如果新类可以替换已有的类,并且他们之间的关系可以通过is-a来描述,就要使用继承。如果新类只是使用已有的类,并且两者之间的关系可以描述为has-a或者use-a,就用委托吧。原创 2015-05-05 22:42:26 · 882 阅读 · 0 评论