82 lines
7.6 KiB
Markdown
82 lines
7.6 KiB
Markdown
|
||
文科与理科的一个最大差异：
|
||
文章写完了，可能才是开始，写文章需要3小时，改可能要画6小时。尤其是诗歌，改几个字词，要花一年（贾岛）
|
||
代码写完，只要目标实现，这个工作基本实现，程序界有一句话叫，这个代码能跑起来，你就别改。
|
||
|
||
当然这是夸张的说法，代码有重构的概念，而文章还有交差的，但是总体来说文章与代码是不同的目标。
|
||
|
||
对于以上，请你用逻辑思维和批判性思维来考虑，
|
||
1. 逻辑是否成立
|
||
2. 有哪些遗漏和补充
|
||
|
||
## Ge
|
||
|
||
这是一个非常精彩的观察和类比，它触及了文科与理科在思维模式和产出标准上的一个核心差异。我们用逻辑和批判性思维来深入分析一下。
|
||
|
||
### 1. 逻辑是否成立？
|
||
|
||
**结论：这个类比的**核心逻辑在很大程度上是成立的，**但它建立在对两者最典型、也最具艺术/工程色彩的极端案例上。**
|
||
|
||
这个类比的逻辑之所以成立，是因为它准确地抓住了两者在**目标、评价体系和“完成”定义**上的根本不同。
|
||
|
||
**A. 核心目标的差异 (The Core Logic's Validity)**
|
||
|
||
* **文章 (尤其是文学作品) 的目标：唤起共鸣、传递情感、引发思考、创造美感。** 这是一个主观和开放的目标。一篇文章是否“好”，取决于它在读者心中产生的效果。这种效果没有上限，因此修改和打磨的过程理论上是无限的。贾岛的“推敲”就是为了在“僧推月下门”和“僧敲月下门”之间，选择一个能引发更丰富联想、更具画面感和音韵美的表达。
|
||
* **代码 (尤其是功能性程序) 的目标：解决一个明确的问题、实现一个具体的功能。** 这是一个客观和封闭的目标。代码是否“好”，首先取决于它是否能正确、高效地完成预定任务。一旦这个目标达成，它的核心使命就完成了。
|
||
|
||
**B. 评价体系的差异**
|
||
|
||
* **文章的评价：主观性、多维度。** 评价标准包括但不限于：思想深度、情感张力、结构精巧、语言优美、风格独特。这些标准很难量化，不同的读者（评委）会有不同的看法。
|
||
* **代码的评价：客观性、可量化。** 评价标准包括：功能正确性 (Passes all tests)、运行效率 (时间/空间复杂度)、健壮性 (能处理异常)、安全性。这些标准大多可以通过测试和工具来验证。
|
||
|
||
**C. “完成”的定义不同**
|
||
|
||
* **文章的“完成”是相对的。** “写完了”只是草稿完成，进入了新的阶段——修改、润色、升华。对于追求极致的作者来说，作品永远有提升空间。
|
||
* **代码的“完成”是明确的。** “跑起来了”并且通过了所有测试用例，意味着一个可交付的、功能完整的版本诞生了。后续工作（如重构）是提升质量，而不是从0到1的创造。
|
||
|
||
所以，你提出的“文章写完才是开始，代码跑通基本结束”这个核心逻辑，作为一种高度概括的观察，是成立的。
|
||
|
||
---
|
||
|
||
### 2. 有哪些遗漏和补充？
|
||
|
||
你的观察非常敏锐，但为了让这个比较更全面、更严谨，我们需要补充一些被这个“夸张说法”所简化的细节。这个类比描绘的是两个领域的“艺术巅峰”与“基础工程”的对比，但现实中两者都存在一个广阔的谱系。
|
||
|
||
**A. 对代码世界的补充：远不止“跑起来就行”**
|
||
|
||
“能跑起来，你就别改”这句话，在专业软件工程领域通常被当作反面教材，它描述的是一种叫**“技术债” (Technical Debt)** 的状态。
|
||
|
||
1. **重构 (Refactoring) 的重要性远超你的描述。** 它不是锦上添花，而是核心工程实践。糟糕的代码（能跑但难以理解、难以修改）会给未来的维护、扩展和团队协作带来巨大的成本。一个优秀的程序员花在重构、优化代码结构上的时间，可能远超最初写出“能跑”版本的时间。这和作家修改文章的过程非常相似，目标都是为了让作品（代码）更清晰、更优雅、更经得起时间的考验。
|
||
2. **代码也有“文采”和“风格”。** 同样实现一个功能，好的代码如同一篇结构清晰、用词精准的说明文，读起来毫不费力。而差的代码则像一篇逻辑混乱、词不达意的文章。在顶尖程序员眼中，代码不仅是工具，也追求一种“美感”——简洁之美、逻辑之美、架构之美。Donald Knuth的传世之作就被命名为 *The Art of Computer Programming*（计算机程序设计的艺术）。
|
||
3. **代码的“受众”是双重的。** 代码不仅要让机器读懂（运行），更要让人（其他程序员）读懂。为了“可读性”和“可维护性”所做的努力，和作家为了让读者更好地理解而修改文章，其思维过程是相通的。
|
||
|
||
**B. 对文章世界的补充：并非所有文章都追求“推敲”**
|
||
|
||
贾岛的诗歌是文学创作的顶峰，但并非所有“文科”产出都遵循这个模式。
|
||
|
||
1. **功能性写作 (Functional Writing)。** 例如，一份产品说明书、一份法律合同、一篇紧急新闻稿。这类文章的首要目标是**准确、清晰、无歧义**，而不是艺术美感。修改它们的目标是消除漏洞和歧义，这和调试代码以消除 bug 的过程非常相似。在这里，“交差”和“实现功能”是等价的。
|
||
2. **效率优先的写作。** 很多时候，文章的产出有严格的时间限制（如记者赶稿、公文写作），目标是“在截止日期前完成一个足够好的版本”，而不是“创作一个传世之作”。这和敏捷开发中的“快速迭代”思想异曲同工。
|
||
|
||
**C. 核心的共同点：抽象、结构与迭代**
|
||
|
||
如果剥去外壳，两者在底层思维上存在深刻的共性：
|
||
|
||
1. **抽象与建模：** 写文章要先立意、搭框架；写代码要先做系统设计、建数据模型。两者都是将复杂的现实世界或思想抽象为简化的结构。
|
||
2. **逻辑与结构：** 一篇好的议论文，其论点、论据、论证过程要求逻辑严密；一个好的程序，其模块划分、函数调用、算法流程也要求逻辑清晰。两者都极度考验结构化思维。
|
||
3. **迭代与优化：** 无论是文章的“草稿-修改-定稿”，还是软件的“原型-开发-测试-重构”，核心都是一个不断迭代、追求更优解的过程。
|
||
|
||
### 总结与升华
|
||
|
||
你的观察是一个绝佳的切入点，它用一种生动的方式揭示了文理思维的典型差异。
|
||
|
||
* **逻辑成立之处**：它准确捕捉了**文学创作**与**功能编程**在**终极目标**（主观共鸣 vs. 客观实现）和**评价标准**上的本质区别。
|
||
* **遗漏与补充**：现实中，**软件工程**也包含大量类似修改文章的“美学”和“结构”优化工作（重构、追求代码优雅）；而**文字工作**也包含大量类似编程的“功能性”和“精确性”要求（技术文档、法律文书）。
|
||
|
||
因此，一个更精确的说法可能是：
|
||
|
||
**文科与理科的差异，不在于“修改”这个行为本身，而在于“修改”所依据的准则。**
|
||
|
||
* **文章的修改**，往往是在一个**主观、开放的美学和情感坐标系**里，寻找一个更好的“表达点”。
|
||
* **代码的修改（重构）**，则是在一个**客观、约束的逻辑和效率坐标系**里，寻找一个更优的“实现点”。
|
||
|
||
但顶级的作家和顶级的程序员，都在其领域里追求着同一种东西：**用最简洁、最优雅、最深刻的方式，构建一个完美的结构来表达思想或实现功能。** 在这个层面上，他们殊途同归。 |