vue 页面之间的过度_最佳实践和过度工程之间的狭窄道路

最新推荐文章于 2024-05-12 18:19:01 发布

danpu0978

最新推荐文章于 2024-05-12 18:19:01 发布

阅读量170

点赞数

文章标签： java 设计模式 python 人工智能编程语言

原文链接：https://www.javacodegeeks.com/2013/11/the-narrow-path-between-best-practices-and-over-engineering.html

版权

vue 页面之间的过度

几天前，我读了Petri Kainulainen的一则有关最佳实践的阴暗面的文章。他确实在一方面打出了恕我直言的观点，这是完全显而易见的常识，但可悲的是，事实往往并非如此。

不要误会我的意思。 最佳实践是软件开发的重要组成部分，我对此表示大力支持。每个开发人员都应该阅读诸如《四人帮的设计模式》，《 Fowlers重构》或《企业体系结构模式》等书籍。我坚信自动测试和TDD方法会为您提供随时间变化的灵活性。但是关键是您真的必须了解它们。正如皮特里（Petri）所写的那样，也有阴暗面，尤其是当它们被当作银弹时 。

当最佳实践被视为最终解决方案时，不允许质疑它们。 […]这意味着我们失去了学习和改善当前状况的机会。 […]如果我们生活在一个静止的世界中，这将是一个有效的策略。 […]所有人都知道新技术正在Swift发展。我们确定要被抛在后面吗？来自Petri Kainulainen的博客

毕竟，许多软件工程师经常忘记的是，我们在这里的目标是：满足客户的需求；使复杂的操作自动化并简化他的生活，而不是使其复杂化 。显然，我们是技术人员，因此我们需要尽最大努力避免技术僵局，成本爆炸等问题。但是，我们并不是在这里创建梦想或框架的架构（除非这是我们的核心业务）。我常常觉得，我们最好将时间花在更直观，该死的简单用户界面上，而不是笨拙地构建后端体系结构。

有时，最佳实践会导致诸如架构，设计模式和重用之类的概念受到重视。

工程过度是另一个常见症状……

由一组建筑师设计的软件如此复杂，真是令人惊讶。

正如Petri所写，这是由于对可重用组件和应用程序之间缺乏了解（我可以默默同意。）

这种情况是由于无法理解可重用组件（框架，库或服务）与应用程序之间的差异而引起的。

正如他所写：这种区别很明显：

在创建可重用组件时，我们必须将其设计为可重用。
在创建应用程序时，我们必须专注于该应用程序的需求。

过度设计可能永远不会重复使用的代码是没有意义的。但是，如果我们认为在每种情况下都应使用相同的设计原则，就会发生这种情况。

我已经听到一些人的声音：嗯，但是如果我们从一开始就设计要重用的所有内容，那么我们将更加灵活。相当公平，但是设计一些可以立即使用的东西意味着在生产过程中会增加成本。但这是合理的吗？让客户为可能从未真正发生的事情付费是公平的吗？另一方面，诸如敏捷，TDD方法和精益软件开发之类的方法选择实施就足够了。显然，您确实遵循了应用程序设计中的常识，例如将业务逻辑与数据访问或表示代码分离，并且对相关性进行分离和隔离，以使其更易于交换和测试等。

那我们该怎么办呢？

我们应该了解最佳做法，其优缺点，并应视情况决定是否应用这些最佳做法，和/或了解何时更好地服务于我们（和客户）何时走另一条路。根本没有人可以统治他们所有的方法，它不存在，尤其是在像IT这样瞬息万变的部门中。

我们需要不断创新，这只有在我们允许我们自己脱离常规的决策方案时，才可以尝试从更遥远，更客观的角度看待我们的解决方案。从现在开始，挑战您通常的方法；有更好的吗？别人如何解决类似的情况，向他们学习？ 创新需要从团队中产生 ，而生产必须来自团队 ，而不能在单独的独立实验室中进行。浪费的风险太大了。

最后，架构师应该更多地是领导者，首席开发人员，“ 教练架构师 ”，在创新过程中以及在保持生产力和效率的过程中，支持团队进行此类决策。此外，他们应该建立联系并促进不同项目和团队之间的知识共享过程。