封面
版权信息
内容简介
悦读上品 得乎益友
领悟程序员的哲学
NOTE
从程序员的个体哲学到编码过程中的各个环节，再到团队的项目管理；从程序员要如何扩充知识，如何思考问题，如何利用有效的工具打造个人的工作环境，到项目启动之前如何建立一些基本准则，如何分析、设计、编写、测试、重构，如何实现自动化，甚至是项目团队中提高实效的原则
2022-05-30 14:57:28
再次阅读，感受颇多
NOTE
比如谁都知道不要对自己家的破窗户置之不理，可实际中听到太多的妥协：这个代码已经这样了，只能继续在上面贴上丑陋的workaround，这其实是一种对责任的推卸和对未来的不负责。
2022-05-30 15:04:57
NOTE
pragmatic
2022-05-30 15:06:05
NOTE
代码的优美、设计、实现的正交、DRY（Don’t Repeat Yourself）原则
2022-05-30 15:06:18
NOTE
正如书中提到“鞋匠的孩子没鞋穿”，作为一个pragmatic程序员，合理地使用工具、库，以及自己积累的开发的轮子，会让自己的productivity不断提升
2022-05-30 15:06:48
NOTE
曳光弹。
2022-05-30 15:16:08
NOTE
ACE文档及相关资料，收益颇多，ACE可谓网络编程技术的集大成者
2022-05-30 15:23:58
一切阅读都是误读
NOTE
古人云，读书有三上，马上、枕上、厕上。
2022-05-30 15:27:09
程序员升级必备
程序员心底的小声音
其 他
专业人士对《程序员修炼之道》的赞誉
Things Really Haven’t Changed That Much
软件开发的变化并不大
译序
前言
序
第1章 注重实效的哲学 A Pragmatic Philosophy
1 我的源码让猫给吃了
NOTE
在所有弱点中，最大的弱点就是害怕暴露弱点。
2022-05-31 13:11:11
2 软件的熵
NOTE
熵是一个来自物理学的概念，指的是某个系统中的“无序”的总量。遗憾的是，热力学定律保证了宇宙中的熵倾向于最大化。当软件中的无序增长时，程序员们称之为“软件腐烂”（software rot）。
2022-06-15 10:15:03
3 石头汤与煮青蛙
4 足够好的软件
5 你的知识资产
6 交流
第2章 注重实效的途径 A Pragmatic Approach
7 重复的危害
8 正交性
NOTE
在计算技术中，该术语用于表示某种不相依赖性或是解耦性。如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。
2022-06-15 10:15:50
9 可撤消性
10 曳光弹
11 原型与便笺
12 领域语言
13 估算
第3章 基本工具 The Basic Tools
14 纯文本的威力
15 shell游戏
16 强力编辑
17 源码控制
18 调试
19 文本操纵
20 代码生成器
第4章 注重实效的偏执 Pragmatic Paranoia
21 按合约设计
22 死程序不说谎
23 断言式编程
24 何时使用异常
25 怎样配平资源
第5章 弯曲，或折断 Bend，or Break
26 解耦与得墨忒耳法则
27 元程序设计
28 时间耦合
29 它只是视图
30 黑板
第6章 当你编码时 While You Are Coding
31 靠巧合编程
32 算法速率
33 重构
34 易于测试的代码
35 邪恶的向导
第7章 在项目开始之前 Before The Project
36 需求之坑
37 解开不可能解开的谜题
38 等你准备好
39 规范陷阱
40 圆圈与箭头
第8章 注重实效的项目 Pragmatic Projects
41 注重实效的团队
42 无处不在的自动化
NOTE
文明通过增加我们不加思索就能完成的重要操作的数目而取得进步。
2022-05-30 15:48:05
NOTE
人工流程不能保证一致性，也无法保证可重复性，特别是在不同的人对流程的各个方面有不同解释时。
2022-05-30 15:51:41
NOTE
我们可以增加挂钩，让其为我们生成代码，并自动运行回归测试。IDE有自身的优势，但只用IDE，可能很难获得我们寻求的自动化程度。我们想要用一条命令就完成签出、构建、测试和发布。
2022-05-31 08:47:07
NOTE
回归测试
2022-05-31 08:50:24
NOTE
只能分析存在于单次make调用中的依赖关系
2022-05-31 11:16:02
NOTE
不知道对make的其他调用可能具有的依赖关系
2022-05-31 11:16:11
NOTE
很容易带来不必要的额外工作——或是遗漏某一依赖，在需要重新编译时没有重新编译
2022-05-31 11:16:22
NOTE
运行规定的测试（make test）
2022-05-31 11:18:59
NOTE
如果你没有定期运行测试，你可能会发现，应用因为3个月前做出的代码改动而失败。但愿你有足够的好运气找到它。
2022-05-31 11:18:49
43 无情的测试
NOTE
大多数开发者都讨厌测试。他们往往会温和地测试，下意识地知道代码会在哪里出问题，并避开那些薄弱的地方。注重实效的程序员与此不同。我们受到驱迫，现在就要找到我们的bug，以免以后经受由别人找到我们的bug所带来的羞耻。 寻找bug有点像是用网捕鱼。我们用纤小的网（单元测试）捕捉小鱼，用粗大的网（集成测试）捕捉吃人的鲨鱼。有时鱼会设法逃跑，所以为了抓住在我们的项目池塘里游动的、越来越狡猾的缺陷，要补上我们发现的任何漏洞。 提示62 Test Early.Test Often.Test Automatically. 早测试，常测试，自动测试。 一旦我们有了代码，我们就想开始进行测试。那些小鱼苗有飞快地变成吃人的大鲨鱼的可恶习惯，而抓住鲨鱼会困难许多。但我们又不想手工进行所有这些测试。 许多团队都会为他们的项目精心制订测试计划。有时他们甚至会使用这些计划。但我们发现，使用自动测试的团队成功的机会要大得多。与呆在架子上的测试计划相比，随每次构建运行的测试要有效得多。 bug被发现得越早，进行修补的成本就越低。“编一点，测一点”是Smalltalk世界里流行的一句话[6]，我们可以把这句话当作我们自己的曼特罗，在编写产品代码的同时（甚至更早）
2022-05-31 08:51:18