我认为开发者有时过于执着于代码质量，认为更聪明的代码能让他们成为更好的开发者。事实上，我见过一些开发者陷入误区，把他们的代码当作产品，因此花太多时间美化代码，以至于从未真正发布任何东西。然后你又会看到另一端的情况，有些人过于专注于快速拼凑出东西，结果最终的代码难以维护。现实是，要成为一个优秀的开发者，需要两者兼顾。例如，如果你在构建一个概念验证（POC），那么证明这个想法比定义架构更重要。原因在于，你并不总是能一开始就理解最终产品（无论是商业软件还是开源库）的最佳架构，直到你经历了几次想法的草稿之后。因此，面条式代码并不一定是坏事。但当你确定你的想法可行，需要将其扩展成更持久的东西时，你就会开始将这些面条式代码重构为更易维护的形式。…
源讨论约翰·卡马克关于法布里斯·贝拉德原帖 463 条评论 · 导入时统计莫扎特的感觉不对。代码并不美丽和优雅。它并不是为了长久而构建的（至少对于ffmpeg来说），也不是什么杰作。他写代码只是为了完成工作或满足某种智力好奇心。它并不美丽，但这没关系。 我认为Unicorn体现了他风格的一个问题。如果QEMU代码被架构成整洁的组件，Unicorn就不需要存在。但编写能完成工作的混乱代码正是他如此快速和高效的原因。这是一种权衡。 https://www.unicorn-engine.org/docs/beyond_qemu.html 我认为实际上和约翰·卡马克形成了鲜明对比。法布里斯可能更聪明、更快，但卡马克可能是一位更好的软件工程师。你可以从Doom和Quake的源代码中看到他的风格发展，其中Quake 3的源代码就像一个美丽的宝石般的代码库。
完整原文把你的经验，加入这段讨论。
但代码质量是速度和覆盖范围。你无法前进，除非你能阅读代码，理解模型，否则你无法超越某个点。架构的美妙之处在于，它能让你建造一艘宇宙飞船，而不是一堆煤油油罐车。它们在物理上相似，但能力上却截然不同。 我觉得这非常可怕。有些人无法察觉能力和技术债务。如果你无法察觉这一点，你不应该被允许参与高管决策或代码库评估。这实际上是航天科学和失败项目爆炸之间的区别。每个人都可以堆砌炸药，但不是每个人今天都能去太空。 这是一个很好的面试话题，可以筛选出这类候选人。
完整原文相反，更好的代码结构让我这个普通开发者能够取得进展，而不是遇到复杂性障碍。 这与追求“优美”代码无关，优美在良好的结构边界内带来的收益递减，相比之下，只要拥有这些边界就足够了。
完整原文> 我认为开发者有时过于关注代码质量，认为更聪明的代码能让自己成为更好的开发者。 并不是说“聪明”不重要，但代码远比其之上的许多“产品”更持久，因此对它们进行打磨可能比对那些可以随手丢弃的礼物纸更值得。 人们当然会购买漂亮的礼物纸包装廉价的流行音乐玩具。但他们会以不同的方式看待一件精美的手工乐器。另一方面，那些根本不玩音乐的人无法评估任何音乐设备。
完整原文> 例如，如果你在构建一个概念验证（POC），那么证明这个想法比定义架构更重要。 我曾经尝试为POC这样做（只是把所有东西随便拼凑在一起），但总是很快就会卡住。直到我为我应该做的事情想出某种架构，我才能继续前进。就像，一旦我完成了POC的几个步骤中的第一步，我就无法想象如何实现第二步，直到第一步被某种程度地组织好。
完整原文如果你的代码是低风险的一次性项目，并且最终能正常运行，那么杂乱的代码是可以原谅的。Undertale看起来像Yandere Simulator内部；没人会在意。 但如果你的代码需要长期维护，或者在安全性、可用性等方面有约束，就像几乎所有代码一样，那么是的：更清晰、结构更好、更易读的代码是产品的重要组成部分，因为它在修改时对你自己和后续开发者来说都是巨大的帮助，可以更快地进行修改，降低修改成本，并提高安全等指标的质量。即使我是在写一个游戏——我有ADHD，所以如果初始代码很糟糕（我写过很多糟糕的代码），我以后会很不愿意去碰它。结构更好的代码更容易让我在之后重新审视并改进。所以我从一开始就坚持不断改进我的代码结构…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。