笔记出自:《高效程序员的45个习惯:敏捷开发修炼之道 (图灵程序设计丛 书 11)》
作者:亨特(Andy Hunt)、 苏帕拉马尼亚姆(Venkat Subramaniam)、 钱安川、 郑柯
开发准则:
迭代开发,价值优先
分解任务,真实进度
站立会议,交流畅通
用户参与,调整方向
结对编程,代码质量
测试驱动,安全可靠
持续集成,尽早反馈
自动部署,一键安装
定期回顾,持续改进
不断学习,提高能力

及时反馈,与人交流

标注(黄) | 位置 148
我们正通过亲身实践和帮助他人实践,揭示了一些更好的软件开发方法。通过这项工作,我们认为: 个 体和交互胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循 计划 虽然右项也有价值,但我们认为左项具有更大的价值。

标注(蓝) | 位置 159
了敏捷开发宣言:一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。

标注(蓝) | 位置 188
敏捷团队往往是一个小型团队,或者是大团队分成的若干小团队(10人左右)。团队的所有成员在一起 工作,如果可能,最好有独立的工作空间(或者类似bull pen1),一起共享代码和必要的开发任务,而 且大部分时间都能在一起工作。同时和客户或者软件的用户紧密工作在一起,并且尽可能早且频繁地给 他们演示最新的系统。

标注(蓝) | 位置 193
前进过程中,你都会有意识地修改一些代码:在功能不变的情况下,重新设计部分代码,改善代码的质 量。这就是所谓的 重构,它是软件开发中不可或缺的一部分——编码永远没有真正意义上的“结束“

标注(蓝) | 位置 206
敏捷团队之所以能够顺利开展工作,而不会陷入泥潭挣扎导致项目失败,就是因为一直使用反馈来纠正软件和开发过程。最好的反馈源自代码本身。

标注(橙) | 位置 457
在开发者眼中的最好,不一定就是用户认为最好的,

标注(橙) | 位置 1065
如果你的迭代周期是一个季节或者一年(那就太长了),就应把周期缩短到一周或者两周。完成了一些功能和特征之后,去积极获得客户的反馈。

及时排错,不放过警告

标注(橙) | 位置 344
拙劣的代码工人会这样不假思索地改完代码,然后快速转向下一个问题。 优秀的程序员会挖掘更深一 层,尽力去理解为什么这里必须要加1,更重要的是,他会想明白会产生什么其他影响。

标注(橙) | 位置 350
千里之堤,溃于蚁穴,大灾难是逐步演化来的。一次又一次的快速修复,每一次都不探究问题的根源,久而久之就形成了一个危险的沼泽地,最终会吞噬整个项目的生命。

标注(橙) | 位置 356
只要我们继续进行快速修复,代码的清晰度就不断降低。一旦问题累积到一定程度,清晰的代码就不复存在,只剩一片浑浊。

标注(粉) | 位置 2005
那么忽略警告信息继续开发代码,会导致什么状况呢?这样做等于是坐在了一个嘀嗒作响的定时炸弹上,而且它很有可能在最糟糕的时刻

标注(粉) | 位置 2038
要找到一种方式让编译器将警告作为错误提示出来。如果编译器允许调整警告的报告级别,那就把级别 调到最高,让任何警告不能被忽略。例如,GCC编译器支持-Werror 参数,在Visual Studio中,开发人员 可以改变项目设置,将警告视为错误。
比如:

$ gcc -Werror test.c
test.c:7:11: error: using the result of an assignment as a condition without parentheses
      [-Werror,-Wparentheses]
    if( a = 2 )
        ~~^~~
test.c:7:11: note: place parentheses around the assignment to silence this warning
    if( a = 2 )
          ^
        ( )
test.c:7:11: note: use '==' to turn this assignment into an equality comparison
    if( a = 2 )
          ^
          ==
1 error generated.

标注(粉) | 位置 2186
没有必要等待抛出异常来发现问题。在代码关键点使用断言以保证一切正常。当断言失败时,要提供与异常报告同样详细的信息。

勇气,坚持等可贵品质

标注(橙) | 位置 465
老鼠们打算在猫的脖子上系一个铃铛,这样猫巡逻靠近的时候,就能预先得到警报。每只老鼠都点头, 认为这是一个绝妙的想法。这时一只年老的老鼠问道:“那么,谁愿意挺身而出去系铃铛呢?”毫无疑 问,没有一只老鼠站出来。当然,计划也就这样泡汤了。 有时,绝妙的计划会因为勇气不足而最终失 败。尽管前方很危险——不管是真的鱼雷或者只是一个比喻——你必须有勇气向前冲锋,做你认为对的

标注(橙) | 位置 543
你不需要一口气爬上10楼,而需要一直在攀登,所以最后看起来就像只要再上一两层

标注(橙) | 位置 601
坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。

标注(橙) | 位置 694
上帝发明了时间,就是为了防止所有事情同时发生。因此我们需要更具远见,保持不同的开发节奏,这样敏捷项目的所有事情就不会突然同时发生。

测试,提交,构建

标注(橙) | 位置 722
每天结束的时候,测试代码,提交代码,没有残留的代码。 不要搞得经常加班。

标注(橙) | 位置 953
在产品的开发过程中,集成是一个主要的风险区域。让你的子系统不停地增长,不去做系统集成,就等于一步一步把自己置于越来越大的风险中

标注(橙) | 位置 1413
FIT1,即集成测试框架,它很实用,可以更容易地使用HTML表格定义测试用例,并比较测试结果

标注(橙) | 位置 1391
不同环境,就有不同问题。使用持续集成工具,在每一种支持的平台和环境中运行单元测试。要积极地寻找问题,而不是等问题来找自己

标注(黄) | 位置 2568
从单元测试开始是一个不错的选择。可以先针对自己的代码开始使用。在短时间之内(几周甚至更 少),就可以看到代码质量提升了——减少了错误的数目,提高了质量,健壮性也有所提升。你下午5点就可以下班回家,而且所有的任务都可以顺利完成——不必担心半夜被电话叫醒,去修复bug。旁边的 开发人员想知道你是如何做到的,而且消息也渐渐传开了。整个团队现在都想尝试这些新奇的习惯,而 不需要你努力去说服

标注(黄) | 位置 2574
还可以在自己机器上运行一个持续构建服务器,发生问题时可以马上知道。队友可能会觉得你有“千里眼”

单元测试和自动化部署的相关资料

标注(橙)和笔记 | 位置 1224
实际上,对任何你可以想象到的环境和语言都有对应的单元测试框架,其中的大部分都可以从http://xprogramming.com/software.htm 上的列表中找到。

标注(橙) | 位置 1246
有很多图书和其他资料可以帮你起步。如果你是一个新手,建议阅读《单元测试之道》(有Java[HT03] 和C# [HT04]版本)。如果要进一步了解测试的一些窍门,可以看一下 JUnit Recipes[Rai04]。 如果想要 自动化地连接单元测试(和其他一些有用的东西),可以阅读《项目自动化之道》[Cla04]。尽管它主要 是关于Java的,但也有类似的可以用于.NET环境或者其他环境的工具。

标注(黄) | 位置 2550
如果你对这些领域不熟悉,到最近的书店(或 www.PragmaticBookshelf.com))去买一本 Ship It! [RG05],它会告诉你如何设置相关的环境和运行机制。入门工具箱(Starter Kit)系列图书可以帮你完 成如何在特定环境下配置版本控制、单元测试,以及自动化等具体细节。

项目推进

标注(橙) | 位置 1460
清楚项目的真实进度,是一项强大的技术

标注(橙) | 位置 1507
新项目刚开始着手开发时,它的代码很容易理解和上手。然而,随着开发过程的推进,项目不知不觉中演变为一个庞然怪物。发展到最后,往往需要投入更多的精力、人力和物力来让它继续下去

标注(橙) | 位置 1528
设计软件有两种方式。一种是设计得尽量简单,并且明显没有缺陷。另一种方式是设计得尽量复杂,并 且没有明显的缺陷。 ——C.A.R. Hoare

标注(橙) | 位置 1533
如果没有人理解一段代码的工作方式,那这段代码还有什么用

标注(橙) | 位置 1535
代码阅读的次数要远远超过编写的次数,所以在编写的时候值得花点功夫让它读起来更加简单

标注(橙) | 位置 1766
要休息的话,就要好好休息。休息时请远离键盘。

标注(粉) | 位置 2096
以 二分查找 的方式来定位问题是很有用的。也就是说,将问题空间分为两半,看看哪一半包含问题。再 将包含问题的一半进行二分,并不断重复这个

关于优雅的设计:简单的方案更加可贵

标注(橙) | 位置 1778
开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲。

标注(橙) | 位置 1786
优雅的代码第一眼看上去,就知道它的用处,而且很简洁。但是这样的解决方案不是那么容易想出

标注(橙) | 位置 1791
开发可以工作的、最简单的解决方案。除非有不可辩驳的原因,否则不要使用模式、原则和高难度技术 之类的东西。

标注(橙) | 位置 1793
当你觉得所编写的代码中没有一行是多余的,并且仍能交付全部的功能时,这种感觉就对了。这样的代码容易理解和改正。

高内聚,低耦合

标注(粉) | 位置 1817
Venkat曾经见过一个用ASP开发的、有20个页面的Web应用。每个页面都以HTML开头,并包含大量 VBScript脚本,其中还内嵌了访问数据库的SQL语句。客户当然会认为这个应用的开发已经失去了控 制,并且无法维护。如果每个页面都包括展示逻辑、业务逻辑和访问数据的代码,就有太多的东西都堆 在一个地方

标注(粉) | 位置 1822
如果应用使用了中间层对象(比如一个COM组件)来访问数据库,数据库表结构变更所造成的影响就可 以控制在一定的范围之内,代码也更容易维护。

标注(粉) | 位置 1824
假设有这样一个类,实现了五种完全不相干的功能。如果这5个功能的需求或细节发生了变化,这个类也 必须跟着改变。如果一个类(或者一个组件)变化得过于频繁,这样的改变会对整个系统形成“涟漪效 应”,并导致更多的维护和成本的发生。

标注(粉) | 位置 1835
让类的功能尽量集中,让组件尽量小。要避免创建很大的类或组件,也不要创建无所不包的大杂烩

标注(粉) | 位置 1837
感觉类和组件的功能都很集中:每个类或组件只做一件事,而且做得很好。bug很容易跟踪,代码也易 于修改,因为类和组件的责任都很清晰。

标注(粉) | 位置 1843
本书的一位检阅者告诉我们这样一个系统,向一个表单中添加一个字段,需要16名团队成员和6名经理的同意。这是一个很清晰的警告信号,说明系统的内聚性很差。

标注(粉) | 位置 1860
与 告知,不要询问 相关的一个很有用的技术是: 命令与查询相分离模式(command-query separation)。就是要将功能和方法分为“命令”和“查询”两类,并在源码中记录下来(这样做可以帮 助将所有的“命令”代码放在一起,并将所有的“查询”代码放在一起)。 一个常规的“命令”可能会 改变对象的状态,而且有可能返回一些有用的值,以方便使用。一个“查询”仅仅提供给开发人员对象 的状态,并不会对其外部的可见状态进行修改。

继承与委托

标注(粉) | 位置 1934
聚合 是指在类中包含一个对象,并且该对象是其他类的实例,开发人员将责任委托给所包含的对象来完 成(该技术同样被称为委托)

标注(粉) | 位置 1941
那么继承和委托分别在什么时候使用呢? 如果新类可以替换已有的类,并且它们之间的关系可以通过is- a来描述,就要使用继承。 如果新类只是使用已有的类,并且两者之间的关系可以描述为has-a或是uses- a,就使用委托。

Bug记录

标注(粉)和笔记 | 位置 1980
工程师们已经使用这种方式很多年了,他们称之为 每日日志(daylog)。 可以选择符合需求的任何格 式。下面这些条目可能会用得上。 问题发生日期。 问题简述。 解决方案详细描述。 引用文章或网址, 以提供更多细节或相关信息。 任何代码片段、设置或对话框的截屏,只要它们是解决方案的一部分,或 者可以帮助更深入地理解相关
每日日志,这是一个非常好的习惯

标注(粉) | 位置 1994
记录问题的时间不能超过在解决问题上花费的时间。要保持轻量级和简单,不必达到对外发布式的质 量。找到以前的解决方法非常关键。使用足够的关键字,可以帮助你在需要的时候发现需要的条目。

会议

标注(粉) | 位置 2214
立会(站着开的会议,Scrum最早引入并被极限编程所强调的一个实践)是将团队召集在一起,并让每个人了解当下进展状况的好办法。顾名思义,参与者们不允许在立会中就坐,这可以保证会议快速进行。一个人坐下来之后,会由于感到舒适而让会议持续更长的时间。

标注(粉) | 位置 2220
要保证会议议题不会发散,每个人都应该只回答下述三个问题。 昨天有什么收获? 今天计划要做哪些工 作? 面临着哪些障碍?

标注(粉) | 位置 2236
每日立会有诸多好处。 让大家尽快投入到一天的工作中来。 如果某个开发人员在某一点上有问题,他可 以趁此机会将问题公开,并积极寻求帮助。 帮助团队带头人或管理层了解哪些领域需要更多的帮助,并 重新分配人手。 让团队成员知道项目其他部分的进展情况。 帮助团队识别是否在某些东西上有重复劳动 而耗费了精力,或者是不是某个问题有人已有现成的解决方案。 通过促进代码和思路的共享,来提升开 发速度。 鼓励向前的动力:看到别人报告的进度都在前进,会对彼此形成激励

架构师也需要编码

标注(黄) | 位置 2286
好的设计者必须能够卷起袖子,加入开发队伍,毫不犹豫地参与实际编程。真正的架构师,如果不允许参与编码的话,他们会提出强烈的抗议。

标注(黄) | 位置 2302
如果有一位首席架构师,他可能没有足够的时间来参与编码工作。还是要让他参与,但是别让他开发在 项目关键路径上的、工作量最大的代码。 不要允许任何人单独进行设计,特别是你自己。

知识分享

标注(黄) | 位置 2307
任何一位团队成员,只要理解某段代码的来龙去脉,就应该可以对其进行处理。如果某一段代码只有一
位开发人员能够处理,项目的风险无形中也就增加了。

标注(黄) | 位置 2332
Knowledge grows when given

标注(黄) | 位置 2348
这个过程不必局限于自己的团队。可以开设个人博客,贴一些代码和技术在上面。不一定是多么伟大的
项目,即使是一小段代码和解释,对别人也可能是有帮助

标注(黄) | 位置 2385
用问题来回答问题,可以引导提问的人走上正确的道路。 如果有人真的陷入胶着状态,就不要折磨他们 了。告诉他们答案,再解释为什么是

代码复查

标注(黄) | 位置 2426
要寻找深藏不露的程序bug,正式地进行代码检查,其效果是任何已知形式测试的两倍,而且是移除80% 缺陷的唯一已知方法

标注(黄) | 位置 2441
捡拾游戏。当某些代码编写完成、通过编译、完成测试,并已经准备签入时,其他开发人员就可以“捡拾”起这些代码开始复查。类似的“提交复查”是一种快速而非正式的方式,保证代码在提交之前是可以被接受的。为了消除行为上的惯性,要在开发人员之间进行轮换。比如,如果Joey的代码上次是由 Jane复查的,这次不妨让Mark来复查。这是一种很有效的技术。

标注(黄) | 位置 2446
结对编程。在极限编程中,不存在一个人独立进行编码的情况。编程总是成对进行的:一个人在键盘旁 边(担任 司机 的角色),另一个人坐在后面担任导航员。他们会不时变换角色。有第二双眼睛在旁边盯着,就像是在进行持续的代码复查活动,也就不必安排单独的特定复查时间。

标注(黄) | 位置 2454
还可以考虑使用诸如Similarity Analyzer或Jester这样的代码分析工具。如果这些工具产生的静态分析结果对项目有帮助,就把它们集成到持续构建中

分类: career

发表评论

电子邮件地址不会被公开。 必填项已用*标注