pastor

pastor

V2EX 第 581218 号会员,加入于 2022-05-11 10:50:15 +08:00
pastor 最近回复了
58 天前
回复了 SilenceLL 创建的主题 投资 存量房贷终于要降一点了,真是不容易
@Reficul #88

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

看着隔三差五的反腐新闻,动辄贪污几千数亿的大人们
还有体制内数量庞大的朝九晚五午休 2-3 小时的小吏们惬意的生活
......
我仿佛知道交的税去哪了
堆的 Pop 是弹出队首,不要把它和栈搞混了
2022-10-12 13:37:28 +08:00
回复了 dc2002007 创建的主题 程序员 求一款开源的应用商店技术方案
当年想几千块外包做个淘宝的老板又出山了?
2022-10-09 20:37:17 +08:00
回复了 sanbenweiyang 创建的主题 程序员 《Easy 搞定 Go 语言设计模式》(Golang 设计模式,如此简单)
对付我这种人,最好的办法就是回去好好修炼内功,等 OP 真牛逼了、不再有这种错误的认知了、再出来传播的是牛逼的知识点的时候,我自然就拜服了,所以劝 OP 赶紧收了设计模式这神通吧
2022-10-09 20:31:40 +08:00
回复了 sanbenweiyang 创建的主题 程序员 《Easy 搞定 Go 语言设计模式》(Golang 设计模式,如此简单)
设计模式最初好像是被 GOF 那几人借鉴建筑领域搞的,建筑和软件虽然都是工程,也确实有很多可以借鉴之处,但是还有一个很大的区别,就是建筑领域的图纸方案是数学的物理的材料的定量的计算,更加规范,而且一经敲定很少需要在施工过程中再去大量更改需求和对应的方案的。软件则大不相同,从立项到完成,中间的产品需求和代码是分阶段输出,产品经理或者甲方改需求比 tm 40+男人尿尿还频,所以你根本没法像建筑领域那样图纸方案搞定后一铁锹干到底,而是得翻来覆去改代码改数据库改这个改那个的。
2022-10-09 20:24:30 +08:00
回复了 sanbenweiyang 创建的主题 程序员 《Easy 搞定 Go 语言设计模式》(Golang 设计模式,如此简单)
我不知道你是不是刘丹冰老师本人,zinx 代码我扫过几眼,其他一些比如 cellnet 也扫过几眼,讲真,这些培训机构老师也好、专职做知识传播的专家也好,工程实践的代码质量优秀的比较少,还差些火候,但是普及传播基础知识对于年轻人还是够用的,我很支持。设计模式这种糟粕,你就别跟我杠了。好些人拿大道至简嘲讽 go ,但你是做 go 的,相信你不会像他们那么肤浅,自己多反思下什么是大道至简更好。
2022-10-09 20:19:18 +08:00
回复了 sanbenweiyang 创建的主题 程序员 《Easy 搞定 Go 语言设计模式》(Golang 设计模式,如此简单)
@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 做到日后的易扩展,简直就是痴人说梦。只有阶段性重构能真正让屎山改造成艺术品
2022-10-09 16:40:14 +08:00
回复了 helloworld1024 创建的主题 程序员 之前觉得七天好短,现在觉得七天好长。。。
明年还9天短,简直不知道该如何感恩
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4887 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 09:43 · PVG 17:43 · LAX 01:43 · JFK 04:43
Developed with CodeLauncher
♥ Do have faith in what you're doing.