软件工程 on LeoChu Space

人月传奇

Wed, 22 Jan 2025 00:00:00 +0000

Frederick P. Brooks Jr.《人月传奇》。核心观点：软件项目最大的难点不是编码本身，而是复杂性、沟通成本和不可压缩的系统设计工作。

向延期项目增加人手，只会让它更晚。 新人加入需要沟通、培训、同步上下文，短期内增加的是负担而不是产能。

概念完整性比局部聪明更重要。 一个系统最宝贵的是整体一致的设计语言，而不是每个模块都由最聪明的人各自发挥。

软件开发存在本质复杂性。 有些问题可以靠工具改善，但需求理解、系统边界、多人协作这些难题无法被简单消灭。

人月并不能自由替换。 并不是每个任务都能线性拆分后并行推进，很多关键工作天然依赖少数人做深度思考。

文档和接口设计是沟通成本控制器。 项目一旦变大，真正稀缺的就不是“谁会写代码”，而是“谁能让协作保持有序”。

这本书虽然老，但读起来并不旧。今天工具多了很多，项目翻车的原因却没怎么变：目标没说清，边界没定住，沟通一乱，就开始指望“再加点人”补回来。

核心是把软件工程从“多写点代码”拉回到“怎么组织人和系统一起工作”。

Sat, 07 Sep 2024 00:00:00 +0000

Robert C. Martin《代码整洁之道》。核心观点：整洁代码不是美学偏好，而是长期可维护性的基础。

代码首先是写给人读的。 机器最终当然会执行，但程序员大部分时间都花在理解和修改已有代码上。可读性不是附加价值，而是主价值。

函数要短，职责要单一。 一个函数一旦同时承担多层抽象、多种意图，理解成本就会迅速上升。短函数不是教条，单一意图才是关键。

命名是第一层设计。 好命名能直接省掉解释成本；坏命名会让系统像永远开着一层雾。

重复不只是代码味道，更是未来修改成本。 逻辑复制一次看似省事，后面会以一致性风险的形式成倍偿还。

错误处理和正常流程应当分离。 把异常分支塞进主逻辑里，会让代码阅读路径被打断，结构也变得混浊。

整洁不是一次性整理，而是持续的小修正。 童子军军规式的“离开时让它比来时更干净一点”，比大规模重构更现实。

代码不会在项目后期突然变整洁，它只会在每次提交里慢慢变好，或者慢慢变烂。

很多工程问题到最后都不是技术突破不了，而是前面欠下的整洁债开始一起算账。