专业主义

笑吧，科廷，老伙计。这是上帝，或者也可以说是命运或者自然，跟我们开的一个玩笑。不过，不管这家伙是谁或是什么，他真幽默！哈哈！

01 | 清楚你要什么

02 | 担当责任

03 | 不行损害之事

不破坏软件功能

不破坏结构

04 | 职业道德

了解你的领域

• 设计模式
  • GOF书中的24种设计模式
• 设计原则
  • SOLID原则
  • 组件设计原则
• 方法
  • XP
  • Scrum
  • 精益
  • 看板
  • 瀑布
  • 结构化分析
  • 结构化设计
• 实践
  • 测试驱动开发
  • 面向对象设计
  • 结构化编程
  • 持续集成
  • 结对编程
• 工件
  • UML图
  • DFD图
  • 结构图
  • Petri网络图
  • 状态迁移表
  • 流程图
  • 决策表

坚持学习

.net到java，java到ruby，c到lisp

Prolog和Forth

练习

10分钟kata练习

合作

一起编程、一起练习、一起设计、一起计划

辅导

了解业务领域

每位开发人员有义务了解自己开发的解决方案所对应的业务领域

与雇主或客户保持一致

谦逊

说“不”

能就是能，不能就是不能。不要说“试试看”。

01 | 对抗角色

02 | 高风险时刻

03 | 团队精神

试试看

• 许诺尝试，意味着你承认之前未尽全力，趁人自己还有余力可施
• 许诺尝试，意味着你承诺你会确保成功
• 如果没有保留，没有新方案，不要轻易许诺尝试，否则你在说谎

消极对抗

• 灾难降临，证明自己某市某刻给领导的建议，撇去自己的责任，放任领导走向悬崖，是一种消极对抗

04 | 说“是”的成本

05 | 如何写出好代码

说“是”

01 | 承诺用语

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

“天哪，我真该减减肥了？”但你知道其实他还会是老样子，什么改变都不会发生。

识别缺乏承诺的征兆

透露“缺乏承诺”的用语：

• 需要、应当
• 希望、但愿
• 让我们
• 我要

真正的承诺听起来是怎样的

我将在...之前...

1. 只能承诺自己能完全掌控的事
2. 如果最终目标依赖他人，那就应该采取些行动，接近最终目标
3. 没预料到的情况，一定要及时说明，越快越好

02 | 学习如何说“是”

“试试”的另一面

别说“试试”，真实反应自己的情况

编码

“信心”与“出错感知”

01 | 做好准备

1. 代码必须能够正常工作
2. 代码能够帮你解决客户提出的问题
3. 代码必须要能和现有系统结合的天衣无缝
4. 其他程序员必须能读懂你的代码

如果感到疲劳或者心烦意乱，千万不要编码

凌晨3点写出的代码

疲劳的时候，千万不要写代码

焦虑时写下的代码

• 私人时间解决私人问题
• 先安静，再工作

02 | 流态区

高效率状态：流态

避免进入流态区

音乐

中断

礼貌的表现出乐于助人的态度才是专业的态度

03 | 阻塞

• 找一个搭档结对编程，和别人一起工作时，会发生一种生理上的变化？
• 结对的主要好处就是能够重新激活思维

04 | 调试

05 | 保持节奏

保存好自己的精力和创造力

知道何时应该离开一会儿

开车回家路上

洗澡

回家，吃顿好的，上床睡觉，清晨洗个澡2333

06 | 进度延迟

做好3个评估：

• 乐观预估
• 标称预估
• 悲观预估

期望

不要让其他人对预估抱有希望

盲目冲刺

坚持维护你的估算

加班加点

没有后备语言，不要同意接受加班方案

交付失误

07 | 帮助

帮助他人

接受他人的帮助

辅导

测试驱动开发

TDD：测试驱动开发

XP：极限编程

对任何新鲜事物，最好不要马上批驳

01 | 此事已有定论

TDD绝不仅仅是一种用于缩短编码周期的简单技巧

• 此事已有定论！
• 争论已经结束
• GOTO是有害的
• TDD确实可行

02 | TDD的三项法则

• 编好失败单元测试之前，不要编写任何代码
• 只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况
• 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写

测试代码之匹配于产品代码，就如抗体之匹配于抗原一样

03 | TDD的优势

确定性

缺陷注入率

勇气

专业程序员怎么会容忍代码持续劣化呢？

文档

设计

专业人士的选择

• 提升代码确定性
• 给程序员鼓励
• 降低代码缺陷率
• 优化文档和设计的原则

04 | TDD的局限

练习

01 | 引子

10的22次方

我们有了更好的工具，更好的语言。可是，语句的本质并没有随时间而改变。我们真正打交道的东西，40多年来没有多少改变

转变

02 | 编程柔道场

卡塔

武术里，卡塔是一套设计好的、用来模拟搏斗一方的招式。目标则是要逐步把整套招式练习到纯熟。习武者努力训练自己的身体来熟悉每一招，把它们连贯成流畅的套路。

收录编程卡塔的网站：

• http://katas.softwarecraftsmanship.org
• http://codekata.pragprog.com

瓦萨

瓦萨是两个人的卡塔

自由练习

03 | 自身经验的拓展

开源

为开源项目贡献代码

java给rails做点贡献，c++给python做点贡献

关于练习的职业道德

04 | 结论

练习的时候你是赚不到钱的，但是练习之后，你会获得回报，而且是丰厚的回报

验收测试

01 | 需求的沟通

客户对功能的设想，经不起电脑前真刀真枪的考验

过早精细化

1. 不确定原则

• 每次你向业务方向展示一项功能，它们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法

2. 预估焦虑

• 需求是一定会变化的，所以追求那种精确性是徒劳的

02 | 迟来的模糊性

02 | 验收测试

验收测试的目的在于确定需求已经完成

“完成”的定义

沟通

自动化

自动化验收测试工具：

• FitNesse
• Cucumber
• cuke4duke
• robot framework
• Selenium

额外工作

验收测试什么时候写，由谁来写

开发人员的角色

测试的协商与被动推进

验收测试和单元测试

真正的价值不在测试上，而是在具体指标上

图形界面及其他复杂因素

GUI与业务逻辑解耦

持续集成

03 | 结论

解决开发方与业务方沟通的问题，唯一有效的办法是编写自动化测试

测试策略

01 | 目前：QA找不到任何错误

QA也是团队的一部分

需求规约定义者

QA编写针对极端情况、边界状态和异常路径的测试

特性描述者

02 | 自动化测试金字塔

1. 单元测试

• 由程序员实现，在最低层次上定义系统，确保程序员代码意图没有被破坏

2. 组件测试

• 针对系统各个组件进行车市，对其中的业务规则进行验收测试，由QA和开发人员编写，开发人员进行辅助，主要测试成功路径的情况及部分明显的极端情况、边界状态和可选路径

3. 集成测试

• 测试组件之间是否能正常通信，主要测试组件之间是否正常连接，可以进行性能测试和吞吐率测试，一般由系统架构师或者主设计师来实现

4. 系统测试

• 测试系统是否正确组装完毕，系统各个部件之间是否能够正确交互，应包含吞吐率测试和性能测试，由系统架构师和技术负责人编写

5. 人工探索式测试

• 验证预期行为时，探索系统预期之外的行为

03 | 结论

时间管理

01 | 会议

1. 会议是必需的
2. 会议浪费了大量的时间

拒绝

受到邀请的会议没必要全部参加，为时间负责的只有自己

领导最重要的职责之一，就是帮你从某些会议中脱身，因为他和你一样关心你的时间

离席

如果会议让人厌烦，就离席，如果会议是在浪费你的时间，就应当想一个礼貌的方式退出来

确定议程和目标

立会

1. 我昨天干了什么
2. 我今天打算干什么
3. 我遇到了什么问题

每个问题时间有限，发言时间有限

迭代会议计划

迭代回顾和Demo展示

争论与反对

唯一出路，用数据（事实）说话

02 | 注意力点数

睡眠

咖啡因

• 早上一杯浓咖啡
• 中午一罐无糖可乐

恢复

肌肉注意力

提升肌肉注意力，继而提升心智注意力

输入与输出

03 | 时间拆分与番茄工作法

04 | 要避免的行为

优先级错乱：提高某个任务的优先级，之后就有借口推迟真正的急迫任务。

05 | 死胡同

坑法则：如果你掉进了坑里，别挖。

06 | 泥潭

07 | 结论

最糟糕的事情，莫过于看到一群同志徒劳拼命的工作，结果却陷入越来越深的泥潭

预估

01 | 什么是预估

承诺

如果你被要求承诺做自己不确定的事情，那么就应当坚决拒绝

预估

墨菲定律说，如果可能出错，那么一定会出错

PERT

• 乐观预估
• 标称预估
• 悲观预估

02 | 预估任务

1. 亮手指
2. 规划扑克
3. 关联预估
4. 三元预估

04 | 大数定律

把大任务分成许多小任务，分开预估在总和

压力

高质量而不是愚蠢的劳作来享受自己的职业生涯

01 | 避免压力

承诺

保持整洁

脏乱只会导致缓慢

危机中的纪律

当困难降临时，也不要改变行为

02 | 应对压力

不要惊慌失措

沟通

依靠你的纪律原则

当事情十分困难时，要坚信并坚持你的原则

寻求帮助

协作

01 | 程序员与人

程序员与雇主

程序员与程序员

1. 代码个体所有
2. 协作性的代码共有权
3. 结对

02 | 小脑

03 | 结论

编程意味着你就要和别人合作，一定要学会交流

团队与项目

01 | 只是简单的混合吗

有凝聚力的团队

• 7名程序员
• 2名测试人员
• 2名分析师
• 1名项目经理

1. 发酵期
2. 团队和项目，何者为先

• 按照项目来构建团队，永远不可能有凝聚力

3. 管理有凝聚力的团队

项目承包人的困境

02 | 结论

团队比项目更难构建。要给予团队充足的时间，让他们形成凝聚力，一直共同工作，成为不断交付项目的强大引擎

辅导、学徒期与技艺

01 | 失败的学位教育

在大学里完全可以蒙混过关，混的一纸文凭，其实什么都不懂

02 | 辅导

Digi-Comp I

ECP-18

非常规辅导

艰难的锤炼

03 | 学徒期

软件学徒期

1. 大师
2. 熟练工
3. 学徒或者实习生

现实情况

03 | 技艺

觉者觉人

首先你自己要成为能工巧匠，向别人展示你的技艺

附录

01 | 工具

版本控制工具

• git

IDE

• vi
• emacs
• intelliJ
• TextMate

问题跟踪

• Pivotal Tracker
• Lighthouse
• wiki

持续构建

• Jenkins

单元测试工具

• Java：JUnit
• .Net：NUnit
• Clojuer：Midje
• C/C++：CppUTest

组件测试工具

• Fitness
• RobotFX
• Green Pepper
• Cucumber
• JBehave