个人觉得左耳朵耗子、酷壳的多数内容，其实并不是好的技术文章。更偏散文风格，对于一些技术人有兴趣上的激励效果，但干货不多，甚至很多工程、技术观点是错的。
他文章的效果，就像他在阿里的成绩一样。
我对他个人没有意见，但是感觉他被太多小白过度吹捧了。

很久没见过这么自恋的人了

观察了段时间来反馈下：

@Meursau1T 手上还有个 s22 、但是本来电池就小、也升级了但是没出现 s24+这么明显的掉电，其他型号倒是没对比过

@Magicmadoka 卡顿倒是没觉得，可能因为我用的功能和 app 比较少

@lumia1020 @szzonly 我是去香港买的港行机器，港版系统没刷过

@xinxuyue 刚开始持续了有快一周，掉电非常快，然后恢复正常了到现在十多天还好。

总有些人，看不得国产越来越好，仿佛只要崇洋媚外多骂几句家里的不好、自己就能被白皮看得起了似的。

提前建议尔等，以后华夏越加强大的时候，做好心理准备，不要破大防让自己心理崩溃——哦哦对，你们这种人啊，也不至于心理崩溃，见风使舵左右逢源，没人比尔等更擅长跳来跳去的了。
是我不该替尔等多虑了。

@Reficul #88

> 我也不知道我现在交的那些税花哪去了

看着隔三差五的反腐新闻，动辄贪污几千数亿的大人们
还有体制内数量庞大的朝九晚五午休 2-3 小时的小吏们惬意的生活
......
我仿佛知道交的税去哪了

堆的 Pop 是弹出队首，不要把它和栈搞混了

当年想几千块外包做个淘宝的老板又出山了？

对付我这种人，最好的办法就是回去好好修炼内功，等 OP 真牛逼了、不再有这种错误的认知了、再出来传播的是牛逼的知识点的时候，我自然就拜服了，所以劝 OP 赶紧收了设计模式这神通吧

设计模式最初好像是被 GOF 那几人借鉴建筑领域搞的，建筑和软件虽然都是工程，也确实有很多可以借鉴之处，但是还有一个很大的区别，就是建筑领域的图纸方案是数学的物理的材料的定量的计算，更加规范，而且一经敲定很少需要在施工过程中再去大量更改需求和对应的方案的。软件则大不相同，从立项到完成，中间的产品需求和代码是分阶段输出，产品经理或者甲方改需求比 tm 40+男人尿尿还频，所以你根本没法像建筑领域那样图纸方案搞定后一铁锹干到底，而是得翻来覆去改代码改数据库改这个改那个的。

我不知道你是不是刘丹冰老师本人，zinx 代码我扫过几眼，其他一些比如 cellnet 也扫过几眼，讲真，这些培训机构老师也好、专职做知识传播的专家也好，工程实践的代码质量优秀的比较少，还差些火候，但是普及传播基础知识对于年轻人还是够用的，我很支持。设计模式这种糟粕，你就别跟我杠了。好些人拿大道至简嘲讽 go ，但你是做 go 的，相信你不会像他们那么肤浅，自己多反思下什么是大道至简更好。

@sanbenweiyang #9

我随便搜个帖子给你：
https://www.infoq.cn/article/design-patterns-proposed-by-gof-20-years-ago

摘抄一段：
```text
Gang of Four （简称 GOF ）似乎从一开始就将模式视为一种艺术 / 科学；在论著的最后一章（遗憾的是，读者们大多直接将其忽略），他们指出：

这本书的实际价值也许还值得商榷。毕竟它并没有提出任何前所未有的算法或者编程技术。它也没能给出任何严格的系统设计方法或者新的设计开发理论——它只是对现有设计成果的一种审视。大家当然可以将其视为一套不错的教程，但它显然无法为经验丰富的面向对象设计人员带来多少帮助。

但需要强调的是，实际情况在于：这本书中的模式设计理念尚未彻底完成。我在 DevelopMentor 上结识的一位朋友将设计模式称为“23 种指针使用方法”。好吧，似乎也有道理。

同样的，当管理层 / 高管团队将这本书甩给新手开发者并希望他们通过阅读实现技能“升级”时，结果也肯定会让他们深感失望。
```

你可以回头再看一下你举例的 linux 内核设计模式的站点：首先，这不是 linux 官方文档，而是其他人的总结；其次，这是针对 linux 内核而总结出来的，并不是 linux 内核根据 GOF 的设计模式进行的实践。

说道这里我不知道你有没有意识到自己对设计模式的理解存在的问题，如果没有，我进一步直接告诉你：你把设计模式与代码架构的先有鸡还是先有蛋的顺序搞反了（例如我上面解释了你对 linux 内核那个设计模式套过来做论据的错误）。

设计模式并不是只有 GOF 整理的这些，GOF 整理的这些也并不适合直接用于代码设计。设计模式的运用的最佳实践，应该是先有业务和代码，在实现以及发展的过程中，甚至是在日后重构的过程中，结合这个项目整理出项目本身对应的设计模式（实际上不只是整理设计模式，还应该整理项目的各种定义、规范等）。用既定的设计模式去设计架构、大型代码模块，只有一个大场景和很多小场景符合，大场景比如已经成熟的行业领域，比如传统企业级，已经多年深耕、架构、代码、模式成熟，所以当你从头再造一套，那些在这个领域已有的设计模式能帮助提高生产效率。小场景也是类似的道理，已有成熟的体系才行。而直接拿设计模式不分青红皂白往各种项目上套，八成制造更多屎山。

至于设计模式跟语言无关，那你可是更没理解到位了。比如单例，对于有全局变量或者全局静态变量的语言比如 c/cpp/go ，最简单的就是一个全局变量就搞定了，再多封装单例模式的 N 种写法也都是脱裤子放屁或者仅仅看上去接口 /方法的形式或许比变量更优雅而已（然而这种审美也是因人而异）。

总结起来，就是现有的代码实践，然后才有对应的整理出来的设计模式，如果使用这些模式去指导类似的业务或者逻辑的代码架构是存在一定合理性的，但生搬硬套是扯淡，尤其在这些年 IT 互联网行业高速发展、需求快速迭代的场景。这一点上，OOP 存在类似的问题，比如鸭嘴兽，比如快速迭代无法预测未来需求的快速变化，你在早起想在顶层设计阶段使用设计模式、OOP 做到日后的易扩展，简直就是痴人说梦。只有阶段性重构能真正让屎山改造成艺术品

明年还９天短，简直不知道该如何感恩

@ifdef 感谢支持，我马上复出！

求设计模式党和面向对象中毒党放过 golang ，不要把你们的魔爪伸过来，求求你们了

阿里已经有一帮毒瘤 javaer 搞了一些 go 框架来毒害社区了，求求你们拿到 KPI 后就不要再继续这种行为了

孩子们会中毒的！

坚决抵制！

求设计模式党和面向对象中毒党放过 golang ，不要把你们的魔爪伸过来，求求你们了

阿里已经有一帮毒瘤 javaer 搞了一些 go 框架来毒害社区了，求求你们拿到 KPI 后就不要再继续这种行为了

孩子们会中毒的！

老子键盘猛掉漆，
同事骂我奋斗比；
老子键盘按不对，
同事嫌我是累赘。
老子键盘弹钢琴，
老板不涨一分钱；
老子键盘上跳舞，
老板当我二百五。