代码整洁之道-程序员的职业素养
2025-02-10 15:40:14 0 举报AI智能生成
《代码整洁之道-程序员的职业素养》是罗伯特·C. 马丁（Uncle Bob）继其经典著作《代码整洁之道》之后的又一力作，专注于程序员行为规范和专业发展。本书不仅关注代码质量，更强调程序员个人和团队的职业素养，致力于引导开发者形成高效、负责任的工作习惯，以维护软件项目的健康性和长远发展。书中详述了代码的美感、编程的哲学，以及如何在不断变化的IT行业中持续成长。作者结合多年的经验，提出了一系列实践建议和最佳实践，旨在培养程序员的专业精神，提升团队的协作效能。《代码整洁之道-程序员的职业素养》是每个追求卓越软件开发者的必读之作，同时也是计算机科学教育和职业培训的重要参考书籍。
作者其他创作
大纲/内容
说"不"
能就是能，不能就是不能，不要说‘试试看’
对抗角色
高风险时刻
要有团队精神
说‘是’的成本
如何写出好代码
说"是"
承诺用语
做出承诺包含三个步骤
口头上说自己将会去做
心里认真对待做出的承诺
真正付诸行动
识别“缺乏承诺”的征兆
需要/应当
希望/但愿
让我们
真正的承诺听起来是怎样的
我将在...之前...
学习如何说"是"
“试试”的另一面
坚守原则
测试驱动开发
TDD的三项法则
在编好失败单元测试之前，不要编写任何产品代码
只要有一个单元测试失败了，就不要再写测试代码。无法通过编译也是失败情况
产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写
TDD的优势
确定性
缺陷注入率
勇气
文档
单元测试即是文档，描述了系统的最底层设计细节
设计
测试先行，促使你做出松耦合的设计
专业人士的选择
TDD的局限
练习
编程柔道场
卡塔
逐步练习已达到纯熟
瓦萨
自由练习
自身经验的扩展
开源
关于练习的职业道德
用自己的时间来练习
专业人士都需要练习
验收测试
需求的沟通
过早精细化
不确定原则
预估焦虑
迟来的模糊性
验收测试
“完成”的定义
沟通
自动化
额外工作
验收测试什么时候写，谁来写
业务方和QA协作编写测试，程序员检查合理性
功能执行完成的前几天
开发人员的角色
测试的协商与被动推进
验收测试和单元测试
验收测试不是单元测试，单元测试是程序员写给程序员的，验收测试是业务方写给业务方的
图形界面及其他复杂因素
持续集成
失败立刻终止
测试策略
QA应该找不到任何错误
QA也是团队的一部分
需求规约定义者
业务人员定义正常路径的测试
QA编写针对极端情况，边界状态和异常路径的测试
自动化测试金字塔
单元测试
组件测试
集成测试
系统测试
人工探索测试
预估
什么是预估
业务方觉得预估是承诺
开发方认为预估就是猜测
承诺
承诺是必须做到的
预估
预估是一种猜测
PERT
三元分析法
O：乐观预估
N:标称预估
P:悲观预估
期望完成时间μ=（O+4N+P）/6
标准差σ=（P-O）/6
总标准差=各个任务的标准差平方之和的平方根
预估任务
德尔菲法
亮手指
大家必须同时亮手指
规划扑克
关联预估
三元预估
大数预估
把大任务分成许多小任务，分开预估再加总
团队与项目
有凝聚力的团队
发酵期
成功克服个体差异，默契配合，彼此信任，
形成真正有凝聚力的团队，是需要一些时间的
形成真正有凝聚力的团队，是需要一些时间的
团队和项目，何者为先
专业的开发组织会把项目分配给已形成凝聚力的端对，
而不会围绕着项目来组件团队
而不会围绕着项目来组件团队
团队比项目更难构建。组件稳健的团队，
让团队在一个又一个项目中整体移动共同工作是较好的做法
让团队在一个又一个项目中整体移动共同工作是较好的做法
辅导、学徒期与技艺
失败的学位教育
医生的辅导体系
技艺是工匠所持有的精神状态
技艺的模因中包含着价值观、原则、技术、态度、正见
技艺模因经由口口相传和手手相承而来，
需要由资深人士向年轻学徒殷勤传授，然后再在学徒之间相互传播
需要由资深人士向年轻学徒殷勤传授，然后再在学徒之间相互传播
专业主义
清楚你要什么
担当责任
首先，不行损害之事
不要破坏软件功能
让QA找不出任何问题
要确信代码正常运行
自动化QA
不要破坏结构
软件要易于修改
你必须能让修改不必花太高代价就可以完成
如果你希望自己的软件灵活可变，那就应该时常修改它
职业道德
职业发展是你自己的事
雇主没有义务确保你在职场能够立于不败之地，
也没义务培训你，送你参加各种会议或者给你买各种书籍充电
也没义务培训你，送你参加各种会议或者给你买各种书籍充电
了解你的领域
必须精通的事项
设计模式。必须能描述GOF书中的全部24种设计模式，
同时还要有POSA书中的多数模式的实战经验
同时还要有POSA书中的多数模式的实战经验
设计原则。必须了解SOLID原则，而且要深刻理解组件设计原则
方法。必须理解XP，scrum，精益，看板，瀑布，结构化分析及结构化设计
实践。必须掌握测试驱动开发，面向对象设计，结构化编程，持续集成和结对编程
工件。必须了解如何使用UML图，DFD图，结构图，
Petri网络图，状态迁移图表，流程图和决策图
Petri网络图，状态迁移图表，流程图和决策图
坚持学习
练习
合作
辅导
了解业务领域
与雇主/客户保持一致
谦逊
如果真遇到挫折，最好的办法就是——一笑了之
编码
做好准备
平衡互相牵制的多种因素
代码必须能正常工作
代码必须能帮助你解决客户提出的问题
代码必须能喝现有系统结合的天衣无缝
其他程序员必须能读懂你的代码
凌晨3点写出的代码
焦虑时写下的代码
流态区（高效率状态）
避免进入流态区（浅层冥想状态，为了追求速度，理性思考能力会下降）
音乐——消耗宝贵的脑力资源，带领他们进入流态区
中断
结对、TDD可以帮助维护中断处的上下文
中断无法避免，礼貌地表现出乐于助人的态度才是专业的态度
阻塞
解决方法
找一些其他的事情干
找一个搭档结对编程
创造性输入
“创造性输出”依赖于“创造性输入”
调试
采用TDD降低调试时间
保持节奏
软件开发是一场马拉松，而不是短跑冲刺
保存好自己的精力和创造力
知道何时应该离开一会
开车回家路上
洗澡
进度延迟
多种因素的期限
乐观预估
标称预估
悲观预估
期望
盲目冲刺
加班加点
交付失误
明知还没完成任务却宣称已经完成
定义“完成”
通过确切的完成标准来避免交付失误
业务分析师和测试人员创建自动化的验收测试，
只有完全通过验收测试开发任务才算完成
只有完全通过验收测试开发任务才算完成
帮助
编程并非易事
帮助他人
接受他人的帮助
辅导
时间管理
会议
两条真理
会议是必须的
会议浪费了大量的时间
拒绝
离席
确定议程与目标
立会（每日站会）
每人回答3个问题
我昨天干了什么？
我今天打算干什么？
我遇到了什么问题？
每个问题回答时间不要超过20秒，每人的发言不要超过1分钟
迭代计划会议
难度最大的会议
节奏要足够的快，简明扼要的讨论候选任务，决定选择还是放弃
每个任务上花的时间应该限制在5-10分钟
迭代回顾和DEMO展示
迭代的末尾召开
可以在迭代的最后一天下班前45钟召开，20分钟回顾，25分钟演示
争论/反对
凡是不能在5分钟内解决的争论，都不能靠辩论解决
注意力点数
睡眠
咖啡因
恢复
肌肉注意力
输入与输出
时间拆分和番茄工作法
要避免的行为
优先级错乱
死胡同
坑法则：如果你掉进坑里，别挖
泥潭
比死胡同更糟的是泥潭
压力
避免压力
承诺
应当避免对没有把握能够达成的最后期限做出承诺
保持整洁
不会为了快点前进而乱来
危机中的纪律
观察自己再危机时刻中的反应，就可以了解自己的信念
子当危机降临时，也不要改变行为
应对压力
不要惊慌失措
正确应对压力
沟通
让你的团队和主管知道你正深陷困境之中。
告诉他们你所指定的走出困境的最佳计划，请求他们的志愿和指引
告诉他们你所指定的走出困境的最佳计划，请求他们的志愿和指引
依靠你的纪律原则
寻求帮助
寻找结对编程的伙伴。帮助别人走出困境
协作
一定要学会交流，和大家交流
工具
版本控制
GIT
问题跟踪
Pivotal Tracker
Lighthouse
持续构建
Jenkins
单元测试工具
JUnit
组件测试工具
FitNesse
RobotFX
Cucumber
JBehave
集成测试
Selenium
Watir
clean code 属性
干净代码的好处：软件质量
sonar解决方案
0 条评论
下一页
