※ 引述《del680202 (HANA)》之铭言：
: ※ 引述《neo5277 (I am an agent of chaos)》之铭言：
: : 纯粹对工作上来说
: : 好抽换，好接手(易阅读)，好维护(包含升级，测试
: 好接手，易阅读…
: 我想到一个故事
看到你的故事，让我想起好多当年犯过的错误
: 几年前有个同事，号称国中时期就开始接案写代码
: clean code,DDD滚瓜烂熟,对coding极度洁癖
: 印象比较深的是入职时说了句：我看到不规范的代码会非常生气
我年轻的时候也这样，但做久了慢慢可以理解凡事都是 trade-off
写得很漂亮，却没商业价值的 code，根本没人在用，
对比写得很乱，却实际有大量使用者的 code，很难说哪个是比较好的。
刚进业界第一份工作，很认真的帮每个 function 写满注解跟 API doc，
努力遵循各种 best practice，几个月后专案取消了，这 code 从来没上 production
对比那些可怕的 legacy code，每天都好好的运行着赚钱的服务。
后来开始懂得要考量 business 的需求，有时候牺牲一点品质，抢占先机是必要之恶
: 上工第一案子，设计一个工具网站，拆了七个GitHub repo
这我当年刚学 git/github 也做过，把个巨大专案拆了十几个 repo，
原先要解决的问题是，希望每个元件可以降低耦合，容易独立使用，分开 deploy。
随着时间，逐渐发现各个元件需要共用的东西越来越多，互相 dependency 逐渐变多
这时候各个元件之间需要正确的版本，才能互相搭配，管理起来却成了噩梦
有些直接 include 就能用的东西，拆在两个 repo 挂 submodule 变得很难维护
build rules / makefile 也因此复杂了起来，最后有点后悔一开始把他们拆开。
体验过就能理解为何很多大公司最后走向 monorepo 架构，全公司专案都在一个 repo
其中一个经典案例就是 google，几乎全公司所有 code 在一个巨无霸 repo 内。
不同程式互相引用，就少有版本管理问题，开发的复杂度降低很多。
: Micro services, grpc当年流行的工具全套了一轮
: 说是将低耦合，高内聚做到极致
刚进业界的时候，我也是刚学了 microservice，很开心地把手上系统全拆了
拆分得很干净，每个服务都可以分开扩展，一开始还觉得这是 best practice
后来学到血泪教训。因为业务的改变，需求大幅度改变了。原先的拆分并不合适
反而让开发、测试、跟部署变得复杂，印证了 "monolith first" 的建议!
在早期需求还不明朗的时候，全部塞在一起，其实不是坏事，延迟到真正出现扩展需求
再来拆分，会比过早拆分要好。这跟不要 premature optimization 感觉很像。
就跟一开始学 OOP 都狂写 interface，后来才发现根本没有其他 implementation
白白多了一堆无谓的继承，最后又发现需要不同的行为，于是换了 interface
本来定义的抽象化不但没用到，还因为要保持相容，造成日后扩充的阻碍。
后来就学到 "concrete first"，不要起手式就急着开 abstract interface，
可以延后到真的有需要再来做，有时候反而会更合适。
做久了慢慢对这些东西有不同的感受，best practice 通常要放在特定情境下才是 best
如果很清楚自己做了什么 trade-off，违反它们不见得是错误的。
: 其中一个repo 甚至只放了一个utils
: 后来来了另一个人接手
: 改个功能要先看懂七个repo之间关联，跟找大秘宝似的
: 在review code阶段，还埋个彩蛋，发现了隐藏的第八个repo
: 新来的同事说改不动了，就算加个menu都很麻烦
: 心一横，提案该网站功能也不复杂，全部打掉重做
: 就自己埋头花了两周重做了那个网站加迁移
两个礼拜是不是没算到写 test 跟重作 QA 的时间 XD
写 code 相对快，大部分开发时间本就都花在其他地方
这种大霹雳式的重写，通常是很危险的 XD
: 工程师追求的很简单，(自己）好阅读，（自己）好维护就行了
:

简单一句话: 不要过早完美化。技术服务业务，随服务演进

PCMAN大神

只能推

on demand做 而refactor的时候需要test避免你改错That's why unit tests are important

确实

感谢大大分享

写不写的漂亮与市场反应是两件事情 这与公司经营和高层思想才有关系 写的好不代表一定花时间但为了不让资本嚣张 我赞同有时可以这么做

我认为 一个专案的基础架构 开发蓝图 工时 要能准确估算跟执行真的都需要高度经验工作而言 重要的事是怎么在日期限制内交出及格的作品什么要取舍 什么一定要做到

有时也不一定是资本嚣张 是高层嚣张

推这篇，句句是实务

至少你走过来了，辛苦了

推大神

上古神兽推推

推，虽然层级有差但鲁蛇做久了感想完全一样

感谢分享 看完觉得茅塞顿开

最近也有这种感觉，会开始要求自己做到best practice，但老实说这是必经之路吧，经历过凡事都要求完美的路，才会知道哪些可以放弃不用

大神推推 都是血和泪的教训

推

best 根本就不存在，完全是商业手法的误导，欺骗初学者以为只要看到 best 学就对，自己就会变成 best这个世界只有 suitable practice ，最合适的，没有最好的

很多都这样 一开始能动最重要，真的有闲稳定下来后才是重构的部分

神兽来了快拜一下~~~interface 还是看语言跟框架用啊

推这篇，这几年工作下来的经验也是如此，尤其碰到专案需求变动快速的时候，这篇的经验会更实用

interface 跟 DDD 就是互相成就遵从到后来都魔怔了，一堆过度设计的场景

先存活下来再想着如何变好但活太久改不动就又是另外一回事了QQ

推这篇~很有同感+1

推

推推

认真分享，给推！

那些指导的书看一本就好, 程式写多了就有自己的体会再看那些书也有不同的体验

神出没

谢谢前辈分享

神来了，必须盖楼推!

trade-off

大神要拜一下 感谢分享

显灵

只能推了

大神出没，推一个！

推

推推

居然是PCMAN，给推

推

推，好奇问，那如果是为了 UT 而弄的 interface 呢?

PCMAN!!!!!!!!!!!!!!!!!

推

其实最主要的问题在于 工程师都很自闭的自己搞东搞西像这些经历 是不是当初在拼了命分拆小模组前 召集团队所有人开个会蕉流蕉流 应该就有资深的会跟你说 确定要这样吗

资深不代表有决定权 end

设计本来就没有圣杯 大家吵架出来的就是最佳解 至少团队里的人都方便 这样就行了 不同团队有不同作法但工程师喔 大多都觉得太麻烦了 太无聊了 没空 别烦我 你说的我都不同意 我觉得XXXOOO就是最棒的 是尼不懂 哈不过就算乱写一通其实也没差啦 听说OpenAI里也全都乱写哪有时间code review吵架 东西先上先赢R 抢快比什么都重要

推推推

可是吵架很累馁我水瓶，我爱好和平有吵架以外的方法吗？

有 那就是长官或资深说怎么做 你就怎么做

好吧！那看状况吵好了

大神推

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

推

PCMan推一个

推大神

Google用内部工具Blaze直接否决高耦合 才能不吵架

那基本上就算是长官或资深说你要怎么做 你就得怎么做XD

深有同感

推神兽

推

oop重点写接口做啥？会写的直接上手

看需求吧 有场景是要把code喂给编译器看那就另当别论

推

该怎么切没有个圣杯，但核心就是要为爽跟快爽 = 好维护好追问题，快 = 开发不会相依性一堆绑手脚虾拆但是会往反方向前进的，就是吵 = =

推

有时候写interface是怕把依赖方向搞烂 有建议吗

大神推推

推推

好猛

推

谢 strlen，gino0717，TaiwanUp，shortoneal4位大大提供的方向

谢谢大大分享！讲的超清楚

朝圣

推

推

推

谢分享

推，这些真的是慢慢工作才会理解到的

推

推

感谢分享

按需求服务 还有渐进式的抽出共用

但c#要mock的话不是一定要interface吗？ 不测试的话的确是不用interface啦

热爱尝试当下流行的新工具新理论的工程师，常常也是团队主力，很难找到理由阻止他们尝试新事物

推

好奇Google 那样要怎么管理不同套件之间的相依性？ 如果都要保持所有test全过的话 几乎不太可能推新功能？

推 这如人月神话所说，软件之中“没有银弹”

专业