[draft] new

1 files changed, 26 insertions, 0 deletions

diff --git a/content/article/engineering-perspective.md b/content/article/engineering-perspective.md
new file mode 100644
index 00000000..13ade637
--- /dev/null
+++ b/content/article/engineering-perspective.md
@@ -0,0 +1,26 @@
++++
+title = '什么是工程问题？'
+subtitle = '什么又是技术问题？'
+slug = ''
+tags = []
+categories = '软件杂谈'
+date = 2026-07-23T20:35:23+08:00
+draft = true
+toc = true
++++
+
+据我对自己过去的总结，以及比我更晚进入软件领域的人的观察，我发现新来者更容易陷入对技术问题的纠结，工程问题则被忽略了。我并不是说技术问题不如工程问题重要，我仅仅是指出，有不少人并不区分这两类问题，工程问题甚至不在他们的认知范围内，更别提去思考它了。本文我想来总结我对这两类问题的认识，并试图总结一些方法论。我也不是专家，所以肯定会有疏漏和错误，还请不吝赐教。<!--more-->
+
+## 接地气
+
+技术的定义或许更接近科学原则和科学事实，比方说，Go 语言中有缓冲的 `channel` 会在缓冲区满的时候阻塞试图向其中写入新数据的协程[^1]。倘若这个表述变成「需要严格控制并发的场合，应该使用带缓冲的 `channel`」，那么我们就更接近工程的范畴了，但这依旧更像是技术细节。如果说的是「尽管协程很轻量，但这个项目里每个协程的任务都占用 100MB，而每个实例运行在 1C1G 的服务器上，再加上操作系统和程序本身占用的内存，应该用带缓冲的 `channel` 把并发数控制在 8 以下」，这显然就是工程问题了。
+
+如此看来，技术和工程的区别之一可能是接不接地气的问题，也就是该问题是否涉及真实的软件需求、限制和外部环境。我们再来考量一下「工程化」这个词。过去人们常谈「前端工程化」这个问题，如今有不少人痛骂越来越臃肿的 Web，怒吼「[手写 HTML 难道他妈的不就是个网站了吗？](https://motherfuckingwebsite.com/)」。前端的过度工程当然是个问题，但后者的愤怒也有失公正。主流的前端库 [React](https://react.dev/)，尽管我不太喜欢，但它在刚推出时的确解决了不少问题。组件（Components）在 HTML 之上增加了一层抽象，很好地包装并隔离了复杂 Web 应用的复杂度。手写 HTML 当然能用，但用老三件套手写 Facebook 的用户界面实在强人所难——团队不方便分工，太多的细节都被挤在一起，所有人都有可能不小心碰到别人的代码。如果一个 HTML 页面冗长得不可理喻，要修改根本无从下手，这就使得工程无法进行下去。真正的问题是，某些网站根本不能算得上是一个「Web 应用」，竟然也要用一大堆 NPM 依赖写 SPA，这反而是对工程问题没有思考导致的——由于没有明确问题的规模（以及考虑未来是否有可能扩大规模），甚至根本没有考虑规模问题，就使用流行的、过度抽象的前端框架，消耗过多的计算资源。
+
+接地气要考虑的东西其实很多，而技术问题顶多关乎设计和实现。我不得不说，尽管我很讨厌 Java 这门语言，但在具体工程中使用 Java 有明显优势：会 Java 的人实在是太~~他妈~~多了，招人和组建团队非常容易；同时，遇到问题也更容易搜索到已有的解决方案；生态更成熟，JVM 也是很稳定的运行环境。当然也不能只看好处，选用 Java 的代价就是：JVM 启动需要时间，如果需要频繁停启，就会成为瓶颈；Java 的语法很啰唆，不仅如此，语言本身也有诸多限制，不够灵活，需要编写和维护的代码量很多，结构复杂，详见《[从 CLOS 审视 Java 面向对象编程](/article/clos/)》；~~会被 Eltrac 嘲讽~~；
+
+## 谁都能写出来，但不是谁都能维护下去
+
+## Footnotes
+
+[^1]: 协程指代 `goroutine`，是用户态的、轻量级、装载到系统线程上的并发单元。