圣杯与银弹 · 没用的设计模式 · /holy-grail-design-pattern

[draveness]

https://draveness.me/holy-grail-design-pattern

学习设计模式与设计优秀的软件并不相关，盲目追求和套用书中的设计模式只能使项目变得更加糟糕，本文并不是要批判《设计模式》中提出的通用的设计模型，我们需要对书中的内容多一些批判性的思考，想清楚究竟什么样的设计才是能够保留下来的。需要注意的是，这篇文章充满了作者的主观意见和个人经验，如果读者不认同本文的观点，欢迎在文章下面留言并讨论。

[yanjinbin]

哈哈 特地来赞同下，很反感设计模式拿来做面试考察内容。 一说设计模式，大都老JAVA了 2333 。 见过有更风骚的拿反射来写业务代码。 简单的设计模式有他的适用性，复杂的设计模式，有些看起来很拙劣

[YangKian]

A Typo，图4上面那段的第一行：如果要从抽象的理论直接推导出或者出具体的实现是比较困难的，或者后面应该是漏了一个词 :)

[draveness]

A Typo，图4上面那段的第一行：如果要从抽象的理论直接推导出或者出具体的实现是比较困难的，或者后面应该是漏了一个词 :)

已经修复了

[draveness]

简单的设计模式有他的适用性，复杂的设计模式，有些看起来很拙劣

个人的体会是，简单的设计模式真的不需要从书中学

[BluebuleZJR]

深有体会，《Head First 设计模式》和《大话设计模式》都看过。真写过的模式也只有策略模式，一是业务代码对我来说很难抽象出来，二是赶时间上线也没时间给你思考。

[maxnoodles]

本人现在算正式接触开发一年，公司一直使用python + 函数编写业务，感觉自己代码写得很烂，很像面向实现编程，一遇到扩展或者修改基本就是重构或者重写，请问有什么书推荐一下吗 (刚想去看大话设计模式)，还有一个开发中真的需要像 TDD 一样先写测试再写业务吗，而且单元测试需要覆盖大部分情况，感觉写一个函数，从而写5个函数来测试他的各种情况，是不是有点累。本人基本只覆盖了函数的正确测试情况。

[draveness]

本人现在算正式接触开发一年，公司一直使用python + 函数编写业务，感觉自己代码写得很烂，很像面向实现编程，一遇到扩展或者修改基本就是重构或者重写，请问有什么书推荐一下吗 (刚想去看大话设计模式)

可以翻一翻《重构》这本书，不过重构的基础是完善单元测试，对于动态的编程语言来说，由于没有编译器的检查，单元测试更加重要，我们又回到了原点。

还有一个开发中真的需要像 TDD 一样先写测试再写业务吗

不需要像 TDD 一样，但是要写单元测试

而且单元测试需要覆盖大部分情况，感觉写一个函数，从而写5个函数来测试他的各种情况，是不是有点累。本人基本只写了复制函数的正确测试情况。

单元测试的作用非常大，起码要覆盖核心逻辑，不过在这里不想在这里重新展开介绍单元测试的重要性了，以后可以讲讲

[WyattJia]

想要学习设计优秀的软件，其实可以看看 SICP 或者 HTDP 。

[draveness]

想要学习设计优秀的软件，其实可以看看 SICP 或者 HTDP 。

SICP 是一个不错的起点，能改变对编程这件事情的理解，尤其是对仅使用 OOP 的工程师

[maxnoodles]

https://draveness.me/holy-grail-design-pattern

@draveness

本人现在算正式接触开发一年，公司一直使用python + 函数编写业务，感觉自己代码写得很烂，很像面向实现编程，一遇到扩展或者修改基本就是重构或者重写，请问有什么书推荐一下吗 (刚想去看大话设计模式)

可以翻一翻《重构》这本书，不过重构的基础是完善单元测试，对于动态的编程语言来说，由于没有编译器的检查，单元测试更加重要，我们又回到了原点。

非常感谢推荐，清明节好好读一读。

还有一个开发中真的需要像 TDD 一样先写测试再写业务吗

不需要像 TDD 一样，但是要写单元测试

而且单元测试需要覆盖大部分情况，感觉写一个函数，从而写5个函数来测试他的各种情况，是不是有点累。本人基本只写了复制函数的正确测试情况。

单元测试的作用非常大，起码要覆盖核心逻辑，不过在这里不想在这里重新展开介绍单元测试的重要性了，以后可以讲讲

到时候能推荐一些最佳实践吗，因为公司内部的测试基本都只是使用 requests 测试了一下接口的正确情况，然后就覆盖率写得很高。。。想请问测试的单位具体到那种程度合适。是否每个函数都需要测试，如果只是一个函数简单包装了另一个核心函数，那2个函数都需要写测试吗？

[draveness]

到时候能推荐一些最佳实践吗，因为公司内部的测试基本都只是使用 requests 测试了一下接口的正确情况，然后就覆盖率写得很高。。。想请问测试的单位具体到那种程度合适。是否每个函数都需要测试，如果只是一个函数简单包装了另一个核心函数，那2个函数都需要写测试吗？

合理的方式是分层的，每层只测试自己的功能，这样能够减少每一层单元测试需要关注的上下文，不过我说这些你可能也就一听，以后可以详细说一说

[maxnoodles]

@draveness

想要学习设计优秀的软件，其实可以看看 SICP 或者 HTDP 。

SICP 是一个不错的起点，能改变对编程这件事情的理解，尤其是对仅使用 OOP 的工程师

SICP 很早就加入在读书清单里面，不过之前在知乎看到很多回答说此书耗费时间非常长，一直望而却步，可能现在也要看一看了。

[draveness]

@draveness

想要学习设计优秀的软件，其实可以看看 SICP 或者 HTDP 。

SICP 是一个不错的起点，能改变对编程这件事情的理解，尤其是对仅使用 OOP 的工程师

SICP 很早就加入在读书清单里面，不过之前在知乎看到很多回答说此书耗费时间非常长，一直望而却步，可能现在也要看一看了。

可以顺便再看看相关的视频，我自己在学习的时候觉得刷新了当时对编程的认识

[WyattJia]

@draveness

想要学习设计优秀的软件，其实可以看看 SICP 或者 HTDP 。

SICP 是一个不错的起点，能改变对编程这件事情的理解，尤其是对仅使用 OOP 的工程师

SICP 很早就加入在读书清单里面，不过之前在知乎看到很多回答说此书耗费时间非常长，一直望而却步，可能现在也要看一看了。

可以看看 Python 或者 JavaScript 版本的，精简很多，思想不变。

[maxnoodles]

@draveness

@draveness

想要学习设计优秀的软件，其实可以看看 SICP 或者 HTDP 。

SICP 是一个不错的起点，能改变对编程这件事情的理解，尤其是对仅使用 OOP 的工程师

SICP 很早就加入在读书清单里面，不过之前在知乎看到很多回答说此书耗费时间非常长，一直望而却步，可能现在也要看一看了。

可以顺便再看看相关的视频，我自己在学习的时候觉得刷新了当时对编程的认识

最近刚在b站上发现 MIT 关于 SICP 的公开课，luck

[yanjinbin]

大佬再说说 单元测试吧。。。

[draveness]

大佬再说说 单元测试吧。。。

可以啊，这里面其实讲了一些，感兴趣可以看看 https://draveness.me/golang-101

[runforprogram]

同感，在写代码的时候，如果发现有点别扭，就知道去想怎么设计合理一点。有可能就用到了某些模式。面试考这个也是很尴尬，没有用过的根本背不下来。

[yuchanns]

工作了快4年，用过最多的就是单例、观察者、工厂、装饰器这些。。。 接触go之后看一些源码设计经常刷新我对接口的看法。。。

[draveness]

工作了快4年，用过最多的就是单例、观察者、工厂、装饰器这些。。。 接触go之后看一些源码设计经常刷新我对接口的看法。。。

不同语言的设计其实差别挺大的

[PeterlitsZo]

感觉python是真的很好的在开发速度和稳定做了一个让很多人满意的平衡，有什么写起来很不错的语言吗？（个人感觉哈，golang真的很难写www，有很多特别特别好的地方但是......）比如说有不错的语法糖，统一性。

[draveness]

感觉python是真的很好的在开发速度和稳定做了一个让很多人满意的平衡，有什么写起来很不错的语言吗？

如果说 Python 的开发速度比较快，个人觉得是正确的。但是从稳定的角度来看，脚本语言还是不适合开发稍微大一些的项目，少了编译器的检查，我们就不得不写非常多的单元测试来保证工程质量，但是并不是所有开发者都能写出易于测试的代码和合格的单元测试，所以做一些研究或者数据相关的工作还是没有问题的，但是很多公司都在迁移 Python 服务，毕竟它与一些静态语言相比，性能上有数量级的差距，可能不止只一个数量级。

（个人感觉哈，golang真的很难写www，有很多特别特别好的地方但是......）比如说有不错的语法糖，统一性。

我最开始对 Go 语言的看法和你一样，认为这门语言非常难写，很多工具的设计也不符合直觉，但是在熟悉了社区的这一套规范之后，反而会觉得这门语言开发效率比较高，静态类型以及完善的工具链能够辅助工程师的开发；之前认为很多不方便的地方是语言的顶层设计决定的，也是语言设计者的抉择和权衡。

如果你希望我能推荐变成语言的话，那么你其实需要详细的描述你的需求，到底是想找一个靠他吃饭和谋生的编程语言，还是业余时间玩的编程语言。

[PeterlitsZo]

如果你希望我能推荐变成语言的话，那么你其实需要详细的描述你的需求，到底是想找一个靠他吃饭和谋生的编程语言，还是业余时间玩的编程语言。

我并不认为玩和吃饭非此即彼，但从推荐角度来说的话，我更倾向于玩@_@

我现在习惯在Python中写tdd测试代码，我认为你说得对，的确很长，不过我也不知道静态语言的ttd该怎么写。因为Python的tdd是标准，拿来可用（是的，强大的标准库和包管理器会强烈的吸引我），但C++不是，我最近在尝试为我们学校的作业写测试代码，所以在看gtest，但没有完整的使用过，并不知道静态语言的测试会不会轻松。（但是动态语言的测试也没有困扰到我，写测试有时很让人开心^_^）

我喜欢函数式编程，喜欢支持元编程的语言，良好的统一性，强健的内建库和强大的包管理器，和优雅的面向对象模式，可以良好的发布。（性能不在我首选的范围）

我没有认为现在有一个语言能完整的实现所有的功能，但是我还是在寻找能尽可能多的实现的语言。

我表达了对lisp，haskell和rust的兴趣，tutorial的前几页也看了的，我很喜欢。（不过由于人类的本质并没有坚持下去，我相信我会看完的）

我认为语言是工具，但我尽可能尝试新的语言，希望能在新的语言中找到新的有意思的地方。我很喜欢这样子。

[draveness]

我并不认为玩和吃饭非此即彼

嗯呢，有时候可以

我现在习惯在Python中写ttd测试代码，我认为你说得对，的确很长，不过我也不知道静态语言的ttd该怎么写。因为Python的ttd是标准，拿来可用（是的，强大的标准库和包管理器会强烈的吸引我），但C++不是

ttd 是什么，是 TDD 么

，我最近在尝试为我们学校的作业写测试代码，所以在看gtest，但没有完整的使用过，并不知道静态语言的测试会不会轻松。（但是动态语言的测试也没有困扰到我，写测试有时很让人开心^_^）

静态语言测试写起来麻烦的一笔

我喜欢函数式编程，喜欢支持元编程的语言，良好的统一性，强健的内建库和强大的包管理器，和优雅的面向对象模式，可以良好的发布。

不同语言对元编程有不同的支持，在某种程度上都支持元编程，可以看看 https://draveness.me/metaprogramming/

（性能不在我首选的范围）

这个没有问题哈，我业余时间玩的时候都写 Ruby，但是说两点

• 有些极端场景要做微秒级别优化的，动态语言做不了，做优化的过程也很有意思；
• 公司会考虑成本，如果用 Python 的机器比 Go 多几十倍，用 Go 语言写的服务可能只需要几百个实例，用 Python 可能就需要几千，那么就没理由选择更慢的语言^1，服务器真的太贵了；

[WyattJia]

感觉python是真的很好的在开发速度和稳定做了一个让很多人满意的平衡，有什么写起来很不错的语言吗？（个人感觉哈，golang真的很难写www，有很多特别特别好的地方但是......）比如说有不错的语法糖，统一性。

Scala 不错，Golang 写业务代码确实有点难受。

[draveness]

感觉python是真的很好的在开发速度和稳定做了一个让很多人满意的平衡，有什么写起来很不错的语言吗？（个人感觉哈，golang真的很难写www，有很多特别特别好的地方但是......）比如说有不错的语法糖，统一性。

Scala 不错，Golang 写业务代码确实有点难受。

哈哈哈，这个还是看个人体验吧

[PeterlitsZo]

太神奇了，我发现golang有一个细节，就是无论是内置类型还是自己定义的数据结构，fmt.Println都是使用对象的String方法来调用的！（这就是我喜欢的统一性的一个代表！）那么是不是range也可以给自定义对象使用？等等之类的？

（使用interface{}来操作，感觉有点点动态语言的鸭子类型的感觉了）

Scala看起来是用来生成Java代码的语言，Ruby看起来像是Lisp。我最近看了点点介绍，但是时间有点紧张www

不早了，我睡觉去了，明天还有？有考试吗！！！我的天我没复习！！！

[aaa1999]

@PeterlitsZo 太神奇了，我发现golang有一个细节，就是无论是内置类型还是自己定义的数据结构，fmt.Println都是使用对象的String方法来调用的！（这就是我喜欢的统一性的一个代表！）那么是不是range也可以给自定义对象使用？等等之类的？

（使用interface{}来操作，感觉有点点动态语言的鸭子类型的感觉了）

Scala看起来是用来生成Java代码的语言，Ruby看起来像是Lisp。我最近看了点点介绍，但是时间有点紧张www

不早了，我睡觉去了，明天还有？有考试吗！！！我的天我没复习！！！

太厉害了。在校学生，这么厉害嘛。

[tidyoux]

没有银弹，因为复杂性是编程的核心属性。

实现的复杂度总是不小于问题的本质复杂度，我们能做的就是在问题空间中找到一组合适的基，使我们能尽量逼近本质复杂度。

设计更多的是为了做到封装，而封装是为了隔离变化，隔离变化是为了控制复杂度。

设计的过程就是找基的过程。

[neochief]

感谢您的文章！

我试图使其保持现代和乐趣。

[hoset]

@BluebuleZJR 深有体会，《Head First 设计模式》和《大话设计模式》都看过。真写过的模式也只有策略模式，一是业务代码对我来说很难抽象出来，二是赶时间上线也没时间给你思考。

同感

[PasserbyX7]

设计模式之三重境界 看山是山：手里有锤子看什么都是钉子 看山不是山：厌倦了模式的嵌套，对曾经的设计深恶痛绝 看山还是山：写完代码后恍然发现，哦，我这里用了xx模式啊 我觉得这篇文章洋洋洒洒，不过是一句“会者不难，难者不会”。我倒觉得初学者应该大胆地用模式，踩过坑了跌得疼了才有后期的返璞归真信手拈来。

[draveness]

@PasserbyX7 设计模式之三重境界 看山是山：手里有锤子看什么都是钉子 看山不是山：厌倦了模式的嵌套，对曾经的设计深恶痛绝 看山还是山：写完代码后恍然发现，哦，我这里用了xx模式啊 我觉得这篇文章洋洋洒洒，不过是一句“会者不难，难者不会”。我倒觉得初学者应该大胆地用模式，踩过坑了跌得疼了才有后期的返璞归真信手拈来。

很多东西都可以归结到『会者不难，难者不会』，你这里的『总结』和文章中提到的抽象和具体差不多，说一句『会者不难，难者不会』对其他人没太多帮助，只有具体化讲清楚才能让读者真正理解为什么

[love477]

都是经验的沉淀，但是很多东西未必适合当前的问题，没有理解透彻用起来就很奇怪。
《重构》真的很赞

[IronCity]

@PasserbyX7 设计模式之三重境界 看山是山：手里有锤子看什么都是钉子 看山不是山：厌倦了模式的嵌套，对曾经的设计深恶痛绝 看山还是山：写完代码后恍然发现，哦，我这里用了xx模式啊 我觉得这篇文章洋洋洒洒，不过是一句“会者不难，难者不会”。我倒觉得初学者应该大胆地用模式，踩过坑了跌得疼了才有后期的返璞归真信手拈来。

@PasserbyX7 设计模式之三重境界 看山是山：手里有锤子看什么都是钉子 看山不是山：厌倦了模式的嵌套，对曾经的设计深恶痛绝 看山还是山：写完代码后恍然发现，哦，我这里用了xx模式啊 我觉得这篇文章洋洋洒洒，不过是一句“会者不难，难者不会”。我倒觉得初学者应该大胆地用模式，踩过坑了跌得疼了才有后期的返璞归真信手拈来。

总结到位

[feng99]

@yanjinbin 哈哈 特地来赞同下，很反感设计模式拿来做面试考察内容。 一说设计模式，大都老JAVA了 2333 。 见过有更风骚的拿反射来写业务代码。 简单的设计模式有他的适用性，复杂的设计模式，有些看起来很拙劣

用反射实现业务代码 有和问题呢? 性能问题? 还是代码可读性问题?

用设计模式做面试考察内容 常问的也不过就是设计模式六大原则, 加单例模式 工厂模式 偶尔问个观察者 这些都是实际工作中常用的设计模式呀 拿来面试 都是基础 也没啥.

[yanjinbin]

@yanjinbin 哈哈 特地来赞同下，很反感设计模式拿来做面试考察内容。 一说设计模式，大都老JAVA了 2333 。 见过有更风骚的拿反射来写业务代码。 简单的设计模式有他的适用性，复杂的设计模式，有些看起来很拙劣

用反射实现业务代码 有和问题呢? 性能问题? 还是代码可读性问题?

用设计模式做面试考察内容 常问的也不过就是设计模式六大原则, 加单例模式 工厂模式 偶尔问个观察者 这些都是实际工作中常用的设计模式呀 拿来面试 都是基础 也没啥.

反射你不觉得不直观 不清晰 不clean么？为什么要用反射这种运行时能力呢？ 设计模式你说的不是和我说的差不过

[feng99]

@yanjinbin 哈哈 特地来赞同下，很反感设计模式拿来做面试考察内容。 一说设计模式，大都老JAVA了 2333 。 见过有更风骚的拿反射来写业务代码。 简单的设计模式有他的适用性，复杂的设计模式，有些看起来很拙劣

用反射实现业务代码 有和问题呢? 性能问题? 还是代码可读性问题? 用设计模式做面试考察内容 常问的也不过就是设计模式六大原则, 加单例模式 工厂模式 偶尔问个观察者 这些都是实际工作中常用的设计模式呀 拿来面试 都是基础 也没啥.

反射你不觉得不直观 不清晰 不clean么？为什么要用反射这种运行时能力呢？ 设计模式你说的不是和我说的差不过

反射 的确不够清晰 代码可读性降低 Java里的注解 一样会造成代码可读性降低,但是用起来真的很爽呀, PHP8 也要直接注解了 还有各种异步回调函数 闭包函数 但这些都是常用的,或者不得不用的写法. 如果反射不好,那java php golang为何都支持反射呢 就是为了用更少的代码 做同样的事

设计模式是某些特定场景的解决方案 用代码结构复杂度换取代码修改灵活度. 掌握常用的就行,也不用走火入魔.

[yanjinbin]

@yanjinbin 哈哈 特地来赞同下，很反感设计模式拿来做面试考察内容。 一说设计模式，大都老JAVA了 2333 。 见过有更风骚的拿反射来写业务代码。 简单的设计模式有他的适用性，复杂的设计模式，有些看起来很拙劣

用反射实现业务代码 有和问题呢? 性能问题? 还是代码可读性问题? 用设计模式做面试考察内容 常问的也不过就是设计模式六大原则, 加单例模式 工厂模式 偶尔问个观察者 这些都是实际工作中常用的设计模式呀 拿来面试 都是基础 也没啥.

反射你不觉得不直观 不清晰 不clean么？为什么要用反射这种运行时能力呢？ 设计模式你说的不是和我说的差不过

反射 的确不够清晰 代码可读性降低 Java里的注解 一样会造成代码可读性降低,但是用起来真的很爽呀, PHP8 也要直接注解了 还有各种异步回调函数 闭包函数 但这些都是常用的,或者不得不用的写法. 如果反射不好,那java php golang为何都支持反射呢 就是为了用更少的代码 做同样的事

设计模式是某些特定场景的解决方案 用代码结构复杂度换取代码修改灵活度. 掌握常用的就行,也不用走火入魔.

有点尬，我说的是反射不应该在业务代码中过多使用。 反射没有不好，只是在go语言里面，函数编程handler能做好Java的事情了。 go proverbs 提倡的原则是 reflect is never clear. ,出自rob pike，见仁见智哈，也不一定对。

[shadowdsp]

另一部分是迭代子模型、命令模式和解释器模式等不容易被理解的复杂模式

是 迭代器模式 吗？

[ficapy]

这篇文章实在是过于误导读者，首先放出google 趋势几张误导性的图片，你不妨用谷歌趋势搜搜计算机网络，computer system, C语言，C++, 我能猜想到的是很多古老的知识点搜索趋势都是这个趋势，可能是因为计算机行业新出了很多新的名词，这些名词占据了老名词的搜索机会。

另外一方面设计模式一书写与1995年，那个时候的语言和现在的语言差距非常大，更有甚者用JAVA的设计模式写法套在动态语言里面(真WTF, 而且还好意思出书)

其实最主要的是，有太多的无良作者，营销号，博客作者(可能他们本身没有恶意)，Python火热，经常能看到有书用python描述设计模式，然后照搬java的写法。市面上的书大多如此，可能写书只是为了出名，他们没有自己的思考，或许自己代码量都没有三十万行就敢去写书卖弄学问，他们拿着万年不变的例子，鸡呀，狗啊etc, 生活中的例子，反正就是不能拿出实际开发中的案例。毁人不倦

我相信设计模式不是没有用，只是缺少好的教材罢了 目前我看到的一本不错的设计模式书籍是： AlloyTeam出品的 《JavaScript 设计模式与开发实践》 虽然我挺少写js, 但是我能看出这本书和其他垃圾设计模式的书有很大不同，结合语言特性，结合实际，而不是硬翻JAVA

[draveness]

@ficapy 这篇文章实在是过于误导读者，首先放出google 趋势几张误导性的图片，你不妨用谷歌趋势搜搜计算机网络，computer system, C语言，C++, 我能猜想到的是很多古老的知识点搜索趋势都是这个趋势，可能是因为计算机行业新出了很多新的名词，这些名词占据了老名词的搜索机会。

重新搜索了你提到的几个关键词，你对数据的猜想是部分正确的：

• 计算机网络、computer system 和 C 语言这三个关键词趋势一直在下跌
• C++ 搜索趋势不变

搜索量变少了可以证明关注度和热度变低了，文章中没有给出除了热度下降的其他结论，但是我不认为可以凭猜想推出『可能是因为计算机行业新出了很多新的名词，这些名词占据了老名词的搜索机会』的结论。

另外一方面设计模式一书写与1995年，那个时候的语言和现在的语言差距非常大，更有甚者用JAVA的设计模式写法套在动态语言里面(真WTF, 而且还好意思出书)

其实最主要的是，有太多的无良作者，营销号，博客作者(可能他们本身没有恶意)，Python火热，经常能看到有书用python描述设计模式，然后照搬java的写法。市面上的书大多如此，可能写书只是为了出名，他们没有自己的思考，或许自己代码量都没有三十万行就敢去写书卖弄学问，他们拿着万年不变的例子，鸡呀，狗啊etc, 生活中的例子，反正就是不能拿出实际开发中的案例。毁人不倦

稻草人谬误（Straw man）[1]：攻击对方并未提出的论点。

这跟文章观点有什么冲突么，是我没写还是你没看？

我相信设计模式不是没有用，只是缺少好的教材罢了

一厢情愿（Wishful thinking）[2]：由于自己希望某事发生，因此主张（或相信）某事是真的；或由于自己不希望某事发生，因此主张（或相信）某事是假的。

我相 XX 不是没有用，只是缺少 XXX 罢了

[1]: Straw man https://en.wikipedia.org/wiki/Straw_man [2]: Wishful Thinking https://en.wikipedia.org/wiki/Wishful_thinking

[shhdgit]

提一个我的感受，设计模式这本书对于经验较少的工程师来说是一本实践大全。 经验较少的工程师看这本书的时候并不会像没有经验的工程师那样认为这本书过于抽象（这么多的抽象场景在另一个角度看不就是大量的例子吗），并且可以通过这本书里这么多的场景和例子总结归纳各个模式在什么场景下是怎么样压缩/转移信息量来帮助系统维持稳定状态的。对提炼场景与信息之间的结构关系帮助很大，结合本书来学习效率 up⬆️。从这个角度来看对于设计学习的帮助还是很大的。 一丢丢愚见，还在学习的路上。

然后我发现一些现象，好多工程师会理直气壮地避开 DDD、TDD、设计模式的学习，可能他们是因为过早的看了“没有银弹”系列文章，以为“没有银弹”指的是没有用。我现在觉得“钉子锤子”与“没有银弹”是两个极端...都应该避免。

推荐一篇关于“没有银弹”的文章：http://www.uml.org.cn/oobject/200509141.htm

[haoel]

设计模式非常有用。对于访问者模式，k8s 用的很好的：https://coolshell.cn/articles/21263.html

[draveness]

@haoel 设计模式非常有用。对于访问者模式，k8s 用的很好的：https://coolshell.cn/articles/21263.html

这里的设计模式，和文章提到的《设计模式》其实是两个东西

@shhdgit 提一个我的感受，设计模式这本书对于经验较少的工程师来说是一本实践大全。 经验较少的工程师看这本书的时候并不会像没有经验的工程师那样认为这本书过于抽象（这么多的抽象场景在另一个角度看不就是大量的例子吗），并且可以通过这本书里这么多的场景和例子总结归纳各个模式在什么场景下是怎么样压缩/转移信息量来帮助系统维持稳定状态的。对提炼场景与信息之间的结构关系帮助很大，结合本书来学习效率 up⬆️。从这个角度来看对于设计学习的帮助还是很大的。 一丢丢愚见，还在学习的路上。

然后我发现一些现象，好多工程师会理直气壮地避开 DDD、TDD、设计模式的学习，可能他们是因为过早的看了“没有银弹”系列文章，以为“没有银弹”指的是没有用。我现在觉得“钉子锤子”与“没有银弹”是两个极端...都应该避免。

推荐一篇关于“没有银弹”的文章：http://www.uml.org.cn/oobject/200509141.htm

文中的观点我觉得写得很清楚了，不排除一些人通过这本书得到了『顿悟』，但是对于作者来说它造成的困惑更多，所以如果要学习设计模式不如到开源项目中、在实践中学习，没必要去翻这本书。

[Yunfei-hub]

@wellls

@draveness

想要学习设计优秀的软件，其实可以看看 SICP 或者 HTDP 。

SICP 是一个不错的起点，能改变对编程这件事情的理解，尤其是对仅使用 OOP 的工程师

SICP 很早就加入在读书清单里面，不过之前在知乎看到很多回答说此书耗费时间非常长，一直望而却步，可能现在也要看一看了。

可以看看 Python 或者 JavaScript 版本的，精简很多，思想不变。

请问 python 或者 javascript 版本, 有对应的具体书吗？还是网上开源的文章？

[WyattJia]

按照对应的关键词，搜索一下，很容易找到的。😊

On Thu, Apr 1, 2021 at 06:41 Yunfei Guo @.***> wrote:

@wellls https://github.com/wellls

@draveness https://github.com/draveness

想要学习设计优秀的软件，其实可以看看 SICP 或者 HTDP 。

SICP 是一个不错的起点，能改变对编程这件事情的理解，尤其是对仅使用 OOP 的工程师

SICP 很早就加入在读书清单里面，不过之前在知乎看到很多回答说此书耗费时间非常长，一直望而却步，可能现在也要看一看了。

可以看看 Python 或者 JavaScript 版本的，精简很多，思想不变。

请问 python 或者 javascript 版本, 有对应的具体书吗？还是网上开源的文章？

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/draveness/blog-comments/issues/193#issuecomment-811512711, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBO2DEBEYCV3S324TFFG7TTGOQLDANCNFSM4LWTKK3A .

[yanjinbin]

大佬 读的书 豆瓣有记录不 想关注偷学下😄

[draveness]

@yanjinbin 大佬 读的书 豆瓣有记录不 想关注偷学下😄

哈哈哈，不用豆瓣

[XhinLiang]

@draveness

@ficapy 这篇文章实在是过于误导读者，首先放出google 趋势几张误导性的图片，你不妨用谷歌趋势搜搜计算机网络，computer system, C语言，C++, 我能猜想到的是很多古老的知识点搜索趋势都是这个趋势，可能是因为计算机行业新出了很多新的名词，这些名词占据了老名词的搜索机会。

重新搜索了你提到的几个关键词，你对数据的猜想是部分正确的：

• 计算机网络、computer system 和 C 语言这三个关键词趋势一直在下跌
• C++ 搜索趋势不变

搜索量变少了可以证明关注度和热度变低了，文章中没有给出除了热度下降的其他结论，但是我不认为可以凭猜想推出『可能是因为计算机行业新出了很多新的名词，这些名词占据了老名词的搜索机会』的结论。

另外一方面设计模式一书写与1995年，那个时候的语言和现在的语言差距非常大，更有甚者用JAVA的设计模式写法套在动态语言里面(真WTF, 而且还好意思出书)

其实最主要的是，有太多的无良作者，营销号，博客作者(可能他们本身没有恶意)，Python火热，经常能看到有书用python描述设计模式，然后照搬java的写法。市面上的书大多如此，可能写书只是为了出名，他们没有自己的思考，或许自己代码量都没有三十万行就敢去写书卖弄学问，他们拿着万年不变的例子，鸡呀，狗啊etc, 生活中的例子，反正就是不能拿出实际开发中的案例。毁人不倦

稻草人谬误（Straw man）[1]：攻击对方并未提出的论点。

这跟文章观点有什么冲突么，是我没写还是你没看？

我相信设计模式不是没有用，只是缺少好的教材罢了

一厢情愿（Wishful thinking）[2]：由于自己希望某事发生，因此主张（或相信）某事是真的；或由于自己不希望某事发生，因此主张（或相信）某事是假的。

我相 XX 不是没有用，只是缺少 XXX 罢了

[1]: Straw man https://en.wikipedia.org/wiki/Straw_man [2]: Wishful Thinking https://en.wikipedia.org/wiki/Wishful_thinking

其实文章中多次提到『没用的设计模式』，『分析作者为什么觉得设计模式没用』。 如果这里的『没用』能用引号引一下的话，可能就不会有这么多分歧了。