……随着时间的推移，我发现唯一可靠的方式来推理工程决策的方法是从业务用例倒推。我们想要实现什么？时间范围是什么？现在与以后值得承担的风险是什么？其他一切……模式、范式、“最佳实践”……只有在那个背景下才有意义。其余的只是学术性的，而且通常与现实脱节，说实话。还注意到，很多工程领域的强烈观点来自于试图避免之前经历过的痛苦的人。但拯救了他们的解决方案在另一种情况下很容易变成负担。模式会固化为规则。这就是为什么我努力让自己的推理立足于结果和上下文，而不是意识形态。大多数“最佳实践”只是局部最优解……直到它们不再有用。
源讨论为什么我不再和架构师讨论微服务了原帖 92 条评论 · 导入时统计把你的经验，加入这段讨论。
是的，这让他们觉得自己很聪明。开发者甚至工程师这个名称都过于夸张了。 代码猿才是更准确的称呼。我可不是在开玩笑。
完整原文机械工程确实有既定的实践，但我会反对它在许多甚至大多数情况下是僵化且定义明确的。
完整原文我同意我们并没有达到“软件工程”这个头衔的水平，软件独特复杂的事实并不是错误，但同样，这种高度的复杂性并不排除工程文化的出现。了解用户并认识你的能力（包括局限性）。这就是工程师被要求做的。当伦理问题出现时，要知道不仅有用户，还有利益相关者。
完整原文对我来说，区别在于使用现有的工程， versus 工程工程的方法。 后者似乎在软件中更常出现并成熟。
完整原文我经常觉得编程更像写作而不是其他任何东西。任何给定的语句可能是数学的，但在更高层次上，你更多的是根据人文需求和思维模式来编写程序，而不是严格地"工程化"它。
完整原文软件与工程的区别在于法律责任的问题。如果我们真的因为软件公司给我们提供有害的东西而起诉它们，软件就会开始看起来像其他类型的工程。
完整原文我非常同意你后两段的观点，但我将反驳一个经常被重复的陈词滥调，即软件工程不是真正的工程，因为它不像物理工程那样有纪律性。 我个人认为软件工程绝对是工程，只是它与物理工程有大部分不同的约束。这大部分与处理在现实世界中建造东西的成本和后果有关。没有这些纪律性，建造一座失败的桥梁或一个无法完成任务的昂贵机器会带来巨大的资本成本。我们还必须考虑物理材料的限制和严酷的环境，这些在某种程度上更难处理，但同时也比纯软件（即所有动物对物理事物都有某种直觉，物理）更稳定和被充分理解的基底。…
完整原文软件的力量在于它1）将大量工作从物理领域转移到了书面和智力领域，以及2）它可以大规模复制。因此它真的不像工程，更像写作，但工业化了。至少在应用层面，大部分软件工作都是如此。实际上让书面软件与它运行的机器进行物理交互的工作是工程，但通常不是大多数"软件工程师"所从事的工作。 不管怎样，软件工程中没有很多硬性且可复制的规则其实并不令人惊讶，因为像散文写作中也没有。有一些更有效的最佳实践、技巧和方法。而且软件确实有一些约束，而散文写作中没有这些约束，最终，软件确实必须…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。