给那些读过所有其他建议文章的新软件开发者的建议

信任建议与“专家”

• 许多评论呼应了文章的观点：人们之所以被追随，是因为他们写得好或讲得好，而不是因为他们是对的。
• 这适用于博客文章、书籍、YouTube，甚至 LLM 输出；自信的表达 ≠ 正确性。
• 有几条评论主张保持怀疑但不要犬儒：理解任何最佳实践背后的理由，以及它背后的“恐怖故事”（Chesterton’s Fence 类比）。

软件、商业价值与销售

• 一个反复出现的争论是：“软件从来不赚钱，只有销售会赚钱。”
  • 支持者认为软件是成本中心，利润来自交易和获取客户。
  • 批评者反驳说，软件创造了可被出售或出租的价值；在许多公司里，软件显然推动了收入，而开发者薪酬也反映了这一点。
• 共识性的细微差别是：商业环境很重要；技术存在是为了服务业务，但低估工程会导致糟糕结果，并最终引发人才流失。

软件的目的

• 有一个很强的说法出现：“软件的唯一目的就是自动化。”
  • 支持者甚至把这一点延伸到电子游戏，认为它们也是自动执行规则。
  • 反对者引用游戏、艺术以及非自动化用途作为有效目的；他们认为这是教条式的越界。

开发者的工作

• 一个流行主题是：你真正的工作是解决业务/用户问题，而不是“写代码”或“写 Slack 消息”。
• 有些人认为这是一种修辞上的夸张；你 确实 经常要写代码，但重点应放在解决正确的问题上，有时甚至要通过 不 增加更多代码来解决。

文档、规格与源代码

• 一派主张“从头到尾”阅读文档，并研究关键工具的源码；他们声称这会带来长期速度提升和“地图感”。
• 也有大量反对意见：
  • 现代规格/库动辄成千上万页；不可能完整阅读或完全记住。
  • 人们有不同的学习方式；很多人更喜欢迭代式、问题驱动的阅读，或者快速浏览目录。
  • 建议的折中方案是：深入掌握一小套核心工具，广泛略读，并知道之后“去哪里找”。

简洁 vs 复杂性 与“正确方式”

• 对“不要把事情搞得比必要更复杂”这一点有很强支持（KISS）。
  • 批评过度抽象、过早泛化，以及为微型项目打造过于庞大的框架。
  • 还有一些“Right Way Guys”的故事：他们为平凡代码强行要求工厂/构建器/ORM/分阶段流程，或者用巨型内部框架来保住工作。
• 反方观点：小型副项目可以是练习“规范”基础设施和工具的安全场所；看起来像过度设计的东西，可能是有意的学习。

代码质量、可维护性与卓越

• 许多人更喜欢“清晰、可运行、易于调试的代码”，而不是“聪明”或“卓越”的代码。
• 对“卓越”存在分歧：
  • 有人说它是真实存在的，但很危险（傲慢、过度工程）。
  • 也有人认为，贬低卓越就是拥抱平庸；关键是追求能工作的、可维护的解决方案，而不是自我炫耀。

调试、读代码与工具

• 多条评论称赞某本调试书，并强调调试是核心职业技能。
• 建议：学会很好地阅读代码（包括单步执行），而不仅仅是写代码。
  • 一种观点认为：调试器是强大的学习工具，类似教科书里的练习题。
  • 另一种观点认为：过度依赖调试器是一种拐杖；资深工程师应当在不总是执行代码的情况下推理代码。

协作、评审与谦逊

• 代码评审被视为高杠杆：它们能改进代码、教授阅读技能，并暴露设计问题。
• 给初级开发者的建议：
  • 放下自我，接受直接批评，提出问题，尽早承认错误。
  • 理解“最佳实践”和架构决策是有情境性的；资深人士可能基于不明显的理由是对的。

健康、散步与认知负荷

• “去散步”这条建议引起了强烈共鸣。
  • 人们表示，散步，或者只是盯着池塘看，对脑内调试和应对压力都非常有帮助。
• 更广泛的一点是：管理你脑中的“状态”；通过笔记/wikis 将其外化，并保护你的精力（避免不必要的复杂性）。