序言
内容参考「程序员修炼之道」一书。
大纲
实力
- 技术是程序员的基本功和硬实力。
- 保证技术更新，持续学习。
思考
- 多思考手头的事情
- 保证你做的事情是为目标服务。
- 安排优先级重要性。
- 不断思考和批判，做好决策。
- 知道自己所做工作的意义。
一、哲学
责任
- 分析任务风险，不可能做到或者风险太大的任务可以不接。
- 承诺确保的事情，负起责任。
- 任务过程中出现可预见风险和延期及时告知，保持沟通。
- 做不到的事情给出选择而非借口。
- 告知决策之前进行谈话预演，我这样说，其他人会说什么想什么？
破窗
- 破窗零容忍：保证项目代码整洁
做变化的催化剂
- 给出蓝图，调动每个人的积极性，让每个人都能做出一点优化。
投资知识
- 养成定期学习习惯。
- 尽可能学习长时效的知识。
- 低投高产，在新技术出现伊始学习，一般就是低投入。
目标：
- 每年至少学习一门新语言。
- 每季度至少读一本技术书籍。
- 也要阅读非技术书籍。
- 上课，大学，网课等等都可以。
- 加入组织（开源项目，社区等）。
- 预先规划，让自己在空闲时间都有事可做有东西可学。
- 独立思考，批判分析。
沟通
交流：
- 知道你想要说什么，提炼和概括内容。
- 知道别人想了解什么。
- 知道应该什么时候说，选择恰当时机。
- 选择恰当的方式，文档、邮件、面谈等等。
- 恰当的表达方式，说什么和怎么说同样重要。
文档：
- 保证文档的美观和整洁。可以参考 中文文档排版指北
- 让读者参与到文档，征求他们的意见。
- 把会议变成对话，如果你想大家听你说话：听他们说话。
- 总是有回复，即使只是一句「我稍后再回你」。
二、途径
DRY 原则
系统的每一项知识都必须具有单一、无歧义、权威的表示。我们称其为「DRY」（Dont't Repeat Yourself）。
四种重复：「强加的重复」，「无意的重复」，「偷懒的重复」，「开发者之间的重复」。
强加的重复：
有时候我们不得不重复代码，重复定义结构、过程。编写类似内容的文档。多个目标平台需要自己的编程语言等等。这里有这样几种情况：
- 信息的多种表示。比如在 Python 爬虫中我们可能需要重复构造 HTTP 请求，这时我们可以编写一个简单的代码生成器去构建程序（比如 Postman 自带的生成器）。再比如数据库的配置文件，可能很多地方都需要链接数据库，我们可以写入配置文件就避免了每次代码都需要写一遍配置。
- 代码中的文档。我们常常听到，代码要加注释，但是往往不知道什么时候加注释。「DRY 法则」告诉我们：要把低级的知识放在代码中，把注释留给其他的高级说明。否则，每一次改变都要修改注释，注释不可避免的会过时，而不正确的注释比完全没有更加糟糕。
无意的重复：
有时候重复来自于设计错误或者因为性能问题违反「DRY 法则」（比如需要缓存）。这时方法是使影响局部化，对「DRY 法则」的影响不暴露给外界。
偷懒的重复：
一句话，不该偷懒的地方别偷懒。
开发者之间的重复
多交流
正交性
低耦合：消除无关事物之间的影响
- 避免使用全局变量
- 避免编写相似的函数
可撤销性
比如项目初期你打算用 A 公司的关系数据库，用一段时间后发现供应商 B 提供的数据库更便宜更快速，如果你的数据库概念已经抽离出来就很容易换到另一个数据库中。再比如项目初期采用的是「客户 - 服务端」模型，但是项目中期市场部门认为单机版效果更好。如果你把项目改为单机版对你来说有多困难？
决策之前要未雨绸缪，考虑到各种情况提前设计。
要把决策视为是写在沙滩上的，而非刻在石头上。大浪随时可能会来，抹去它们。
There Are No Final Decisions. 不存在最终决策
估算
估算的精度
根据情景选择估算精度，如果你家人问你什么时候回来，他们可能只是想准备午餐或者晚餐，而一个在水下空气即将用光的潜水运动员可能就需要精确到秒的估算。
关于估算有个有趣的现象，如果你说某个事情需要 130 天完成，那么大家会期望他在 130 天的前后几天完成，但是如果你说「大概需要４个月完成」，那么大家会期望它在第五到七个月完成。这两个数字表示相同的时间，但「130 天」暗含了更高的时间精度。建议这样估算时间：
| 时长 | 估算单位 |
|---|---|
| 1-15 天 | 天 |
| 3-8 周 | 周 |
| 8-30 周 | 月 |
| 30+ 周 | 在给出估算前先想想 |
估算的来源
-
理解提问的内容
-
建立系统的模型
-
把模型分解为组件
-
给每个参数指定值
-
计算答案
估算项目进度
- 检查需求
- 分析风险
- 设计、实现、集成
- 向用户确认
在被要求估算时回答什么？
回复「我等会回答你」，然后花点时间认真估算。
三、基本工具
纯文本
用纯文本去存储数据。优点：
- 保证不过时
- 杠杆作用
- 更易于测试
用好 Shell
利用 Shell 提高工作效率。
选好编辑器
有以下特性：
- 可配置，可以按照你的偏好配置编辑器
- 可扩展，迅速集成开发环境
- 可编程，可对编辑器编程
版本控制系统
总是使用版本控制系统，即使只有你自己开发。
面对 Bug
原则：
想办法解决问题，而不是甩锅或者指责。各种问题适用。
方法：
- 不要恐慌，如果你面对「bug」的第一反应是「那不可能」，那你的每个脑细胞都浪费在「那不可能」起头的思绪上。问题都已经发生了，不要再自我欺骗。
- 数据可视化，一图胜千言。
- 向别人或者自己解释程序。
- 先不要考虑系统，编译器，或者第三方产品的问题。
- 如果你只改了一样东西系统就出了问题，很可能问题出在你修改的东西上。
- 不要认为和应该，要证明。
代码生成器
- 代码生成器本质是参数化模板。
- 代码生成器不一定很复杂。
四、需求之坑
- 不要搜集需求，挖掘需求。
- 与用户一同工作，像用户一样思考。
- 建立需求文档，好的需求文档要保持抽象。
- 抽象比细节活的要长久。
- 需求不是架构也不是设计，需求是需要。
- 维护词汇表，项目的所有参与者都应该使用该词汇表。
