Hoon Wee · 2025-01-22

软件工程师应避免的十个行为

摘要

作者 Hoon Wee 基于五年以上的软件工程经验，分享了十个开发者应当避免的行为模式。这些经验涵盖了对代码质量的理解、开发流程的把控、职业心态的调整等多个维度，旨在帮助软件工程师摆脱常见误区，成长为更成熟的问题解决者。

内容框架与概述

文章以资深工程师的视角展开论述，首先指出了完美主义的陷阱——完美的代码并不存在，软件开发本质上是迭代的过程，专业能力体现在"足够好"而非"完美"。作者进一步强调重构应当融入日常开发流程，而非作为事后的额外请求，这体现了对工程质量的持续关注。

在技术实践层面，作者重新定义了"遗留代码"的概念——它并非指旧代码，而是指缺乏测试的代码。这一观点揭示了可测试性与可维护性之间的本质联系。同时，作者警示不要盲目推崇函数式编程或遵循所谓的"最佳实践"，编程范式的选择应当基于具体场景和上下文判断，而非教条式套用。

文章后半部分转向开发者工作方式和职业心态的探讨。作者反对独自挣扎解决问题，倡导利用团队智慧和现有方案；提醒在追求"心流"状态时保持自我觉察，建议采用番茄工作法避免倦怠。最后，作者强调了身体健康的重要性，并鼓励开发者保持对编程本身的热爱，从"码农"升级为用代码解决问题的"软件工程师"，以应对未来 AI 对简单编码工作的潜在替代。

核心概念及解读

遗留代码的本质：传统观点认为遗留代码等同于陈旧代码，但作者指出真正的定义是"没有测试的代码"。缺乏测试的代码无法安全重构，也无法维护；相反，即使技术栈较老（如 Next.js v10），只要测试覆盖良好，代码仍然具备可维护性。这一观点重新定义了代码质量的评判标准。

上下文驱动的技术选择：函数式编程、清洁架构、SOLID 原则、TDD 等都是有力的工具，但没有放之四海而皆准的"最佳实践"。在 Clojure 或 Python 等语言中，TDD 可能并非必要；在 Flutter UI 层中，过度函数式化可能损害性能。成熟工程师的标志在于根据具体情境做出合理判断。

从编码者到问题解决者：AI 时代正在重新定义软件开发者的价值。单纯写代码的能力（“码农”）面临被替代的风险，而运用代码解决实际问题的能力（“软件工程师”）将更加稀缺。这一转变要求开发者超越技术本身，关注业务价值和问题本质。