读书笔记【程序员修炼之道-务实的最高境界 v2】

前言

1.关注技艺： 作为开发者，先关心把软件开发好, 再谈软件开发领域的事情

如果不关心怎么做好，为什么要花时间开发软件？

2.思考：做事思考一下在做什么，批判性评估

持续不断的评估所做的工作

第一章：务实的哲学

1. 你有选择权

软件开发不限地域，可以选择改变组织，换组织，对组织提出要求
学习新技术

2. 不害怕错误

承认错误，不找借口，提供解决方案选择
不要说做不到，要说力所能及能做些什么

3. 不要放任：软件熵，技术债，破窗

不做破窗的那个人

4. 石头汤: 渐进的骗局

正向思考：做催化剂，吸引、欺骗人参与渐进
反向思考：牢记全景，不要做被欺骗的温水青蛙

5. 够好即可的软件就是最好的

让用户参与权衡，知道何时止步
把质量视为 需求问题

6. 管理知识组合
   知识有时效性，会过时。管理知识组合 类似 管理金融投资：

- 定期投资（持续学习）
- 长线成功关键是 多样化投资（扩展技能）
- 平衡 保守-高风险 的组合投资（平衡 稳定技术-前沿技术 ）
- 定期重平衡（学新语言、新数据库）
- 低买高卖（新技术流行之前学习）

• 交流

学英语
说什么、怎么说
代码多嵌入文档，文档与代码隔离后很难保持正确与及时更新

第二章：务实的方法

1. 优秀设计的精髓

易变更

2. 项目易理解、易维护

DRY避免重复，单一职责
（代码重复，文档重复，数据重复，表征重复，内部API重复，外部API重复，数据源重复，开发人员重复）

3. 正交性

独立性、解耦性。一个事务不影响其他任何一个

4. 可逆性

5. 拽光弹

在做未知的东西时，几乎可以确定工作环境一定会改变。
这时不适合把系统定死（罗列需求，写文档，约束环境，做大量计算工作）。
应该使用拽光弹，快速低成本抵达目标，得到及时反馈

6. 原型与便签

与拽光弹相反，原型的设计是为了学习经验，尽量推迟细节思考
无需真正投入开发，就能模拟、暴露出一些风险

• 适用范围
  任何有风险的东西、未经证实、实验性的东西都可以用原型来研究
  架构、新功能、数据结构、三方工具、性能问题、用户界面

• 如何使用
  跳过细节，忽略正确性(用mock数据)、完整性(只满足单个功能)、健壮性(错误检查可以不完整)、格式(不需要太多文档)

• 不把原型用于产品
  原型是用完及弃的，不完整的

7. 领域语言

每个行业、领域都有自己的一些语言、词汇、语法、语义
直接用该领域的语言编程

8. 估算

缺少必要信息的情况下估算
对数量级产生直觉，判断一些事情是否可行

通过估算，根据代码迭代项目进度表

三~七 章 编码

• 第三章：开发工具
  加强编辑器
  版本控制
  调试
  文本处理语言
• 第四章：偏执
  契约式设计（规定权利与责任、针对后果协议），
  断言式编程（断言参数不为null），
  资源释放
  小步前进，不超出预测
• 第五章：解耦
  作出可逆决策
• 第六章：并发
• 第七章：编码

第八章：项目启动前

1. 需求之坑：避免常见陷阱

程序员的重要价值属性：帮助人们理解他们想要什么

1. 需求 是个循环反馈的过程，让客户理解需求的后果-优化-循环
   方法：给举反例（薅羊毛的人会怎么利用你的需求漏洞）
2. 需求 要代入客户：与客户一起工作，看客户如何工作
3. 需求 与策略：有些不是需求，而是业务策略。如（总经理可审批假期 != 需求, =权限控制策略）
4. 需求 与现实：做出来的东西在现实中没人用
5. 需求 的文档化：
   1. 文档是为计划准备的 （正确做法：就像user story，是指导实现代码的路标）
   2. 不是给客户看的(错误做法：文档当成法律文件一样详细繁杂给客户看)
   3. 需求 != 架构设计，不需要过度规范化
   4. 防止 需求蠕变、功能膨胀、特性泛滥（方法：反馈，通过客户的反馈迭代）
6. 维护一张项目术语表

2. 处理无法解决的问题

1. 约束条件
   1. 找到约束条件
   2. 区分 真约束条件 与 假约束条件
   3. 跳出假约束条件
2. 分散注意力有助于解决复杂问题（做点其他事放松）
3. 对橡皮鸭讲讲你的问题
4. 持续供养大脑，为大脑提供经验原料

3. 携手共建（共同工作）

• 康威定律：团队的边界反馈到软件的边界，独立的团队做出孤立的系统
  如何利用这一点：按照代码的模块、分布式的软件 来组建团队

• 不仅仅是提问、讨论、做笔记。要真正编码的同时提问和讨论

• 实践1 结对编程：不同背景和经验的两人。一人输入代码，一人不操作，一块解决问题。可切换角色

• 实践2 群体编程：一群人处理一个问题，加一个打字员

• 和谁一起编程？对人的方面把控

  1. 从小规模做起，小团队、短期
  2. 不针对人：看这块代码，而不是看这个人的代码
  3. 多听多理解
  4. 频繁回顾

4. 敏捷的本质

敏捷 不是 开箱即用，不是多层管理、正式报告、各种岗位头衔
敏捷 不是 工艺流程，不是 “这么干，你就敏捷了”
敏捷 无法取代思考
物理世界的敏捷，讨论的是对变化的响应。决策环境发生变化 --> 对此进行响应

• 《敏捷软件开发宣言》 价值观

个体和互动 > 流程和工具
工作软件 > 详细的文档
客户合作 > 合同谈判
响应变化 > 遵循计划

• 敏捷方式工作的秘诀：

1. 弄清楚你在哪，环境是什么
2. 朝着终点 迈出有意义的最小一步
3. 评估在哪里终结。还要把被破坏的东西修好

• 重复步骤

例：

不是举行站立会议就变成敏捷开发
而是每天站立会议收集信息，弄清楚自己在哪里，环境有什么变化，对此作出响应才是敏捷开发

第九章 务实的项目

务实的团队

小而稳定的团队
事情排日程
围绕功能组织团队（别把UI/UX、前后端程序员、测试分离）

椰子 派不上用场

飞机跑道带来财富
原住民用椰子壳做机场，期待财富到来

做有用的事，不赶时髦
在用户需要的时候交付

务实的入门三件套

1. 版本控制
   版本控制驱动构建、测试、发布
2. 无情的测试
   1. 尽早测试、经常测试、自动测试
   2. 所有的测试运行，编码才算完成
   3. 用破坏者检测测试，特意引入bug
   4. 测试 状态覆盖，不是代码覆盖
   5. 每个bug只找一次。之后都要自动化发现
3. 完全自动化
   不使用手动程序、手动部署

取悦用户

有了务实的入门三件套 才能将精力集中在最难的部分：取悦用户

发掘用户的期望，以用户存留率为指标（用户到底用不用系统）