读程序员的README笔记02_软件的熵与技术债.png

1. 提出问题

1.1. 所有的工程师都应该提出问题，这是学习的一个重要部分

1.2. 新手工程师会担心打扰队友而试图自己解决所有问题，这样做既慢又没有效

1.3. 尝试自己寻找答案

1.3.1. 即使你的同事知道答案，你也要付出努力，这样你会学到更多

1.3.2. 如果你没有找到答案，当你寻求帮助时，你的调查仍然会成为你的起点

1.3.3. 不要只是在互联网上搜索

1.3.3.1. 信息还存在于文档、内部论坛、自述文件(README)、源代码和错误跟踪器中

1.3.3.2. 如果你的问题是关于代码的，试着把它变成一个可以演示的单元测试

1.4. 设置一个时间限制

1.4.1. 限制你研究一个问题时预期花费的时间

1.4.2. 在你开始研究之前就应该设定好时间限制，这样可以鼓励你遵守这个限制，防止收益递减（研究最终会拖累生产性）

1.5. 写下全过程

1.6. 别打扰别人

1.6.1. 其他人也在努力完成工作，他们需要专注

1.6.2. 公司有不同的惯例来标识“请勿打扰”

1.6.2.1. 耳机、耳塞或耳罩是通用的标识

1.7. 多用“非打扰式”交流

1.7.1. 组播(multicast)是指将消息发送到一个组而不是个人目标

1.7.2. 异步(asynchronous)是指可以稍后处理的消息，而不需要立即响应

1.7.3. 即使你需要一个特定的人来回答问题，也要使用共享论坛

1.7.3.1. 你可以在帖子中提到他们的名字

1.8. 批量处理你的同步请求

1.8.1. 聊天和电子邮件对简单的问题很实用，但复杂的讨论很难异步进行

1.8.2. 面对面的交流是“高带宽”和“低延迟”的

1.8.2.1. 可以快速地解决很多问题

1.8.3. 安排一次会议，或者使用“办公室答疑时间”

1.8.3.1. 写下你的问题并保留到会议上

1.8.3.2. 如果你已经没有问题了，就请取消会议

1.8.3.3. 如果你发现自己反复地取消会议，就自省一下这种会议是否还有用

1.8.3.3.1. 如果已经没用了，就不要再安排

2. 行为准则

02_行为准则.png

3. 冒充者综合征

3.1. 大多数新手工程师在开始工作时处于“有意识的无能力”阶段

3.1.1. 有很多东西需要学习，而其他人似乎早已遥遥领先

3.2. 他们说他们只是很幸运，他们不值得别人认可，或者是升职标准太宽松了。这就是冒充者综合征

3.3. 冒充者综合征，以及可能随之并发的焦虑和抑郁，是一个复杂的话题

3.4. 冒充者综合征会自我强化

3.4.1. 每一个错误都会被看作能力匮乏的证明

3.4.2. 每一项成功都是优秀“冒充者”冒充的证

3.4.3. 自我怀疑很常见

3.5. 不要忽视赞美和成就

3.5.1. 即使是小事情，也要把它们写下来

3.6. 获得反馈也有助于缓解冒充者综合征

3.7. 治疗可能也会有帮助

3.7.1. 可以利用治疗来获得你的优势，并克服短期的挑战

4. 邓宁-克鲁格效应

4.1. 邓宁-克鲁格效应在新手工程师中并不常见

4.2. 一种认知偏见，人们认为自己比实际情况更有能力

4.2.1. 与冒充者综合征相反

4.3. 他们太自信了

4.4. 他们总是到处批判公司的技术栈，抱怨代码的质量，贬低设计

4.5. 他们确信自己的想法是正确的

4.6. 他们的默认模式是直接回绝或无视反馈

4.7. 完全自信标志着盲点

4.8. 应对

4.8.1. 有意识地培养好奇心

4.8.2. 对犯错持开放态度

4.8.3. 找到一位受人尊敬的工程师，询问他你做得怎么样，并真正地倾听

4.8.4. 讨论设计决策，尤其是那些你不同意的决策，问问为什么会做出这样的决策

4.8.5. 培养一种权衡利弊的心态，而不是非黑即白的心态

5. 代码库

5.1. 代码库就像阿尔勒的那个圆形剧场一样

5.2. 一代人写了几层，然后又改了改

5.3. 很多人都接触过这些代码

5.4. 测试缺失或强制执行已经过时的设定，不断变化的需求扭曲了代码的使用

6. 软件的熵

6.1. 走向无序的趋势被称为软件的熵(software entropy)

6.2. 当你浏览代码时，你就会注意到它的缺点

6.3. 混乱的代码是变化的自然副作用

6.3.1. 不要把代码的不整洁归咎于开发者

6.4. 很多事情都会导致软件的熵

6.4.1. 开发者误解了其他人的代码或风格上的差异

6.4.2. 不断进步的技术栈

6.4.3. 不断发展的产品需求

6.4.4. bug修复和性能优化带来的复杂性

6.5. 软件的熵可以被管理

6.5.1. 代码风格和bug检测工具有助于保持代码的整洁

6.5.2. 代码评审有助于传播知识和减少不一致

6.5.3. 持续的重构可以减少熵

7. 技术债

7.1. technical debt

7.2. 技术债(technical debt)是造成软件的熵的一个主要原因

7.3. 技术债是为了修复现有的代码不足而欠下的未来工作

7.4. 技术债总是不可避免的

7.4.1. 因为你无法防止无意中的错误

7.5. 技术债甚至可能是成功的标志

7.5.1. 项目只有存活了足够长的时间，才会变得无序

7.6. 技术债也有“本金”和“利息”

7.6.1. 本金是那些需要修复的原始不足

7.6.2. 利息是随着代码的发展没有解决的潜在不足，因为实施了越来越复杂的变通方法

7.6.3. 随着变通办法的复制和巩固，利息就会增加

7.7. 复杂性蔓延开来，就会造成bug

7.7.1. 未支付的技术债很常见，遗留代码里有很多这样的债务

7.8. 你不同意的技术决策并不是技术债，你不喜欢的代码也不是

7.9. 谨慎的、有意的技术债是技术债的典型形式

7.9.1. 在代码的已知不足和交付速度之间进行务实的取舍

7.9.2. 只要团队有规划地解决这个问题，这就是好的债务

7.10. 鲁莽的、有意的技术债是在团队面临交付压力的情况下产生的

7.10.1. 出现“……就……”或“只是”这种词就是在暗示讨论中的内容是鲁莽的债务

7.11. 鲁莽的、无意的技术债来自“不知道自己不知道”

7.11.1. 可以通过事前写下实施计划并获得反馈的方式，以及进行代码评审的方式来减轻这种债务的危险

7.11.2. 持续学习也可以最大限度地减少这种无意的鲁莽行为

7.12. 谨慎的、无意的技术债（是成长经验积累的自然结果

7.12.1. 有些教训只有在事后才会被吸取

7.12.2. 与谨慎的、有意的技术债不同，团队不会知道自己正在承担债务

7.12.3. 与鲁莽的、无意的技术债不同，这种类型的债务更像是在出问题的领域反思学习或作为软件架构师成长的必经之路

7.12.3.1. 不是未做功课这么简单

7.12.4. 健康的团队使用诸如项目回顾等做法来发现无心之债，并讨论何时以及是否偿还

7.13. 在短期内，偿还技术债会拖慢交付特性的速度，而承担更多的技术债会加速交付

7.14. 长期来看，情况正好相反：偿还技术债会加快交付的速度，而承担更多的债务则会减缓交付