……我曾与一些团队一起工作，其中多位工程师争论构建某样东西的"正确"方式。我记得当时觉得他们有基于过往经验的偏见，以及对什么重要的假设。通常需要一个外来者主动提醒他们，实际上对商业案例来说什么才是重要的。我记得有些案例中，工程师团队以"正确"的方式构建了某样东西，但结果却是错误的东西。（一个工程上很完美但没人用的东西）有时候，先草率地拼凑出一个东西来确认它是否是应该构建的东西，这才是正确的方式。然后确保它是安全的，最后再处理一些技术债务，使其更易于维护和扩展。我看到的真正愚蠢的问题是，当工程师在尚未确定他们是否在构建正确的东西时就过度设计，或者当管理层从不允许他们清理代码库，使其在明显是正确的事情时变得易于维护或可扩展。总是存在一种平衡/张力，但当我看到事情向一方或另一方发展过度时，就会出现本可以避免的失败。
源讨论Opus 4.5 将改变一切原帖 1,353 条评论 · 导入时统计让我困扰的是这类帖子：中级工程师并不会被指派原子化、全新领域的项目。如果一个工程师每天所做的只是从零开始构建应用程序，而没有任何期望其他人会随后进行扩展、在其基础上构建或依赖它，那么当然，Opus 4.5 可以取代他们。工程的难点不在于“构建一个能运行的东西”，而在于以一种易于理解、易于扩展的方式构建它。 毫无疑问，我可以给 Opus 4.5 下达“构建一个 XYZ 应用程序”的指令，它会表现得很好。但日常工作中，当我让它“帮我构建这个功能”时，它会使用奇怪的抽象，而且经常需要我多次尝试才能以我认为“正确”的方式完成。任何非技术人员可能会读到后说“如果能运行就没事”，但任何合理的工程师都会知道这还不够。
完整原文把你的经验，加入这段讨论。
> ...多位工程师争论“正确”的构建方式。我记得当时认为他们有基于过去经验和假设的偏见。 我通常会把关注的后果及其对团队的影响列出来，并提出针对这些影响的缓解方案。缓解方案总是涉及其他提议者的团队承担影响的修复工作。在书面文件中。在SOP中。在决策当天明确指出设计决策，以提醒在场人员中那些希望该设计成为专家（SME）的人。记录在运营中心。我们还提供自动监控和通知代码，我们很乐意提供。 一旦人们被要求在持续运营中承担相应的责任，我们会很快发现谁真正考虑了其决策的全部端到端后果。…
完整原文我知道你在说什么，但生活不仅仅是产品-市场匹配。 我们中几乎没有人正在开发Postgres、Photoshop、blender等，但这并不只是去希望我们是那样的。 将商业需求和社会需求分开考虑是很好的。是的，这个东西需要用户，否则没有人会受益。但它也需要对这些用户有益，最终，在最高水平上，工艺开始再次变得重要。 创业生态系统首先和主要关注获取用户/客户是有正当理由的。我并不反对这一点。我争论的是为什么行业需要在大部分产品上由创业公司主导（不是用户数量上的主导）。这引发了关于有多少有社会意义的编程工作有待完成的问题。 我希望有一个世界，更多的终端用户会编程（无论风格如何）…
完整原文> 我曾与一些团队一起工作，其中多位工程师争论构建某样东西的"正确"方式。我记得当时认为他们有基于过去经验和对什么重要的假设的偏见。通常需要一个外来者主动提醒他们什么对商业案例真正重要。 我的第一反应是，你可能也有不同的偏见、优先事项和/或品味。像往常一样，这可能非常依赖于具体情境，需要判断力来知道什么时候做得太过分了。事先很难知道"最正确"的方法是什么。 > 有时，把某样东西草率地拼凑起来以确认你正在构建正确的东西是正确的方式。然后确保它是安全的，最后再解决一些技术债务，使其更易于维护和扩展。 我同意有时候是这样，但在其他情况下，根据我的经验，当某样东西被完成时，…
完整原文*我曾与一些团队一起工作，其中多位工程师争论构建某样东西的"正确"方式。我记得当时认为他们有基于过去经验和对什么重要的假设的偏见。通常需要一个外来者主动提醒他们什么对商业案例真正重要。* 天啊，我对这个真的太累了——有人在之前的某个项目中被烧伤过，现在他的生活使命就是防止这种情况再次发生，他们不会接受任何争论。 然后你就会遇到典型的团队中有10个工程师，团队轮换，结果系统中就包含了各种"我们必须正确地做，因为我们五年前曾经通宵达旦"的观念。 不愉快的部分是，很多商业/管理人员"期望"立即得到完美的解决方案——有些是合理的，他们明白你需要一些迭代。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。