我曾与一些杰出的工程师共事过 -- 在诸如 FAANG 的大公司，也在初创规模的小公司。他们让我看到，传说中的「10 倍」工程师，真实存在！
如今，这些工程师中，有些人后来创办了自己的公司，他们领导的变革改变了我们对网络的认识（比如 Vercel！）；有些人成长为了大型科技公司数十亿美元项目的领导者。
为人编程，而非为电脑编程
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
（笨蛋也能写让计算机理解的程序；而优秀的程序员写的是人能理解的程序。）
Martin Fowler
他们总是会评估代码对所有用户的价值。哪怕漏掉了一个受众，代码也不会投入生产。
好的的工程师不拘泥于代码本身。
如果最终结果整体上会更好，他们会毫不犹豫地删除代码并重新开始，即使已经完成了 90%。
代码不是个人的，因此反馈意见也会被认真对待。
代码并不完美。没人在乎完美的代码，而应该在乎能带来改变的代码。
让自己学会不依赖于代码的最好方法就是认识到，20 年后，你的大部分代码很有可能会成为技术债务、被废弃或重写。
https://startuphustlenews.com/p/my-20-year-career-is-technical-debt
采用统一的标准
在编写代码时，要坚持统一的标准和风格。一致性能让你和团队更容易阅读和理解代码、让代码库更容易扩展。这也是 Meta 和谷歌等公司发布大量代码时，代码库不会随着时间推移变得无法阅读和维护的原因。
我认识的每一位优秀的工程师都将团队的代码标准内化于心，并尽可能严格遵守，因为他们深知这样做的好处。
谷歌有一个易读的流程，来保持代码的简洁。 谷歌已经开源了一些代码风格。 Meta 为其部分开源代码作了 C++ 风格规定。
https://github.com/facebook/hhvm/blob/master/hphp/doc/coding-conventions.md
花时间为团队规定一个代码风格，绝对值得。
阅读更多：
S - 单一职责 Single-responsibility principle (SRP)：
O - 开放封闭 Open–closed principle (OCP)：
L - 里氏替换 Liskov substitution principle (LSP)：
I - 接口隔离 Interface segregation principle (ISP)：
D - 依赖倒置 Dependency inversion principle (DIP)：
一个类只负责一个功能。
软件对象（类、模块等）应对扩展开放，但对修改封闭，从而实现代码可预测、可维护。
子类必须可替换为其基类，而不影响程序的正确性。
接口不应该强制接入冗余功能。因此，使用很多个客户端特定的接口，优于使用一个多用途接口。
命名就是一个例子。好的命名有助于清晰地区分：有描述性的函数名和易于理解的变量，且不含有奇怪的数值。
针对单个组件和独立功能的单元测试
针对多个组件之间交互的集成测试
从用户角度评估整个系统功能的端到端测试
测试不应过于拘泥细节。例如前端代码中的 CSS 选择器，或数据属性乃至截图等，显然就不必测试了。
Bytebase 2.23.0 - 支持 Entra (Azure AD) 用户/组同步
Bytebase 签约澳洲 ROLLER，助力文娱场馆一体化 SaaS 统一数据库操作
