[心得] (转)软件开发六年后我改变想法的事情

楼主: alihue (wanda wanda)   2021-08-31 21:45:42
看到不错的文章 翻译分享一下
原文:
https://chriskiehl.com/article/thoughts-after-6-years
翻译:
软件开发六年后我改变想法的事情:
- 如果你的队友经验参差不齐,Typed languages 是比较好的选择
- Standups 会议以注意新人来说是有用的
- Sprint retrospectives 如果拿来做真正的流程修正(course correction)是有用的;
而不是一些敏捷/scum master 拿来浪费大家时间的
- 软件架构比啥都重要。有好的抽象再烂的实作都不太会弄脏 code base;烂抽象或
missing layer 可以让 code base 变成一坨屎。
- java 没那么烂
- Clever code 通常不是什么好 code;清晰好读(Clarity)的 code 最重要
- 烂 code 可以被以任何方式写出来 (in any paradigm)
- 所谓的 best practices 是要看上下文,并非通用解。盲目追求会让你看起来像白痴
- 在你不需要时硬去设计一个 scalable system,你就是烂工程师
- Static analysis 有用
- DRY(dont repeat yourself) 是为了避免特定问题,并不是最终追求目标。
- 一般来说 RDBMS > NoSql
- Functional programming 是另一个工具,不是万用解/灵丹
一路走来坚持的观念
- YAGNI, SOLID, DRY 请按造这个顺序
- YAGNI:You aren't gonna need it
- SOLID: 某个 OO 原则(单一功能、开闭原则、里氏替换、接口隔离、依赖反转)
- DRY: dont repeat yourself
- 纸笔是最好的开发工具但很少人用
- 用干净/可读(purity)为代价换取实用性是个好方法
- 狂导入额外的技术不是好方向
- 直接跟客户/需求端理解需求会比较快又精确
- "scalable"这个词在码农中有股神秘的力量,仅仅这个字可以让他们陷入疯狂,然后仅
仅为了这个字可以做出疯狂的设计
有点难翻XD 原文:
The word "scalable" has a mystical and stupefying power
over the mind of the software engineer.
Its mere utterance can whip them into a depraved frenzy.
Grim actions have been justified using this word.
- 虽然叫工程师,但其实很多决策都是跟风(cargo-cult),并不是有严谨的分析、资料数
据佐证
- 大概九成的 PM 明天消失对你都没影响,甚至效率还会变好
- 当我做了一百场面试后: 面试方法彻底崩坏,我也不知道怎么做更好
没变的观念
- 会刁 code style, linting rules 或枝微末节的都怪咖
- Code coverage 跟 code 品质完全没差
- Monoliths (大概指微服务的反面)系统在大部分情境都是很好的
- TDD 主义者(purists)是最糟糕的存在,他们的脑不能理解现实中存在不同的 workflows
作者: bjk (Up2u)   2021-08-31 21:52:00
大部分都认同,感谢分享
作者: kvjo (同名专辑)   2021-08-31 21:59:00
大部分认同 看你PM价值 低价值PM如此vaulable的PM 明天消失 好像很清净 过几天就知道.更排山倒海
作者: gn01838335 (寂静的生存者)   2021-08-31 22:25:00
….有些结论太武断
作者: enthos (影斯作业系统)   2021-08-31 22:30:00
不同意纸笔。我说心眼(半小时全盲打)易于专心,但难练
作者: yamakazi (大安吴彦祖)   2021-08-31 22:33:00
Issue tracker很重要
作者: viper9709 (阿达)   2021-08-31 22:35:00
九成的PM明天消失对你都没影响www
作者: jack0204 (Jarbar王朝)   2021-08-31 23:06:00
GO是怪咖语言
作者: amiwry (肥墩墩大人)   2021-08-31 23:31:00
感谢翻译
作者: shooter555 (shooter)   2021-08-31 23:37:00
等你出名后 就能把这些拿来出书了
作者: MOONY135 (谈无欲)   2021-08-31 23:55:00
TDD为什么这么容易被唾弃啊
作者: k900421 (qq)   2021-09-01 00:13:00
能多解释java没那模烂这点吗?
作者: ian90911 (xopowo)   2021-09-01 00:15:00
感谢翻译
作者: RunRun5566 (跑跑五六)   2021-09-01 00:27:00
最后的 Code coverage 是指 Test Coverage 吗
作者: jete   2021-09-01 00:57:00
第一点跟刁linting是怪咖有矛盾啊
作者: umum29 (....)   2021-09-01 01:03:00
有些偏颇+1 直接面对客户会变成没防火墙 客户会不断改需求好的PM/scrum master是会带着整个团队往前冲其他大致同意 面试真的没有最客观的方法
作者: em1234 (em)   2021-09-01 01:17:00
PM那个一定是没遇过都扛屎缺的PM 没了屎缺大家分了
作者: taipoo (要成功要积极)   2021-09-01 01:34:00
谢谢翻译
作者: rotalume (rotalume)   2021-09-01 02:24:00
楼楼上,所以原文说九成没有说全部啊XD
作者: pttassassin (0)   2021-09-01 03:44:00
好奇TDD有啥特别的问题吗
作者: ga013077 (Daky)   2021-09-01 03:55:00
不错啊
作者: fantasychese (林阿宅)   2021-09-01 04:14:00
问题不是TDD是purist吧 任何xxx purist都要小心
作者: deangood01 (跨斯欧鹅)   2021-09-01 04:26:00
看到Sprint retrospectives 马上点about 嗯... 果然是Amazon的员工 觉得看看就好
作者: matyih (mat)   2021-09-01 05:02:00
6年的L5 看看就好
作者: rtoday (rtoday)   2021-09-01 05:17:00
看看就好+1
作者: WaterLengend (Leeeeeeeeooooooo)   2021-09-01 05:53:00
PM那个实在有够中肯
作者: nanashi07 (NaNashi)   2021-09-01 06:23:00
部份认同
作者: CoverMind (Goa ai Giok-Chin)   2021-09-01 07:39:00
看看就好+1 部分认同而已
作者: strlen (strlen)   2021-09-01 08:41:00
懒惰写测试就说 牵拖TDD干麻?
作者: brianhsu (坟墓)   2021-09-01 09:01:00
部份不认同,我自己的经验是确实 bug 好发在没有被 testcoverage 到的地方。然后 TDD 那个看程度,我猜他指的是那种非常坚持要先有test code 才写 production code 的状况。但实务上满多是先写一小段 production code,再补一小段 test code的。
作者: MOONY135 (谈无欲)   2021-09-01 09:23:00
楼上那个是莫非定律 你就是没想到会有bug的部分你的测试当然也是没写到了 所以总会出现在没cover的地方
楼主: alihue (wanda wanda)   2021-09-01 09:25:00
就跟写论文先有实验结果再回去写假设一样
作者: triplee (none)   2021-09-01 09:39:00
不需要时去设计scalable system 就是烂工程师 这点有点玩味 因为遇到的场景通常是你以为你不需要 结果日后碰到了才发现你的系统动弹不得 这篇文的背景跟观点应该是有绝对性的关联 跟之前另一篇分享个人觉得有差别10年工程师的酒后牢骚那篇
作者: brianhsu (坟墓)   2021-09-01 09:47:00
我自己是同意纸笔非常好用。画流程/架构图、简单的测资或 puesdo code,整理思或绪厘清问题都很好用又快速。很多时候纸笔整理完,就知道程式码要怎么写了。
作者: chuegou (chuegou)   2021-09-01 10:04:00
纸笔是整理思绪的好工具
作者: expiate (夜露死苦)   2021-09-01 11:01:00
推有心翻译
作者: geniusturtle (小龟)   2021-09-01 11:14:00
作者: molopo (mmm)   2021-09-01 11:49:00
推纸笔
作者: cunankimo (F5)   2021-09-01 12:22:00
大部份认同
作者: alongalone (沿着孤单的路)   2021-09-01 12:43:00
有战的潜力
作者: aa155495 (冷月狂刃)   2021-09-01 13:07:00
pm那段不完全认同
作者: kvjo (同名专辑)   2021-09-01 13:27:00
PM这段很简单 就把PM拿掉 过一些日子 还是会发现需要有个人PM是软能力大于硬能力的ROLE 本来就很难评估
作者: bnd0327 (阿噗噗)   2021-09-01 14:19:00
比较惊讶要花六年才相信静态分析有用
作者: zebraseven (Die walkuere)   2021-09-01 15:21:00
abstract 翻抽象怪怪的,翻成接口不是顺畅点?
楼主: alihue (wanda wanda)   2021-09-01 15:58:00
抽象是过程,接口是输出XD
作者: sunsamy   2021-09-01 16:38:00
敏捷/scum master是拿来浪费大家时间的
楼主: alihue (wanda wanda)   2021-09-01 17:02:00
没事还会在那玩小游戏而不是跳过会议
作者: polola6212 (Polo)   2021-09-01 18:21:00
极端TDD信仰者和重构之前不写Test Code都蛮麻烦的前者是不好合作,后者是在埋地雷
作者: yamiodymel (YamiOdymel)   2021-09-01 20:22:00
Scalable 那段是指很多人为了讲究“扩展性”而故意写微服务、K8S 或是用 MongoDB 这种 NoSQL。当初 MongoDB 的著名笑话就是:“我知道 MySQL 很好, But does itscale?”
作者: DrTech (竹科管理处网军研发人员)   2021-09-01 21:39:00
整篇废话用这篇逻辑来说就是:这篇是废话,但又没那么废话。
作者: jennya (Jennya)   2021-09-01 22:55:00
好文,推!除了PM那行不同意以外其他都同意;有遇过雷的PM但就算是雷的PM还是有帮RD做了不少沟通的事。最想推的就是YAGNI,有些RD为了他们自以为“未来会有的需求”而先写了“方便未来scalable的”的多余的抽象化,十年之后来看他们当初写的code,那些多余的抽象化都是从来没发生作用的废code,他们完全预估错了未来需求会发展的方向;而他们为了不需要的抽象化而多写的那些逻辑反而让程度中等不敢大刀阔斧砍code的后人、为了实现真正的需求而必须绕来绕去的东加西加,叠床架屋,很多逻辑变得绕,又再加上没有作用的抽象化code在干扰readability,明明可以很简单明了的东西最后却变得超杂乱。看完十年gitlog history,结论真的就是YAGNI,当下真的给进来的需求你再做,不要自以为可以预测未来,事实证明他们预测的没有一个命中,然后没自信或赶时间的后人不敢砍掉没用的抽象化,最后相关的module发展的歪七扭八盘根错节。假如当初不过度抽象化,就写最简单最初学者的那种架构,反而不会危害那么大。YAGNI!
作者: MDay56 (他妈妈冲击波)   2021-09-02 01:21:00
Java忽然就出现了谢谢分享翻译
作者: triplee (none)   2021-09-02 12:38:00
觉得jennya的例子比较像是失败的抽象而不是scalable的锅
作者: s0914714 (YA)   2021-09-03 00:23:00
认同t大说法 那应该是失败的抽象 过度抽象不至于那么惨但我也同意有需求再做就好 只是一发现有问题就得重构
作者: dein0522 (Dennis)   2021-09-03 00:40:00
monolith指的是公司主要的codebase,通常有几百万行程式码,因为美国大公司都可能有几万个工程师
作者: v9290026 (CH)   2021-09-04 14:08:00
我同意多数,学习啦
作者: bndan (seed)   2021-09-04 15:54:00
9成PM存在与否没差 这边的问题在于"设计"者承担了额外的工作 EX: 工作时间分配与责任 但这也很两难啦 把全部责任都堆PM上 在这部份和社会文化不合 这社会强调的是为自己做的事负责..分配工作做不完=自己有问题=>那设计者一开始就把自己的产能需求掐住 自己规化工作时程分配 => PM要他干嘛高度紧密合作(包含工作时程) VS 个人独立性 前者不被这文化选择...

Links booklink

Contact Us: admin [ a t ] ucptt.com