Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
153 lines (80 sloc) 5.41 KB

#读《高效程序员的45个习惯》

这本书讲的主要是敏捷开发的好习惯。如果你是在一个小型团队做开发,那么这本书将对你十分有益。

书中对敏捷开发有一句精辟概况:敏捷开发是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善

下面将是一些书中的摘录,将夹杂我个人结合实践(游戏开发)的一些思考。

  • 做事

指责并不能修复bug,遇到问题时不应该互相追究责任,而是应该直面问题,解决问题。

互相指责必然会导致团队士气下降,对事而不对人,优先解决问题(矛盾,bug)才是王道。

  • 欲速则不达

Debug不要堕入简单的快速修复中,而应该理解所做的修改,并且让代码保持整洁。

总之,不要急于修复一段你没有理解的代码。

  • 跟踪变化

每天花一点时间来学习新的技术。你不需要精通所有技术,但是需要了解行业的动向,以规划你的职业生涯。

一味着守着过时的技术可能会产生依赖,难以进步。

  • 把握开发节奏

站立进行会议,以节省会议时间。

保持舒服的迭代周期,不要搞得经常加班。

在每天结束时,测试,提交代码。

加班与否通常是一个效率问题,制定好合适的工作量,然后专注去完成它。

  • 合理使用技术

不要重复造轮子。不要开发你能够下载到的东西。

如果有别人写好的,可靠的工具,则利用工具。

  • 保持可以发布

每一次提交到代码仓库的代码必须保证正确

这一点可以通过持续集成工具达到,比如jekins。

同时也需要你对每一次提交进行测试,对代码负责

  • 通过演示获得反馈

需求是会不断变更的。每次迭代过后都需要进行一次演示(DEMO),获取反馈,以修正下一次迭代。

  • 使用短迭代,增量发布

将迭代周期尽可能缩短,这样能让人感到十分有效率,且能频繁获得反馈。

每一次的迭代应该有一个具体的小目标,通过增量式的而不是一蹴而就的来检查每个目标的完成情况。

  • 度量真实的进度

通过待办事项,每一天结束时,确定哪些任务完成,哪些任务没有完成。

将没有完成的任务列上优先级,然后估算剩下的工作量,一般以小时为粒度。

  • 代码要清晰地表达意图

代码的可读性十分重要,尤其在多人合作的敏捷开发中。

代码不应该炫技,应该清晰明确表明意图。

代码可以通过命名的规范来进行自说明,而不需要依靠多余的注释。

注释最好写在函数接口和极其复杂(一般需要重构)逻辑处。

  • 动态评估取舍

一件事情几乎可以永远优化下去,所以你需要判断一个平衡的点,优化到一定程度就停止。

另外,过早优化是万恶之源。因为过早优化有可能在未来并不适用,然后提前的优化增加了代码的复杂度和理解成本。

  • 增量式编程

不要连续几小时的进行编写代码。

将大任务分解为小问题。然后一个个的去编写相关代码。

写完一个小问题的代码段后,编译运行以保证正确性,然后休息一段时间,再继续。

  • 保持简单

优先使用最简单的技术。因为简单的代码更能一眼看出问题。

除非有不可辩驳的原因,否则不要使用复杂的模式和高难度技术(指针)类的东西。

简单的代码意味着没有重复代码和多余代码,且仍然能完成全部功能。

  • 编写内聚的代码

将类的功能尽量集中,不要创建无所不包的大杂烩的类。

将职责尽可能明确,集中:每个类只做一件事情,然后把它做好。这样bug很容易跟踪,代码也十分容易修改。

  • 告知,不要询问

将命令(可能对数据有改动)和查询(只读,不改动)分离。否则很容易出bug。

  • 问题解决日志

建立一个问题(坑)和其解决方案的备忘录。以防止趟两次一样的坑。

  • 对问题各个击破

将问题进行分离。比如可以用二分法来定位bug,将代码空间分割成两半,然后分离其中一半,看bug是否在另外一半中。

debug时,要将问题域与周边隔离开来,找到了bug原因,debug就完成了一大半。

  • 提供有用的错误信息

程序发生错误时,如果在开发阶段,应该给出明显而详细的报错堆栈;如果在产品交付阶段,则应该记录下log,并找到合适的时机发送回来。

  • 每日立会

每天早上上班前,先开站立会议,回答三个问题:

* 昨天的收获?
* 今天的计划?
* 当前有哪些问题和阻碍?

立会时间一般在10-15分钟比较理想。

小型团队可能不需要每天都碰头,两天一次或者一周两次也可以。

立会不要过多的深入细节,给出具体进度即可。

  • 教学相长

通过详细解释自己知道的东西,也可以使自己的理解更加深入。

分享可以提高队友和自己的能力和水平,为团队增值。

  • 做代码复查

复查的checklist:

1. 代码是否能被读懂和理解?
2. 代码是否有明显的错误?
3. 代码是否会对其他代码产生副作用?
4. 是否存在重复代码?
5. 是否存在改进和优化空间?

代码复查必须给出反馈,然后每个人根据反馈采取行动。