《程序员的职业素养之代码整洁之道》成为专业人士必读

程序员的职业素养之代码整洁之道

此处悼念1986年1月28日挑战者号航天飞机事故中丧生的七名优秀的宇航员

接下来大家带着以下问题去阅读此书《程序员的职业素养之代码整洁之道》
也可以阅读此文章 本人尽可能将书中精华总结于此文章中

• 什么是专业人士
• 软件专业人事如何行事
• 软件专业人士如何处理冲突,应对很紧的工期,如何和不讲道理里的管理人员打交道
• 软件专业人士何时应该说"不" 怎么说
• 软件专业人士如何应对压力

一 专业主义

1.1 专业主义

专业主义的精髓就在于将公司利益视同个人利益.也就是意味着担当责任

1.2 担当责任

1.3 首先不行损害之事

• 1.3.1 不要破坏软件功能
  所谓专业人士就是能对自己的犯下的错误负责的人,哪怕那些错误实际上在所难免,失误率永远不可能为零 但是你有责任让他无线接近于零
  简单的做到以下几点:
  • 尽可能的让 QA 找不出问题
  • 要确信代码正常运行
  • 自动化 QA
• 1.3.2 不要破坏结构
  成熟的专业开发人员知道 聪明的人不会为了发布新功能而破坏结构 ,结构良好的代码更灵活, 以牺牲结构为代价,得不偿失, 将来必回追悔莫及
  所有软件项目根本指导原则是:软件要易于修改

1.4 职业道德

你应该计划每周工作60个小时, 前40个小时是给雇主的,后20个小时是给自己的, 在这剩余的20个小时里 ,你应该多看书, 练习, 学习, 或者做其他能提升职业能力的事情

• 1.4.1 了解你的领域
• 1.4.2 坚持学习
  软件行业的飞速改变 意味着软件开发人员必须坚持广泛学习才不至于落伍 : 时刻记住不写代码的架构师必然遭殃,他们很快会发现自己跟不上时代了,不学习新语言的程序员同样会遭殃,他们只能眼睁睁的额看着软件业一路发展,把自己抛在后边,学不会新规矩和新技术的开发人员更可怜他们只能在日渐沦落的时候看着身边人越来越优秀
• 1.4.3 练习
  业精于勤荒于嬉
• 1.4.4 合作
  学习的第二个最佳方式就是与他人合作
• 1.4.5 辅导
  俗话说教学相长想迅速牢固的掌握某些事实和观念 最好的办法就是与你负责的人交流这些内容
• 1.4.6 了解业务领域
  每开发一个新领域项目的时候 就要了解自己开发的解决方案所对应的业务领域 如果你编写财务系统 你就应该对财务领域有了解,如果你编写旅游应用程序 那么你需要去了解旅游业
• 1.4.7 与雇主/客户保持一致
• 1.4.8 谦逊

二 说 "不"

能就是能 不能就是不能 不要说"试试看" ----尤达

专业人士应该懂得说"不" 事实上 优秀的经理人对于敢于说"不"的人总是求贤弱渴 因为只有敢于说 "不" 的人 才能真正做成一些事情

2.1 对抗角色

你的经理要求你在明天之前完成登录页面 这就是他在追求和捍卫的一个目标 那是进他的职责.如果你明知第二天之前不可能完成登录页面 嘴上却说"好的 我会试试的" 那么你就是失责了 这时候 尽职的文艺选择是说"不 . 这不可能"

2.2 高风险时刻

越是关键时刻 "不"字就越有价值
这一点应该不证自明 当公司存亡成败皆系于此时 你必须尽己所能 把最好的信息传递给你的经理 这往往意味着要说"不"

2.3 要有团队精神

有团队精神的人会频繁与大家交流 会关心队友 会竭力做到尽职尽责

• 2.3.1 试试看
  允诺"尝试" 就意味着你承认自己之前未尽全力 承认自己还有余力可施 允诺尝试意味着只要你在加把劲 还是可以达成目标的 而且这是一种表示你将再接再厉去实现的目标的承诺 因此只要你要允诺自己去尝试 你其实就是在承诺你会确保成功 这样 压力就是你来抗了 如果你的尝试 没有达到预期的效果 那就表示你失败了

三 说 "是"

3.1 承诺用语

做出承诺,要包含三个步骤

• 1 口头上说自己将会去做
• 2 心里认真对待做出的承诺
• 3 认真付诸行动

如果你能够一直信守承诺 ,大家会以为你是一名严谨负责的开发人员 在我们这行中 也是最有价值的评价了

3.2 学会如何说 "是"

和学会说 不 同样重要的是 要学会说 是

专业人员不需要对所有请求都回答"是" 不过 他们应该努力寻找创新的方法 尽可能做到有求必应 当专业人士给出肯定回答是 他们会使用正式的承诺 一确保各方能明白无误的理解承诺的内容

四 编码

4.1 做好准备

编码是一项 颇具挑战也十分累人的智力活动 相比其他类型的活动 编码要求更加聚精会神 因为在编码是你必须平衡互相牵制的多种因素
如果感到疲劳或者心烦意乱,千万不要编码 相反要找到一种方法来消除干扰 让心绪平静下来

• 4.1.1 凌晨三点写出的代码 😮(惊呆了)
  疲劳的时候 千万不要写代码 奉献精神和职业精神更多意义上指要遵循纪律原则而非长时间工作的的工作狂 要确保自己已经将睡眠,健康和生活方式调整到最佳状况,这样才能做到在每天的8小时工作时间内全力以赴

4.2 流态区

这是程序员在编写代码时会进入的一种意识高度专注 但思维视野却会收拢到狭窄的状态.在这种状态下,他们会感到效率极高;在这种状态中他们会感到"绝无错误" 因此他们一直苦苦追求进入这种状态 并经常以能在那种状态下 维持多久来衡量自我价值

4.3 阻塞

有的时候.就是死活写不出代码.我自己就曾经遇到过,也看到其他人身上遇到过这种情况,干坐在电脑前什么也写不出
这里有个简单的好的方法可以解决这个问题, 这个办法屡试不爽,既简单易行,有能够帮助你写出很多代码,那就是:找个搭档结对编程

4.4 保持节奏

软件开发是一场马拉松,而不是短跑冲刺.你无法全程一直以最快的速度冲刺来赢得比赛,只有通过保存体力和维持稳定节奏来取胜.

4.5 进度延迟

管理延迟的诀窍就是早期检测和保持透明 要根据目标定期衡量进度,使用三个考虑到多种因素的期限:乐观预估,标称预估,悲观预估

• 4.5.1 期望
  如果项目要在十天后发版 而你的常规预估是15天,你是绝对不可能完成任务的,所以不要对十天内全部完成特性开发抱有期望!这种期望会杀死整个项目,期望会毁掉项目进度表,玷污你的名声,期望会把你拖进大麻烦中.

• 4.5.2 盲目冲刺
  不要经受不住诱惑就盲目冲刺
  其实冲刺是做不到的 你无法更快的写完代码. 你无法更快的解决问题, 如果视图这么做 最终只会让自己变得更慢. 同时只能制造出一顿混乱 让其他人慢下来

• 4.5.3 加班加点
  加班确实有用, 而且有时候很有必要,有时候 通过一天工作十个小时在加上周末 你确实能够达成原本不可能的进度. 但这么做的风险也很高. 在额外加班20%的工作时间内 你其实并无法完成20%的额外工作而且,如果连续两三周都要加班工作 则加班的措施必败无疑

• 4.5.4 交付失误
  在程序员所能表现的各种不专业中 最糟糕的是明知道还没有完成任务 确宣称已经完成 这时候这只是一个撒过头的谎言,. 这就已经很糟糕了

• 4.5.5 定义"完成"
  可以通过创建一个确定定义 的''完成''标准来避免交付失误 最好的方法就是让业务分析师和测试人员创建一个自动化的验收测试,只有完全通过这些验收测试,开发任务才能算已经完成

4.6 帮助

编程绝非易事 编程很难 事实上 仅凭一己之力无法写出优秀的代码.即使你的技能格外高超,也肯定能从另外一名程序员的思考与想法中获益

4.7.1 帮助他人

因此互相帮助是每个程序员的职责所在,作为专业人士,要以能够随时帮助他人为荣

4.7.2 接受他人的帮助

如果有人向你伸出援手,要诚挚接受,心怀感激的接受帮助并诚意合作,不要死命的护住自己的地盘 拒绝别人的帮助

五 测试驱动开发(TDD)

5.1 TDD 的三项法则

• 1 在编好失败单元测试之前,不要编写任何产品代码
• 2 只要有一个单元测试失败了,就不要在写测试代码;否则无法通过编译也是一种失败
• 3 产品代码恰好能够让当前失败的单元测试成功通过即可,不要多写
  遵循这三项法则的话,大概三十秒就要运行一次代码, 先写好一个单元测试的一部分代码, 很快,你会发现还缺少一些类或函数, 所以单元测试无法编译.因此必须编写产品代码,让这些测试能够编译成功. 产品代码够用即可,然后再哎回头接着写单元测试

5.2 TDD 的优势

• 5.2.1 保证代码的确定性
• 5.2.2 降低缺陷注入率
• 5.2.3 勇气
  这是 TDD 强大之处, 拥有一套值得信赖的测试,便可完全打消对修改代码的全部恐惧, 当看见糟糕的代码是,就可以放手整理, 代码会变的具有可塑性,你可以放心打磨出简单满意的结果
• 5.2.4 文档
  单元测试即是文档, 他们描述了系统设计的最底层设计细节,他们清晰正确,以读者能够理解的语言写成, 并且形式规整可以运行, 他们是最好的底层文档.
  *5.2.5 专业人士的选择
  本节可以归结一句话, TDD 是专业人士的选择.他是一项能够提升代码确定性,给程序员鼓励,降低代码缺陷率,优化文档和设计的原则.对 TDD 的各项尝试表明,不使用 TDD 就说明你可能还不够专业

5.3 TDD 的局限

尽管 TDD 有诸多优点,遵循这三个法则并不能担保一定会带来上述好处, 及时做到了测试先行, 仍有可能写出糟糕的代码.如果遵循某项法则会弊大于利,专业的开发人员就当然不会选用它

六 练习

专业人士都需要通过专门训练提升自己的技能
此节主要讲的就是要不断地练习 就像弹钢琴一样, 要想自如弹奏,乐手需要反复的弹奏音节,各种练习曲,重复的节奏,直到烂熟于心.要相信10000小时定律

七 验收测试(沟通的重要性)

专业开发人员既要做好开发,也要做好沟通

7.1 需求的沟通

PM 和 RD 之间最常见的沟通就是关于需求了的 PM 描述他们认为自己需要的东西, RD 按照自己理解的业务放表达的需求来开发, 至少理论上是这样的,但是在现实里 关于需求的沟通是极其困难的,其中会出现各种问题

• 7.1.1 过早的精细化
  PM 和 RD 都容易陷入一个陷阱, 即过早进行精细化,
  • 1 不确定原则, 任何一个需求总是不确定 来回改变
  • 2 预估焦虑 评估可以额而且必须基于不那么精确地需求,这些评估只是评估而已
• 7.1.2 迟来的模糊性
  专业的 RD 也包括 PM 必须确认,需求中没有任何不确定因素

7.2 验收测试

• 7.2.1 "完成"的定义
  身为专业开发人员, 我们经常面对的不确定因素之一就是"完成"的各种说法,开发人员说他已经完成任务了,太想表达什么意思呢,是指开发人员已经有足够的信心吧这项功能部署到生产系统,还是他可以准备 QA 程序,或者他已经写完了代码并且跑通了,但还没有真正测试过
• 7.2.2 沟通
  验收测试的目的是沟通澄清,精确化. 开发方,业务方,测试方对验收测试达成共识,大家都能明白系统的行为将会是怎样 各方都应该记录这种准确的共识, 在专业开发人员看来, 与业务方,测试方协同工作,确保大家都明白要做的是什么,是自己的责任
• 7.2.3 自动化
  专业程序员会避免手动测试,相比手动测试来说,自动化测试成本非常低, 让人手工执行测试脚本不划算.专业的开发人员认为 实现验收测试的自动化是自己的责任
• 7.2.4 额外工作
  写这些测试并不是什么额外的工作,这些测试是为了确定系统的各项指标符合要求,. 确定细节指标的目的,是为了确定系统的指标,只有确定这些系统的指标,我们程序员才能确知完成, 只有确认这些指标, 业务方才能确认他们花钱开发的系统确实满足了需求,只有确认这些指标, 才可以真正做到自动化测试, 所以不要把这些测试看做额外的工作,而应当看成节省时间和金钱的办法.
• 7.2.5 验收测试什么时候写,有谁来写
  在理想状态下, PM和 QA 会协作编写 这些测试, 程序员来检查测试之间是否有冲突或矛盾. 但实际上 业务方通常没有时间 或者有时间也难以达到所需要的细致程度 所以他们通常会把测试交给业务分析员,QA 甚至是开发人员.如果只能有开发人员来写测试,应当确保测试
  的程序员与开发测试功能的程序员不是同一个人
• 7.2.6 开发人员的角色
  开发人员有责任吧验收测试与系统联系起来,然后让这些测试通过
• 7.2.7 测试的协商与被动推进
  身为专业开发人员, 与编写测试的人协商并改进测试是你的责任.决不能被动接受测试
• 7.2.8 验收测试和单元测试
  单元测试是程序员写给程序员的 他是正式的设计文档,描述了底层结构及代码的行为, 关心单元测试的结果是程序员而不是业务人员
  验收测试是业务方写给业务方的 他们是正式的需求文档 描述了业务放认为 系统应该如何运行.关心验收测试结果的是业务方和程序员

7.3 结论

要解决开发方和业务方的问题,我所知道的唯一的解决办法就是编写出无可挑剔的需求文档

八 测试策略

每个专业的开发团队都需要一套好的测试策略

8.1 QA 应该找不到任何错误

我们努力的目标应该是让 QA 应该找不到任何错误

8.2 自动化测试金字塔

拥有一套单元测试和验收测试的 同事 还需要更高层次的测试,这样 QA 才找不出任何错误 如下图

image.png

• 8.2.1 单元测试
  在金字塔底部就是单元测试,这些单元测试作为持续集成的一部分来运行,用以确保程序员的代码意图没有遭到破坏
• 8.2.2 组件测试
  组件测试是验收测试的一种 他们针对系统的各个组件而编写的 组件的测试差不多可以覆盖系统的一半
• 8.2.3 集成测试
  集成测试只对那些组件很多的大型系统才有意义,集成测试一般有系统架构师或主设计师编写
• 8.2.4 系统测试
  这个测试是针对整个完毕的系统进行的自动化测试,是最终的集成测试,这个测试中 ,应该包含吞吐率测试和性能测试
• 8.2.5 人工探索式测试
  这些测试的意图 是要在验证预期行为的时候,探索系统预期之外的行为.为了达到这个目的,需要人类智慧的介入,需要人类的创新能力

九 时间管理

八小时其实非常短暂, 只有480分钟 28800秒,身为专业开发人员,你肯定希望能在这短暂的时间里尽可能高效的工作,取得尽可能多的成果

9.1 会议

关于会议 有两条真理:
(1) 会议是必需的
(2) 会议浪费了大量的时间

专业的开发人员同样清楚会议的高昂成本, 他们同样清楚自己的时间是宝贵的,他们同样需要时间来写代码,来处理日程表上的事物,所以 如果会议没有现实且显著 的成效,他们会主动拒绝

• 9.1.1 拒绝
  受到邀请的会议没有必要全部参加, 参加的会议太多,其实只能证明你不够专业.你应该理智的使用时间,所以 必须要谨慎选择, 应当参加那些会议, 礼貌拒绝那些会议 好的领导一定会主动维护你拒绝出席的决定,因为她和你一样关心你的时间

• 9.1.2 离席
  重要的是,你应该明白, 继续待在会议室里是浪费时间; 继续参加对你没有意义的会议是不专业的行为, 因为你有责任合理分配老板给你的时间和金钱, 所以选择一个合适的机会商量如何离席,并非不专业的做法

• 9.1.3 确定议程 和 目标
  为了合理使用与会者的时间,会议应当有清晰的议程, 确定每个议程所花的时间以及确定的目标

• 9.1.4 立会
  让立会简洁

• 9.1.5 迭代计划会议
  迭代计划会议用来选择在下一轮迭代中实现的开发任务, 在会议召开前必须完成两项任务: 评估可选择任务的开发时间, 确定这些任务的业务价值, 如果组织的足够好, 验收和组件测试也应当在会议召开前完成,或者至少要有概略方案

• 9.1.6 迭代回顾和 Demo 演示
  此类会议用来让业务方可以看到最新工作的成果的 DEmo 这类会议可能浪费很多时间, 所以不妨在最后一天下班前45分钟召开, 花20分钟来回顾, 花25分钟来演示

• 9.1.7 争论/反对
  凡是不能再5分钟内解决的 争论, 都不能靠辩论来解决 因为争论之所以话这么长时间,就是因为各方都拿不出足够有力的证据, 所以应当尽量控制争论的时间

9.2 注意力点数

编程是需要持续投入精力和注意力的智力活动.注意力是稀缺的资源,它类似魔力点数,如果你用光了自己的注意力点数, 必须花一个小时或更多的时间做不需要注意力的事情,来补充他

• 9.2.1 睡眠
  睡眠的重要性怎么强调都不为过,专业的开发人员会安排好他们的睡眠, 保证清晨有饱满的注意力点数去上班

• 9.2.2 咖啡因
  毋庸置疑,对有些人来说,适量的咖啡因可以帮他们更有效的使用注意力点数

• 9.2.3 恢复
  在你不集中注意力的时候,注意力点数可以慢慢恢复,漫长的一段长路,与朋友聊天, 看看窗外, 都有助于恢复注意力点数

• 9.2.4 肌肉注意力

肌肉注意力有助于改善心智注意力, 而且不仅仅是简单的恢复, 我发现定期培训肌肉和注意力,可以提升心智注意力的上限. 比如我自己 我就会经常的跑步锻炼身体

• 9.2.5 输入与输出
  关于注意力, 我知道的另一个重点是平衡输入与输出, 编程是一项创造性劳动, 我发现如果能接触到其他人的创造思维,我的创造力也最旺盛,

9.3 时间拆分和番茄工作法

其基本思想很简单, 把厨房用的计时器(通常他们很想番茄) 设定到25分钟, 倒计时期间不要让任何事情干扰你的工作

9.4 死胡同

所有软件开发者都要遇到死胡同 比如你做了一个决定,选择了走不通的技术道路.你对这个绝地个越是坚持,浪费的时间就越多, 专业人员不会执拗有不让放弃也无法绕开的注意, 他们会保持开放的头脑来听取其他意见

9.5 泥潭

比死胡同更糟的是泥潭,泥潭会减慢你的速度,专业开发人员对泥潭的恐惧远远大于死胡同.他们会时刻留神显露出来的泥潭, 然后运用各种努力,尽早尽快的脱身,

9.6 结论

专业的开发人员会用心管理自己的时间和注意力, 他们知道优先级错乱的诱惑, 他们也珍视自己的声誉. 所以会抵制优先级错乱, 他们永远有多种选择,永远敞开心扉听取其他解决方案, 他们从来不会执拗于某个无法放弃的解决方案, 他们也时刻警惕着正在显露的泥潭,一旦看清楚 就会避开.

10 预估

预估是软件开发人员面对的最简单也是最可怕的活动之一了,预估影响到的商业价值巨大关乎声誉吗预估是也业务人员和开发人员之间最重要的障碍, 横亘在双方之间的种种不信任几乎都由他引发

10.1 什么是预估

问题在于 不同的人对预估不同的看法.业务方觉得预估就是承诺, 开发方认为预估就是猜测, 两者相差迥异

• 10.1.1 承诺
  承诺是必须做到的 如果你承诺在哎某天做成某件事, 就必须按时完成, 即便他意味着你必须每天工作12个小时, 放弃周末的休假, 也不得不如此, 既然承诺了,就必须要实现

• 10.1.2 预估
  预估是一种猜测, 预估无关声誉,不幸的是,大多数软件开发人员都很不擅长预估

• 10.1.3 暗示性承诺
  专业开发人员能够清楚地区分预估和承诺, 只有在确切知道可以完成的前提下, 他们才会给出承诺, 此外, 他们也会小心避免给出暗示性的承诺, 他们会尽可能清楚的说明预估的概率分布, 这样主管就可以作出合适的计划了

10.2 PERT 计划评审计划

简单的 PERT 计算说明了一种避免乐观预估的合理方法, 不管尝试加快进度的压力有多大, 专业开发人员都应当谨慎的设定合理的预估值

10.3 结论

专业的开发人员懂得如何为业务人员提供可信的预估结果,以便做出计划,如果做不到或者不确定能做到,专业开发人员不会给出承诺
一旦做出了承诺, 就会提供确定的数字, 按时兑现, 但是在大多数情况下, 他们都不会做这种承诺, 而是提供概率预估,来描述期望的完成时间及可能的变数

11 压力

即使有巨大的压力, 专业的开发人员也会冷静果断. 尽管压力不断增大, 他仍然会坚守所受的训练和纪律, 他知道这些是他赖以战胜有最后期限和承诺所带来的压力感的最好方法

11.1 避免压力

在压力下保持冷静的最好方式,便是规避会导致压力的处境, 规避的方式也许无法完全检出压力, 但是可以大大降低压力并缩短高压力期的时间

• 11.1.1 承诺
  之前第十章已经说过,我们应该避免对没有把握能够完成的最后期限作出承诺 避免给自己带来不可估量的后续问题
• 11.1.2 把持整洁
  让系统,代码和设计尽可能整洁, 就可以避免压力, 这并非是说我们要花无穷无尽的时间去清理代码, 而只是说不要容忍混乱, 混乱会降低速度, 导致工期延误, 承诺失信, 因此,要尽力保持输出成果整洁干净
• 11.1.3 危机中的纪律
  当困境临降时, 也不要改变工作方式, 如果你遵守的纪律原则是工作的最佳方式, 那么即使在深度危机中也要坚决秉承这些纪律原则

11.2 应对压力

• 11.2.1 不要惊慌失措
  正确对待压力, 放松下来,对问题深思熟虑,努力寻找可以带来最好结果的路径, 然后沿着那条路径一合理稳定的节奏前进

• 11.2.2 沟通
  多多沟通,让你的团队和主管知道你正深陷困境之中, 告诉他们你所制定的走出困境的最佳计划, 请求他们支援,避免产生惊恐,没有东西比惊恐更令人愤怒和市区理性,惊恐会让你的压力增大十倍

• 11.2.3 依靠你的纪律原则
  当事情十分困难的时候,要坚信你的纪律原则,他们可以指引你度过高压期

11.3 结论

应对的诀窍在于,能回避压力是尽可能回避,当无法回避是则勇敢直面压力, 可以通过慎重承诺, 遵循自己的纪律原则,保持整洁等来回避压力.直面压力时, 则要保持冷静, 与别人多多沟通, 坚守自己的原则和纪律 并寻求他人的帮助.

12 协作

大多数软件都是由团队开发出来的,当团队成员能够十分专业的互相协作时, 整个团队是最为高效的, 单打独斗与游离于团队之外都是不专业的表现

12.1 程序员与人

我们并非是因为喜欢和其他人一起工作才选择做程序员的, 我们都认为人人际关系难以应付而且毫无规律.编程用的机器则整洁,行为也可预见,如果可以一个人待在房间里数个小数沉浸在一些真正有趣的问题上, 那将会是最开心的时光

• 12.1.1 程序员与雇主
  专业的程序员的首要职责是满足雇主的需求.这意味着要和你的经理们,业务分析师门,测试工程师门,和其他团队成员很好的协作, 深刻理解业务目标, 这并不是说你必须要成为业务方面的老学究,而是说你需要理解手上正在编写的代码的业务价值是什么,了解雇你的企业将如何从你的工作中获得回报

• 12.1.2 程序员与程序员
  程序员之间很难密切合作,这就会带来不小的问题

  • 代码个体所有
    不正常的团队最糟糕的情况是,每个程序员在自己的代码周边筑起一道高墙, 拒绝 让其他程序员接触到这些代码
  • 2 协作性的代码共有权
    专业的开发人员是不会阻止别人修改代码的, 他们不会再代码上构造所有权的藩篱,而是尽可能多的合作, 他们通过合作来达到学习的目的

12.2 结论

也许我们不是因为通过编程可以和人互相协作才选择从事这项工作的, 但真不走运,编程就意味着与人协作.我们需要和业务人员一起工作,我们之间也需要互相合作.
如果我们真想终生能以编程度日,那么一定要学会交流 ,和大家交流

13 团队和项目

小项目该如何实施? 如何给程序员分派? 大项目有该如何实施?

13.1 只是简单混合么

让一个程序员把一半的时间投入到项目 A 中,把其余时间投入到项目 B 中,这并不可行,尤其是当这连个项目的项目经理不同,业务分析师不同,程序员不同,测试人员不同是,更不可行.这不是一个团队,只是从榨汁机中榨出的混合物而已

• 13.1.1 有凝聚力的团队

形成团队是需要时间的,团队成员需要先建立关系,他们需要学习如何互相协助,需要了解彼此的癖好,强项,弱项,最终才能凝聚成团队,
有凝聚力的团队确实有些神奇之处, 他们能够一起创造奇迹,他们互为知己,能够替对方着想, 互相支持, 激励对方拿出自己最好的表现,他们攻无不克

• 13.1.2 如何管理好有凝聚力的团队
  每个团队都有自己的速度,团队的速度,即是指在一定时间段内团队能够完成的工作量,有些团队使用每周点数来衡量自己的速度,其中"点数"是一种关于复杂度的单位.
  管理人员可以依据团队的平均速度来合理分配每周工作的点数

13.2 结论

团队比项目更难构建 .因此 组建稳健的团队,让团队在一个又一个项目中整体移动共同工作是较好的做法, 并且 团队也可以同时承接多个项目, 在组建团队是, 要给予团队充足的时间, 让他们形成凝聚力, 一直共同工作,成为不断交付项目的强大引擎

一周的零碎时间将此书读完并整理出每节重要内容,书中更多的是结合公司中实际例子来说明每一个点的重要性,希望每个开发都能成为像 bob 大叔一样厉害的人