避免陷入过度设计的泥潭

最新推荐文章于 2024-01-29 16:20:47 发布

郭霖_

最新推荐文章于 2024-01-29 16:20:47 发布

阅读量557

点赞数

本文链接：https://blog.csdn.net/c10wtiybq1ye3/article/details/78098769

版权

新的一周开始了，立秋之后天气貌似没那么热了，以后就是“一场秋雨一场寒”啦。

本篇来自 geekerhw 的投稿，跟大家分析了过度设计。另外文末提出的 TDD(测试驱动开发) 大家可以自己搜索一下。

geekerhw 的博客地址：

http://blog.csdn.net/geekerhw

序言

学习了许多的设计模式之后，大部分人都会有滥用(或者设计不足)设计模式的经历，如何在其中找到一个balance，以下的文章就会给出一个解决方案，一种比较中和的思考方式，在此之前，我们先看一下我们经常会犯的几种错误。

功能上的过度设计

功能性过度设计其实不是我们今天讨论的重点，但是知晓它非常的重要，因为需求的易变性(造成我们无法准确把握程序的走向)是造成我们对设计模式滥用的一个比较重要的原因，请各位看官带着调侃的心态看一个小段子，笑笑后可能也会给我们带来一些思考(为什么说带着一种调侃的心态，因为这部分大多不是我们能控制的，大家都懂) 。

程序上的过度设计

先引用 vczh 的一句话：

什么叫过度设计？只要team里面的人没有牛逼到来什么需求都可以把代码重构到恰好满足那个需求的最佳状态，那么我们在开发的时候总是要考虑一下未来的需求到底会往哪个方向走。
你蒙中了，就叫正交分解。
你没蒙中，就叫过度设计。

简单的来说，过度设计就是进行了过多的面向未来设计，我在重构系列中说过，一个程序产生的价值有两种，今天能为你做什么和将来能为你做什么，但是，如果我们过多的考虑了未来，进行了太多的不必要(说不确定可能更好)的封装，就会为系统增加许多的复杂度。

举一个简单的例子：当你接手一个功能模块时，除了你完成了自己目前的任务，你还考虑到了未来可能完成的功能等，你就会做一些抽象和封装，以便将来可以复用它们，但是到后来你发现了功能和你想象的不一样(有可能是需求变化，有可能是你封装抽象错误或者封装抽象不足，或者说你发现复用的部分降低的成本还不如包装花费的成本)，你就会陷入泥潭，可能需要做更多的工作来还原,然后继续前进，继续犯错…

如何解决

如何避免过度设计，这需要大量的经验积累和不断的思考。

我们需要深入理解我们所在程序领域的知识，了解用户使用我们的软件是为了解决什么样的问题，这样我们预测用户的需求才会比以前更加准确，从而避免了我们使用设计模式来封装一些根本不会发生的变化，也避免了我们忽视未来会发生的变化。

在满足了知道所有设计模式为什么要被发明出来的前提之后，剩下的其实和编程没什么关系了，而跟我们的领域知识和经验有关(对于我这个小白，还有很长的路要走啊~-~)

TDD思考发(测试驱动开发)

TDD思考法(测试驱动开发)

这是我在网上看到的一种方法，因为题主经验不足,自己没有亲身实践过，无法通透其中的奥义，所以先行记录,待以后慢慢咀嚼。

TDD 的核心思想是小步增量，不断重构，具体来说TDD有两个状态(两顶帽子) ：

状态A：用test case描绘需求，并使用最简单的方式满足这个case，一定是最简单的方式，不能做此外的任何涉及(考虑当前，不顾未来)，case通过之后进入状态B。
状态B：重构代码，让现有的代码在尽量保持简单性的同时足够清晰优雅，注意此时你只能对现有的实现代码进行重构，不能增加新的功能和test case。

TDD 的这种思维方式走的稍微极端一点。它直接排斥任何对未来的设计，转而以优雅简洁的设计和 test case 来为未来需求的重构降低成本。可以说严格遵循 TDD 会在设计不足和过度设计之间找到最好的平衡。