要点记录：程序员技能训练

前言中简述了优秀程序员的基本素质和工作方法。
[提示1] 关注你的技艺
这里提的程序员技能是广义的，包括开发阶段（需求分析、设计、编码、测试、部署与维护）、产品与项目管理（产品质量控制、开发过程管理）、自身与团队发展（职业发展、事业路线图）等各方面的知识技能与实践经验。
如果你不关心自身的技能训练与提升，实际上，软件开发就没什么好讲的了。
[提示2] 思考你的工作
持续不断地评估所做的工作。日语 kaizen 汉语「改善」的日传词，也音译为「快禅」，意为持续不断地小步改进，被当作日本企业经营理念，被认为是日本制造业生产力提高的核心方法。也见 第27条 不要冲出前灯范围 [提示42] 小步前进，由始至终。
我觉得荀子的《劝学》更清晰精益，开篇就是「学不可以已」。持续提升「不积跬步，无以至千里；不积小流，无以成江海。骐骥一跃，不能十步；驽马十驾，功在不舍」。
然而，对于个人，技能训练也要有目标方向，特别是在进入实际工作后，即「蚓无爪牙之利，筋骨之强，上食埃土，下饮黄泉，用心一也。蟹六跪而二螯，非蛇鳝之穴无可寄托者，用心躁也」。也见下面的 [提示7, 10, 19] 大局观、批判和专注。
-----
第1章 务实的哲学 第1~7条 大部分讲的都是形而上的方法理念，需要在践行中体会，否则就沦为了口头禅。这些原则大多和程序员自身的技能训练、基本素质、学习工作态度相关，我就归到本篇里。
-----
第1条 人生是你的
当工作不如意时，应该主动积极地做出选择或改变。软件开发相比与传统工作，有更大的灵活性，更方便的技能训练途径，前提是要主动。
-----
第2条 我的源码被猫吃了
这句话意指问题出现后，摔锅给猫的借口。所以别找借口，即使真的是猫干的，那为什么不用源码版本库呢？这里的提示是，问题出现后，要第一时间想解决方法，评估和降低损失，以及准备预防。
「我不知道，但是我会去搞清楚」这是练习中提到的话术。话术这东西，基本上是一次性买卖，如果最终搞砸了（或猎物对你有了防备），以后就再也没用了。所以耍小聪明临时挡住锋芒，后面你还是要务实。
也见 第20条 调试 [提示29] 去解决问题，而不是责备
-----
第3条 软件的熵
熵，在热力学和系统论中指系统的无序、混乱程度。
[提示5] 不要放任破窗
导致无序化倾向的一个最重要因素是项目工作中的心理性状态（负面情绪）。看到不好的设计、错误的决策、糟糕的代码，就赶紧去纠正。因为破窗效应将使有问题的软件加速腐化，而且为了救火而随意地引入附带损害，俗成 shit mountain 屎山。
编码技巧：可以用 TODO 注释标注将要做的任务，抛出 NotImplemented 异常提示用户这部分还未实现，用 stub 桩代码/假数据先替代一下跑过测试。
实践经验：决定是否立即纠正，以及花多大力气纠正，还要看具体做的东西或项目性质是什么（时效性、重要性、实验性、教学性、应急性、个人工具等），以及你能调用的生产力资源（人力时间、技能储备、工具平台）。因为纠正（通常方法是重构、TDD 等）本身也是有代价的，甚至异化。
程序结构的改进（更易于维护和复用）见 第40条 重构 [提示65] 尽早重构，经常重构
程序性能的改进见 第39条 算法速度 [提示63] 评估算法的级别
-----
第4条 石头做的汤和煮熟的青蛙
通过两个寓言故事，从两个方面论述道理。
[提示6] 做推动变革的催化剂
从士兵的角度出发，虽然他们欺骗了村民，但结果是他们和村民获得了共赢。士兵是整个活动的策划者和协调者，他们知道最终目标，这是 project manager 项目经理或 director 主管、总监所要具备的素质。一般人（如这里的村民）更愿意加入一个已然成功，或者有成功前景的事业。
当然，虚伪的画饼，和上面提的话术类似，也是一次性买卖。
实践经验：对于富交互应用，如游戏软件，制作可见可得的 prototype 原型系统（游戏叫 demo），是建立具象化目标，树立团队信心的重要方法。见 第13条 原型与便签。
[提示7] 牢记全景
从被欺骗的村民、青蛙的角度出发，告诉我们要有大局观。不要过度沉浸于细枝末节，以免察觉不到周围正在发生的事情。另一方面，青蛙和村民截然不同的命运，也是一种警示。
-----
第5条 够好即可的软件
讲的是何时止步，见 这里
-----
第6条 知识组合
[提示9] 对知识组合做定期投资
知识技能和经验是一种时效资产。学习新事物的能力是你最重要的战略资产。
将知识组合类比金融投资组合进行管理。有以下特征：定期投资、多样化利于长线、平衡保守型和高风险高回报型投资、低买高卖（指技术敏锐感，在一项技术发展的早期就投入学习，也冒很大风险）、重新评估调整组合。
实践经验：本书建议每月读一本技术书，也抽空读非技术书以了解人与生活的需求，以及隔一段时间学习一门新编程语言。对于操作技巧类技能，有时视频教程比书更高效，更容易对照练习，如开发工具（编辑器、版本控制工具、构建管理器、游戏引擎）和数字内容创作（绘画、建模、剪辑）。基础知识则用更具有系统性的读书方式，如算法、程序设计。学会有侧重点的精读与略读相配合。有些资料需要在实际工作中以 RTFM 的方式查阅参考。
[提示10] 批判性地分析你读到的和听到的东西
不要受商家、媒体或教条的影响，根据自身和项目的实际情况来分析信息。最佳实践和成功学的时效性最受怀疑。也见 第11条 可逆性 [提示19] 放弃追逐时尚
-----
第7条 交流
切忌自说自话，那样的交流是无效的。理解交流对象（用户、项目经理）的心理需求。
收集反馈。用在线调查、评论、issues 问题提交、tickets 问题单等方式收集用户反馈。根据反馈信息改善各个环节（市场推广、售后支持、开发测试）。当今的各大应用商店，如 Apple App Store, Steam，都有开发者与用户交流的反馈系统。
交流的时机。交流的内容，要看当时的场合，以及交流对象的心理状态。
交流内容的形式。是正规的文档，还是演讲稿。新手喜欢手把手教学，而老鸟偏爱 tl;dr (too long; didn't read) 太长不读的精炼要点。是浓缩的干货，还是铺垫很多背景知识。
交流中与对象互动。演讲时尤其要注重。
对别人的提问或消息要及时作出反应。没空时，发个稍后回复的消息，也比不回复好。
[提示11] 将自然语言（英语、汉语）也视作一门编程语言。写文章和编程一样，要遵循 DRY 原则、ETC、自动化等。
实践经验：训练英文技术阅读与写作，常去 Stack Overflow, GitHub, Wikipedia, Microsoft Docs (MSDN)，记录自己常用的术语词汇、语句表达法，做技术译文，强迫自己写英文注释、文档以及问答回帖。
例子，常用代码注释中叙述逻辑分支的句子「根据 a 的值判断是否做什么」，这时切忌用 judge，而要用 determine 决定，常和 whether, if 配合，也常用被动语态 determined by。
在谈到编写文章时打开自动拼写检查时，那句译文「逼近总有些措别字会漏掉检察不出来」很传神。
[提示13] 把文档嵌到源码中去。用注释详述暴露给用户使用的函数、结构、类、全局对象等的功能（也就是给用户提供的接口），对于模块内部的功能，注释要点放在工作意图、为啥要选择这么写等方面。然后，用 Doxygen、VS 的 XML 注释转文档工具等，自动从注释生成文档。这样做的好处是，注释和代码是一体的，文档也保持了更新。而写独立的文档，会因怠慢而缺乏更新，导致文档与代码脱节。