程序员修炼之道（第2版）

第1章 务实的哲学

人生是自己的，不要总是抱怨，而要学会如何改变。不停学习，从而改变达到自己的理想目标

只有为学习而加班才是合理的，要不停提升自己，让自己具有竞争力

要用于承担责任，而不是说“我的代码被猫吃了”。此外当你说“我不知道”的时候，要接着说一句“——但我会试图搞清楚”

若是延期和搞砸，不要就说搞不定，而是要解释一下要做什么才能挽回局面，给他们选择：如需要额外资源才能完成任务，需要花更多时间额用户打交道或学习新技能，需要重构模型，需要引入更好的测试及自动化流程等。

及时修补“破窗”，看到糟糕设计、低劣代码时，要及时修改，如果当前没时间，也要在代码加上备注，并安排时间。

“石头做的汤”故事：遇到人们都只守着自己的一亩三分地，不愿意承担责任时，拿出石头——找出合理请求，并不断完善。一旦有成果产出，展示给人们看，让他们大吃一惊。然后装作不在意地说一句“当然了，它可以更好，只要我们再加点……”

“温水煮青蛙”故事：永远留意大局，持续不断审视自己身边发生的事情，而不要只专注自己个人做的事情。

“够用就好”原则：只要写出对用户和未来维护者来说够好的代码即可，只要好到能让自己内心平静就行。这样自己能变得更有效率，客户也更快乐。

知识组合和金融投资组合非常相似：要定期学习；多样化学习；保守型和高风险高回收知识组合；低买高卖（提前学习一门尚未流行的语言）；重新评估调整

批判性思考方法：连续追问至少五次why；谁从中受益（利益分析）；有什么背景（这本书适合什么阶段学习者阅读，有什么产出）；什么时候在哪里可以工作起来（要多阶思考，即当它结束后还会发生什么）；为什么是这个问题（是否存在基础模型，基础模型是怎么工作的？）

交流

了解客户的需求，给用户24h都可以反馈的平台；商务沟通前要捋清楚自己想说什么（反复练习，直到达到最精炼程度）；选择时机，如经理因丢了源码被老板训斥，抓住机会找他谈代码仓库的事情，他更可能听得进去。

尽量弄一个优美的UI界面；注释文档很重要，但只给复杂代码写（简单代码和注释没啥太大区别）

第2章 务实的方法

DRY——避免重复：在一个系统中，每一处知识都必须单一、明确、权威的表达

文中给出了代码重复，文档重复，数据重复（看一遍有印象即可）

表征的重复：内部API重复、外部API重复、数据源引起的重复

• 内部API重复：找工具，生成文档、模拟API、功能测试，还可生成不同语言的API客户端
• 外部API重复：公开API越来越多采用类似OpenAPI的东西做正式规范，这方便开发者将API规范导入本地API工具，更可靠和服务集成
• 数据源引起重复：①可借用数据源对数据（库？前无后有）schema内省来清楚数据源和代码间的重复；②可将数据插入键值对的数据结构中（表、哈希表或字典、甚至对象）+表驱动的检验组件
• 开发人员间的重复：鼓励开发人员频繁交流，日常scrum晨会，开如slack之类的沟通频道；指派团队一人做项目知识管理员促进知识的传播，并在源码目录中设置一个存放位置，存放工具程序和工具脚本

ETC——实现正交性：模块，组件化

第3章 基础工具

人类可描述形式的数据会比其他形式的数据以及创建数据的程序更加具有生命力：123456789 < <field1>123456789</field1> < <SSNO>123456789</SSNO>

要充分利用shell的优势

无鼠标/触控板挑战这部分已经实现，感谢学校购入这设计贼不合理的桌椅 ：）

版本控制

VCS：目前只会用git，虽然已经玩过git游戏，但是在面对实际问题时还是有些吃力，于是又获得了如下建议：

1. 阅读 Pro Git 2nd edition
2. 遇到问题时去git-flight-rules仓库查找解决方案

但是若基础太差，方法2可能不管用。我当时遇到了这样的问题，gitguardian检查出我一私有仓库暴露了token，虽然我并不会公开该仓库，但是觉得自己这习惯还是不好，再加上想练git，于是我想回到某一commit修改内容，用了对应的方法没效。折腾了老久，最后重新生成秘钥。

另外，据这篇文章说明，word可以用一款名为Pandoc的软件将docx转换成markdown，git merge，再将markdown转回成docx。（不过个人没试过，只是觉得很神奇，因为如果涉及做作业或者是写论文，能用git控制版本那真是太爽了）

期末考试，这部分停更一周