这篇满有意思的，牵涉的主题很广，不过有些事情只有一句很难讲清楚
针对中间几点，分享一些我自己的理解
※ 引述《alihue (wanda wanda)》之铭言：
: 看到不错的文章 翻译分享一下
: 原文:
: https://chriskiehl.com/article/thoughts-after-6-years
: 翻译:
: 软件开发六年后我改变想法的事情:
: - 如果你的队友经验参差不齐，Typed languages 是比较好的选择
Typed languages 相对容易做程式码 static analysis，在还没跑起来前
就容易找到错误，一些常见的错误甚至有工具可以自动修正，对正确性有帮助
另外在文件不足的状况下，有时候知道参数和 return value 的类别，会比较容易
看出 method 的正确使用方法。
: - Standups 会议以注意新人来说是有用的
: - Sprint retrospectives 如果拿来做真正的流程修正(course correction)是有用的；
: 而不是一些敏捷/scum master 拿来浪费大家时间的
应该说 retrospective 本来的目的，就是用来检讨要如何做得更好。
不只是流程，有时后会发生交付的东西，和一开始要求的有落差，就需要厘清
团队的合作是哪个环节发生了问题，或是一开始的 user story 可能根本就弄错了
如果不能针对改进有建设性的讨论，只是流于形式，为开会而开会，确实浪费时间。
: - 软件架构比啥都重要。有好的抽象再烂的实作都不太会弄脏 code base；烂抽象或
: missing layer 可以让 code base 变成一坨屎。
所以在 refactor 或是帮 non-testable legacy code 导入新的测试的时候，
一个有用的策略，就是先添加 abstraction layer 再开始 (Refactor by Abstraction)
新增 abstraction 之后本来高度耦合的 code 就比较容易解开，变得好测试
: - java 没那么烂
: - Clever code 通常不是什么好 code；清晰好读(Clarity)的 code 最重要
一般 code 只会被写一次，但是后续会被接手的不同人读很多次，所以好读是必要的
除非 profiling 确认是效能瓶颈，才会用特别的写法去加速，否则可读性比较重要
如果一个 function 不是会执行很多次的热点，选效率差一点但好读很多的写法
对整体效能并不会有影响，不需要过早最佳化。
: - 烂 code 可以被以任何方式写出来 (in any paradigm)
: - 所谓的 best practices 是要看上下文，并非通用解。盲目追求会让你看起来像白痴
: - 在你不需要时硬去设计一个 scalable system，你就是烂工程师
这句话乍看比较武断一些，举个具体的例子，假设产品还在早期 proof of concept
阶段，商业模式都不确定，也还没跟潜在客户验证好可行性，这时候赶快做出来
赶快验证点子，如果不行赶快换方向才是最重要的。在这种阶段有很高的机率
几个月后这个专案(甚至公司)就不见了，好的工程师能够针对不同情况
手上有多少资源，做出最适合当下状况的设计。
例如 monolith first: https://martinfowler.com/bliki/MonolithFirst.html
太早为了 scalability 拆分大量不成熟的微服务，反而会有害之后的发展。
: - Static analysis 有用
: - DRY(dont repeat yourself) 是为了避免特定问题，并不是最终追求目标。
一般不喜欢 code duplication，重复的东西会尽量抽出来成 module / class /function
但有种情况例外，就是 unit test，test 的重点要一眼看得出在测什么，
如果抽出太多细节，反而要一直跳来跳去 trace 还看不出在测什么，这时候还不如
把重要的细节在每个 test case 都重复一次，让他一目了然 (DAMP principle)
补充: https://enterprisecraftsmanship.com/posts/dry-damp-unit-tests/
: - 一般来说 RDBMS > NoSql
: - Functional programming 是另一个工具，不是万用解/灵丹
: 一路走来坚持的观念
: - YAGNI, SOLID, DRY 请按造这个顺序
: - YAGNI:You aren't gonna need it
: - SOLID: 某个 OO 原则（单一功能、开闭原则、里氏替换、接口隔离、依赖反转）
: - DRY: dont repeat yourself
: - 纸笔是最好的开发工具但很少人用
在一开始最前面的设计阶段，用纸笔画系统架构，或是假想的 UI，确实很方便!
: - 用干净/可读(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 品质完全没差
这样讲是比较夸大，test coverage 高品质未必好，但是过低品质确实需要担心
重点不是 coverage 有多少 %，而是你测试了什么 scenarios，是不是有包含到
最重要的功能，是不是连 error handling 都有测试到，这会比较重要。
要伪造很高的 coverage 数字很简单，把一大堆 code 包在一包让他全跑，然后
assertion 的时候检查一个超宽松的条件，这样看起来就会 coverage 100% 了
所以重点确实不是 coverage 多高，而是你测了什么
: - Monoliths (大概指微服务的反面)系统在大部分情境都是很好的
推荐参考 monolith first: https://martinfowler.com/bliki/MonolithFirst.html
如果有好的 abstraction，都是照 SOLID principle 开发的话，就算是 monolithic
日后需要拆分服务是不至于太难拆，问题就是不良的架构跟写 code 习惯，
把东西全部黏在一包，光一个 class 的功能就拆不开了，更不要说拆服务了
: - TDD 主义者(purists)是最糟糕的存在，他们的脑不能理解现实中存在不同的 workflows
TDD 虽然被很多人批评，但我自己使用的感觉他也有很方便的时候
举例来说如果你原本就有 test case，你想要稍微调整现有 class 的行为
那先针对预期行为的改变去调整 test case。或是新增对应的 test case 这是很直觉的
例如你要实做一个新的 RESTful API，input / output 都订好很清楚，这时候先写
test case 完全没问题，而且很直觉也方便。
反之如果你对于 class 该怎么拆分，或是一些细部的设计还没想好的时候
强迫要先写 test 这个就真比较违反一般人的直觉，执行上很困难
我们不一定要信 TDD，但可以撷取他们的优点，有两点我觉得很重要：
1. 透过先写 Test 你可以“试用”你设计的 API，早期发现 API 设计缺陷
这比都实做完了才发现 API 超难用才要修正要好很多，这个想法很有价值
2. 一定要先跑 test 确认在还没实做的时候，test case 真的会 fail
我自己被这个救过几次。举例来说有些 test framework 会找 function 名字有
test 开头的来跑，有一次我打错名字成 tset，导致这个 test 根本没测到
就很开心的 pass 了，殊不知那段 code 是有问题的，却根本没测到
或是设计的 test case 是有问题的，出错根本不会 fail...
TDD 可以非常有效的预防这种状况，而且这种状况是真的会发生。
以上延伸原文，分享一些个人浅见，希望有帮助，欢迎各位先进不吝指正补充