代码整洁之道·程序员的职业素养读书笔记

专业主义

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

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. 不确定原则
  • 每次你向业务方向展示一项功能,它们就获得了比之前更多的信息,这些新信息反过来又会影响他们对整个系统的看法
  1. 预估焦虑
  • 需求是一定会变化的,所以追求那种精确性是徒劳的

02 | 迟来的模糊性

02 | 验收测试

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

“完成”的定义

沟通

自动化

自动化验收测试工具:

  • FitNesse
  • Cucumber
  • cuke4duke
  • robot framework
  • Selenium

额外工作

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

开发人员的角色

测试的协商与被动推进

验收测试和单元测试

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

图形界面及其他复杂因素

GUI与业务逻辑解耦

持续集成

03 | 结论

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

测试策略

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

QA也是团队的一部分

需求规约定义者

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

特性描述者

02 | 自动化测试金字塔

  1. 单元测试
  • 由程序员实现,在最低层次上定义系统,确保程序员代码意图没有被破坏
  1. 组件测试
  • 针对系统各个组件进行车市,对其中的业务规则进行验收测试,由QA和开发人员编写,开发人员进行辅助,主要测试成功路径的情况及部分明显的极端情况、边界状态和可选路径
  1. 集成测试
  • 测试组件之间是否能正常通信,主要测试组件之间是否正常连接,可以进行性能测试和吞吐率测试,一般由系统架构师或者主设计师来实现
  1. 系统测试
  • 测试系统是否正确组装完毕,系统各个部件之间是否能够正确交互,应包含吞吐率测试和性能测试,由系统架构师和技术负责人编写
  1. 人工探索式测试
  • 验证预期行为时,探索系统预期之外的行为

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. 团队和项目,何者为先
  • 按照项目来构建团队,永远不可能有凝聚力
  1. 管理有凝聚力的团队

项目承包人的困境

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

你可能感兴趣的:(代码整洁之道·程序员的职业素养读书笔记)