@shaoyaoju 同学，我总结的几条里，也没说是因为觉得 “你是为了讨谁的喜” 呀

@lakehylia
我想尝试课代表：
1. 标题就是傍大腿装逼的风格。其实 apache 项目要分三六九等，进入 apache 未必就是真的牛逼的东西
2. 文章内容拖沓，找不到重点干货，更适合去做 PPT 忽悠老板然后给自己升职加薪，详情参考《沙漠骆驼》新东方年会版。踏实做技术的本分人，没几个不烦这种 PPT 技术达人的
3. 一个使用 antd 开发的 dashboard ，功能通常不会比很多公司的管理后台复杂，这玩意本身确实不牛逼
4. 年纪不大，语气是成功人事高高在上，少年非要装老成却又并没见到真正牛逼的点，肯定不讨喜
5. 而且说白了，这就是个间接的推广软文，我不反对推广干货，但是实在没看到干货，所以就烦了

要是像隔壁 3 年的同学一样谦虚 /t/858318 ，没人会在这里喷 OP ，而且隔壁 3 年的同学已经很牛逼了，对比之下，OP 这个标题、自己的实力和行文的口气，真忍不住想喷

下一个工作还是用 go 做数据库内核吗？ PingCAP 那样 go 还是做周边比较好

@monetto c++的语法语义复杂度已经是编程语言天花板了，应该改名叫 Mediterranean Lang 。。。

明白人好好跟这说话根本没人信，全去信道貌岸然西装革履说话像心理按摩一样的所谓大能架构师布道师了。国内的 KPI 环境，尤其阿里为主带头搞这种文化的企业，踏踏实实本本分分做技术的人里，有多少被这种 ppt 架构师坑的，然后 ppt 架构师踩着老实人肩膀爬上去留一地鸡毛给老实人擦屁股，新东方版的《沙漠骆驼》听过吗？

就像早年的 ACE 框架一样，圈子里广泛流传一句评价：学之者生，用之者死

微服务、中台也是类似，只是如果能实事求是地运用，也不至于死。但是大多数人都做不到，大多数人都是盲目跟风胡乱拆分一通服务，然后呢，横向上服务数量增加了，纵向上调用链条增加了，开发流程图变复杂了，人力增加了，运维复杂度增加了，遇到问题时排查难度恢复难度增加了——我不是说所有的微服务都不合理，但多数团队都是东施效颦成了这种，除了程序员吹了一波自己技能点，更大程度就是重复制造垃圾代码、浪费电

你可以对比下隔壁的技术分享：t/855914
再看看你的文章里有多少有用的干货，你的帖子标题我前面就解释过了

少点假大空，少点 ppt 架构师，没啥有用的贡献还拿很多钱并且坑队友误导社区

你要非觉得是人身攻击那就是吧，就像你认为“每个微服务要有自己独立的数据库”一样，你觉得好那你就觉得好呗


“这观点就很武断，滴滴、阿里哪个业务稳定，哪个变化不快，为啥非要稳定的传统企业才能用中台
很多中台搞不起也不单纯是技术的问题，组织结构上就很难支持”
——你是真觉得阿里中台很成功是吧，中台也好、微服务也好，多搜几个“阿里 中台”关键字的文章看看再来反思自己的技术吧，你看看说它好的有几个、不好的有几个，如果真的好，会是这种局面？

另外别觉得中台没有失败，只是老板们总不能自己打自己脸因为自己代表着集团，随便承认错误资本也是不答应的，因为还有声誉、公信力、股价各种，所以委婉地低调转变罢了

从你的文章和回复中，我知道你也是个受害者，自己并没有深入体会，甚至别人都船掉头了你还在顺着人家的轨迹继续驶向深渊。所以我说你们人云亦云垃圾架构师，没说错，但凡哪天你真的进阶了会发现我这是点醒梦中人，回头肯定要感谢我、至少是内心里感谢我让你在技术理解上少走了一些弯路

@AllenHua
很多事情不能怪企业，也不能怪用户。想想为什么”润“这么火其实就懂了。z-f 不制定好法律法规、不去落实监管，必然导致这种局面。最受不了的是各种思想都要小学课本就开始洗脑了，难道不洗脑我们就不爱这片土地了吗？我们热爱这片土地，但希望陛下也能把我们当成有自主思考和行为能力的人一样对待，等到真的你好我好大家好，用户不至于为了这点会费而舍不得，企业家也不需要再为了盈利问题而蝇营狗苟

@lotusp
“别夹枪带棒的人身攻击”
没想人身攻击，社区里确实是你们这些带节奏的“技术大能”太多了，对于小白，你们的很多“布道”都是在误导人。
我们招聘的时候就能遇到很多被你们洗脑了的技术人，或者团队里总是会有人被洗脑后，把我们的架构做的高耦合低性能且臃肿难看。

”就是像楼主这种只知道人云亦云拿来主义的垃圾架构师太多了，而且其中很多还喜欢“布道”，于是坑了更多人”
我前面说的这句，说的是实际情况，我不是针对阁下，我是针对所有像阁下一样的所谓“架构师”，如果觉得这算人身攻击，那也可以自省一下是不是需要把技术做得踏实、扎实一点再“布道”。或者，就思考、分享、讨论的帖子也行，不要那么信誓旦旦把自己说成成功经验、既定规范，比如帖子题目改成”关于微服务与数据库设计的思考“，然后大家来讨论，这都没毛病。

@lotusp

”讨论技术就说技术“
我在上一楼回复过：
“中台也一样，坑很多团队，真正适合的搞法是从实际出发，除非你家业务成熟稳定需求不怎么变了比如很多传统企业级的产品，否则就别鼓吹什么不知道实事求是的方法论了”
——我这个不是就技术论技术吗兄弟？

你自己看下这个帖子的标题：“为什么每个微服务要有自己独立的数据库？“　妥妥的推广软文带节奏的标题，你能保证每家业务都跟你讨论的技术选型适配吗？什么叫从实际出发？但凡脑回路正常点，也不会这么武断地来写出这篇文章。从来就没有什么大一统的技术框架，踏踏实实做事，少出来坑小白

还有逻辑问题："你搞不定不能一棒子打死就说技术不行"
你是怎么看出来我搞不定的呢。。。我照样搞微服务，但是不会像你这种千篇一律设计一种架构方案，而是根据实际情况去设计服务架构。


另外，你可能误解了什么是不会好好说话。我只是对帖子标题这种明显反智之类的言论不好好说话，并不是见谁喷谁。而且不管是前面的回复还是这个回复，我也不是虚空喷，讲了原因的，如果楼主看不出来，那更说明我对此帖不好好说话是对了

@AllenHua #85
"但事实是，我没在 B 站上花过一分钱"

好多国内的产品不得不承认，运营团队为了扩张让用户白嫖了很多，反过来助长了国内用户的白嫖心理，然后反噬运营方，公司挣不到钱难道永远供大家白嫖？资本家不是慈善家，慈善家但从做慈善的角度讲，实际能救助的效果可比资本家养活打工人对社会的贡献效果要小得多。要想共赢，大家都正常一点，企业也别老搞那么多鸡贼的运营套路，用户负担得起的那点小钱该充值就充值

一穷二白发展起来，自上而下的不规范、破坏规则钻空子，导致的是双输的局面，可能只有经济真正强大后、两三代人的更替才能从本质上好起来

好家伙，我直呼好家伙！

你要是先学的 go 后学的其他语言，那你的这种问题是不是会更多？

golang 火的依据+1