※ 引述《neo5277 (I am an agent of chaos)》之铭言：
: 纯粹对工作上来说
: 好抽换，好接手(易阅读)，好维护(包含升级，测试
好接手，易阅读…
我想到一个故事
几年前有个同事，号称国中时期就开始接案写代码
clean code,DDD滚瓜烂熟,对coding极度洁癖
印象比较深的是入职时说了句：我看到不规范的代码会非常生气
上工第一案子，设计一个工具网站，拆了七个GitHub repo
Micro services, grpc当年流行的工具全套了一轮
说是将低耦合，高内聚做到极致
其中一个repo 甚至只放了一个utils
后来来了另一个人接手
改个功能要先看懂七个repo之间关联，跟找大秘宝似的
在review code阶段，还埋个彩蛋，发现了隐藏的第八个repo
新来的同事说改不动了，就算加个menu都很麻烦
心一横，提案该网站功能也不复杂，全部打掉重做
就自己埋头花了两周重做了那个网站加迁移
工程师追求的很简单，(自己）好阅读，（自己）好维护就行了

推"寻宝游戏"！XD

确实，设计得乱七八糟但是连文件都不写

寻宝XDD

哇... 高内聚低耦合已经不知道多少年没听到了...

那依然是个很好的概念 只是要知道 过犹不及R

[自己] 是对的。

这种就Overengineering 我之前遇过一个同事也这样要维护这种code有够痛苦 跟意大利面code半斤八两

我最后trace code是用全域搜寻 懒得找定义了 根本找不到

这种设计以我的认知，根本不算好阅读好维护，有些人曲解这个意思了过度拆分本身就导致维护管理困难，要跨一堆专案来看更称不上好阅读，有的人会因为书上或个人的强迫症导致变成这样然后认为自己的东西很简洁干净

现在一堆人跟风什么都 DI，全部都是 interface 找不到实作，找到后也会发现99%根本只有一个 class实作，浪费后人多少生命时间。而且 DI 的存在不就是为了单元测试隔离相依？结果这99%写 DI 的专案里根本完全没有单元测试的专案！妈的写心酸的喔？

老实说我是觉得开发时程吃紧根本不用做什么interface功能稳定跟拆多少没太多关系...

这篇真的有写实

没文件的专案都是大便 文件很烂的专案跟大便没两样

推 寻宝游戏

太真实

寻宝游戏，笑死

over design 了

确实是过油不及啦 还是要抓平衡

我最怕遇到接手一大堆搞自动化Gen code的神人专案，每次要改都不知道从哪里改，结论就是一路摆烂到重构

如果改一个功能七个 repo 都要动，那叫做高耦合。高内聚低耦合不是这样搞的

DI并不需要拆interface，最基本的用途应该是让物件生命周期能跟着某个context又不用自己new，倒不完全是为了测试interface都是等有第二种实作再重构抽的

他可能以前是写ejb的…

我也遇过一个，做了三个月，产出0，整天跟人吵架

.NET的Mock Library几乎都只能Mock interface跟virtual method，不然我也不想弄这么多interface

改个东西要了解七大密宝叫什么低耦合？这完全是人的问题低耦合的标准 其实就看程式语言本身的功能就懂啦每天都在用一堆内建函式 完全不需要理解函式怎么运作的吧只要知道用它会发生啥事就好 每个模组就应该设计成这样没办法达成这种效果 低耦合都马自己讲所以之前才说 要搞敏捷 搞agile 搞clean code 搞设计模式不是你说了算 你说clean就clean？是要大家来吵架决定的真正好维护的code 就是团队紧密沟通（吵架）才弄得出来的但是齁 基本上工程师都马文人相轻啦 看不起别人 都觉得别人写得都垃圾 又自以为最聪明 其它人都低能 大头症工程师满街都是 这样态度要合作？要吵架？有得吵了 呵呵吵到最后还有EQ不好的开始砍人勒 怕爆

两周的工作量 可以弄到8个 也是人才

这个设计是为了以后团队成长到几万人在开发这个专案

很同意前几楼说的，DI本来可以方便测试，结果一个测试也没见到，XD

8个repo算少了，我接手过一个single page app快100 repo大量的DI，说要重复使用，各种抽换结果连angular升版都做不到，整个砍掉重做（原作者做不到）

拆越多通常问题也越多，比那种几千行的还难维护

寻宝游戏，笑死

功能本来就要做成显示调用 隐藏实作细节的没有不是垃

等到规模够大才有差

圾的 难以追踪也学不到东西 很可惜很多语言的DI是隐式的 好的程式就是minimal外加不写死保留点弹性简单来讲就是可爱 但不利不被取代 主要是做成lib而非弄微服务 这东西多数人用不到 全用http也很惊悚

这种就标准过度设计,杀鸡用牛刀...

这篇很写实XD

我超讨厌微服务的 服务够大就会拆部门了啊 等到那时候再拆就好了 除非是业务需求需要切出去 (例如某个服务预期会有大量流量要扩展) 现在一堆为拆而拆的 真的找 log 都跟在找大秘宝一样...

会写function+struct就很神了 真的 不止写code 还有一堆流程之神 加个三层检查才能进code, 解个bug开新branch 搞很多毛 有两层做的有效的话就很好了

cleancode前几页就说写程式是社交活动 然后他只会生气叫他会去重看

"是要大家来吵架决定的" XD

我自己是觉得不要眼高手低啦 能让你慢慢吵架写一个超赞程式的环境几乎不存在 大家平常忙死了谁要管你啊 如果你是香香妹子工程师那还愿意花点时间跟你交流交流 但平常遇到都马肥宅占九成 说个话都能闻到口臭 谁想蕉流所以还是照着团队的写法跟着写 绝不会错大家怎么写 你就模仿大家怎么写 不要在那边乱 标新立异要搞东搞西你的理想国自己side project爱怎玩就怎玩

桑原老师说过 架是要两个人才能吵的

这就是标准的over design看过书不可能做出这种东西

大祕宝XD

这个叫架构魔怔，设计时都会说扩充多方便，实际上扩充次数不到两次，然后要加个新功能极为麻烦重剑无锋，大巧不工，越是符合原生的应用，逻辑越简单又能达到目标越好，抽象注入太多一堆魔怔，最后都是只有原设计者看得懂，后人接到改个几次觉得很怪就重新打掉了，真正可以留下来后人会维护的code，反而都是没什么抽象的架构的code

over design 真的不行

就跟正规化一样 你过度正规化只会找自己麻烦而已且没必要

这只是你单纯没接手dependency management跟IDE吧2个礼拜能做出来的东西 如何over design到看不懂

推跟过度正规化一样+1

这叫the show

spring framework:.....我教的...

确实

凡事都加个interface,就spring 起的头，然后蔓延出去.

一个 repo 只放一个 utils 是三小!

关spring啥事？ 他实作通常不只一个好吗...

其实选对 IDE 这些都不算是问题拉 认真的大型专案,挂个十来个 dependancy 是家常便饭不要搞不清楚概念乱设计,那种对 clean 一只半解的才恐怖遇过那种一个 lib 做抽象,然后实践实作在各种 lib 中的垃圾,开新 method 没重复名称功能全凭运气

太多这种案例了 头很痛

spring写的通常实作确实一个居多 没什么多实作的应用情境的ide多专案切换就是个麻烦了 编译执行debug都是麻烦跨专案字串补全 搜档案都是

spring自己是很多interface，但用spring写东西根本用不到interface吧，spring的一个恶名不就是动态改你的class生成proxy，实际在跑的bytecode跟你写的东西不同吗?连直接呼叫的method都能被偷改了，干麻用inteface?

最多是替换实现 执行时改原来的类需要一些java底层知识 通常就只是外面套一层用反射去hack

搞不好他只是在练功 刻意练习

你是不是在臭某网红？

KISS

(自己)

只有一个git repo跟很多repo 我支持很多repo....All in one真的很恶心...