月度归档： 2024 年 10 月

一个外卖员的诗

第7-12章好像和面向对象没多大关系，内容也有点水了。

第13章（函数式语言是怎样工作的）写的不错。

面向对象的起源可以追溯到挪威的两名技术人员在1967年开发的 Simula 67 编程语言。之后，任职于美国施乐公司的艾伦•凯率领的团队开发了 Smaltalk，沿用了 Simula 67 语言的结构，确立了面向对象的概念。除此之外，凯在 IT领域还做出了很多贡献，比如开发出图形用户界面（Graphical User Interface,GUI提出作为现代笔记本电脑原型的“DynaBook设想”等。
“预测未来最好的方法就是创造它。”（The best way to predictthe future is to invent it.）据说这句名言是公司高层追问研究内容的未来走向时，凯给出的回答。想必也只有提出了诸多创新性的技术概念的凯，才能讲出这样的名言吧。

NODM 由网络（Network）、开源（Open source）、小型化（Down-sizing）和多媒体（MultiMedia）这4个单词的首字母组成“，该词在日本20世纪 90年代前半期的 IT领域广为流行。不过，随着互联网的普及，NODM 所代指的技术都逐渐成了通用技术，因此该词自然也就不再被使用了。

好莱坞原则一词可以用来表示这种框架结构的特征。在好菜坞，电影制作者对演员说“Don't call us, we will call you”（不要给我们打电话，我们会给你打电话）。

这些管理方法之所以如此失败，是因为使用它们的管理人员不理解软件项目的基本原理。这一原理被称为项目管理的铁十字，约束着所有项目必须做出权衡，无法突破。
质量、速度、成本、完成，你只能任选3个，没法4个全要。可以要求高质量、快速、低成本，这样的话项目就做不完。也可以要求低成本、快速地完成项目，那样的话质量一定不会好。

布鲁克斯定律'指出：为延迟的项目增加人手反而会使它更加延迟。

一种非常适用于大型任务的技术是三元估算。这种估算由3个数组成，这3个数分别对应最佳情况、正常情况和最坏情况。这些数都是对信心的估计：最坏情况是指你有95%的信心认为能完成该任务的时间，正常情况仅具有50%的信心，最佳情况仅具有5%的信心。

故事遵循一组简单的指导原则，这组原则的首字母缩写是 INVEST。
•|：独立（Independent）。用户故事彼此互相独立。这意味着在实现它们时不必遵守特定的顺序。例如登录不是必须在退出之前实现。
• N：可协商（Negotiable）。这是我们不在卡片上写下所有细节的另一个原因：我们希望开发人员和业务人员之间可以就这些细节进行协商。
• V：有价值（Valuable）。用户故事必须对业务具有明确且可量化的价值。
• E：可估算（Estimable）。用户故事必须足够具体，以允许开发人员进行估算。
• S：小（Small）。用户故事不应大于一到两个开发人员可以在一个选代中实现的工作量。
• T：可测试（Testable）。业务部门应该能够提出用户故事的测试标准，通过这些测试就能表明用户故事己经完成。

TDD 可以描述为以下3条简单的规则。
• 先编写一个因为缺乏生产代码而失败的测试，然后才能编写生产代码。
• 只允许编写一个刚好失败的测试——编译失败也算。
• 只允许编写刚好能使当前失败测试通过的生产代码。

肯特•贝克很久以前就提出了敏捷的4个价值观：勇气、沟通、反馈和简单。

人使用和控制工具，不能让工具控制和使用人。

分解、合并和穿刺
合并故事很简单。你可以将几张故事卡夹在一起，把它们当作一个故事对待，只需将所有故事点相加即可。
拆分故事会更有趣，因为你需要保持故事的 INVEST 原则。
穿刺是一个元故事，或者叫“用于估算故事的故事”。之所以称为穿刺，是因为我们经常需要开发一个长而很薄的切片，来打穿系统的所有层。

QA病
然而，这还不是最糟糕的。把QA工作放在流程的尾端还会带来更糟糕的问题。如果QA处于流程尾端，组织如何知道他们是否做好了自己的工作？很简单，看他们能发现多少缺陷。如果 QA 发现了很多缺陷，他们显然做得很好，QA 经理可以吹嘘自己团队发现了多少缺陷，以此作为 QA 团队尽职尽责的明确证据。
于是，发现缺陷被认为是好事。
还有谁能从这些缺陷中获益呢？老程序员有这样的说法：“你可以给我设定任何交货期限，只要别要求软件正常工作就行。”还有其他人能从缺陷中获益吗？那就是那些需要去满足交货最后期限的开发人员。
什么话都不用说，什么协议都不用写，双方都明白，他们都能从缺陷中受益。一个缺陷的“黑市经济”出现了。这种“疾病”渗透到许多组织中，哪怕暂时还不致命，这种“疾病”毫无疑问使组织逐渐虚弱。