过早的重构？

我们都听说过早优化,但您如何看待过早的重构？你认为有这样的事吗？这是我得到的.

首先,阅读Martin Fowler的开创性作品"重构"在字面上改变了我在编程方面的生活.

然而,我注意到的一件事是,如果我开始过快地重构一个类或框架,我有时会发现自己编码到一个角落里就可以说了.现在,我怀疑这个问题本身并不是真正的重构,但可能是过早/糟糕的设计决策/假设.

您对此问题有何看法,见解和/或意见？您对此问题有任何建议或共同的反模式吗？

编辑:

从阅读你的答案和更多地反思这个问题,我想我已经认识到,在这种情况下我的问题实际上是"过早设计"的问题,而不一定是"过早的重构".在编码过程的早期,我一直在设计和重构这个方向.我保持一定程度的设计不可知性并专注于对清洁代码进行重构,这让我有点耐心,这使我无法走下这些设计兔子的道路.

我实际上认为相反.

越早开始思考您的设计是否需要重构,就越好.不断重构,所以这绝不是一个大问题.

我还发现,我在早期重构的越多,我就越能更好地预先编写代码.我倾向于创建更少的大型方法,并且问题更少.

但是,如果你发现自己"重构"自己的角落,我希望这更多的是缺乏初始设计或缺乏对课程使用范围的规划.在开始编写代码之前,尝试写出如何使用类或框架 - 它可以帮助您避免该问题.这也是我认为测试驱动设计的一个优点 - 它可以帮助你强迫自己在编写之前使用你的对象.

请记住,技术上的重构永远不应该把你锁定在一个角落 - 它是关于重新修改内部结构而不改变类的使用方式.如果你通过重构来捕获自己,那就意味着你的初始设计存在缺陷.

您可能会发现,随着时间的推移,这个问题变得越来越好.您的类和框架设计可能会更灵活.

我们都听说过早熟优化,但是你对早熟重构有什么看法？你认为有这样的事吗？

就在这里.重构是一种偿还在开发过程中累积的技术债务的方法.然而,仅仅增加技术债务并不一定是坏事.

为了了解原因,假设您正在为IRS编写纳税申报分析软件.突然之间,在最后一刻引入了新的规定,打破了几个原始的假设.虽然你设计得很好,但你的领域模式已经从根本上从至少一个重要的地方转移到了你的脚下.这是4月14日,该项目必须明天上线,地狱或高水位.你是做什么？

如果以一些中等技术债务为代价实施螺母和螺栓解决方案,您的系统将变得更加严格,并且无法承受另一轮这些变化.但该网站可以上线并继续前进,并且没有延迟交付的风险; 你有信心可以做出必要的改变.

另一方面,如果您花时间重构解决方案,以便现在以更复杂和灵活的方式支持新设计,那么您将适应未来的变化.但是你冒着贵公司旗舰产品的风险而不顾时机; 你不确定重新设计是否需要比今天更长的时间.

在这种情况下,第一个选项是更好的选择.假设您之前几乎没有技术债务,那么现在就拿下你的块并稍后付清它是值得的.当然,这是一个商业决策,而不是设计决策.

我认为有可能过早地重构.

在设计的最后一端是代码本身.设计的最后阶段随着代码的存在而存在,它有时会有缺陷,随着代码的发展,你会看到它.如果你过早地重构,就会更难改变有缺陷的设计.

例如,当您意识到它是垃圾或走错方向时,删除一个很好的格式化功能及其使用的功能和它们使用的功能等,同时确保删除单个长函数要容易得多.你没有打破那些属于重构的东西.

可以说也许你应该花更多的时间来设计,但敏捷过程中的一个关键因素是编码是设计过程的一部分,在大多数情况下,在设计上付出了一些合理的努力,最好还是继续用它.

编辑回复评论: -

在编写代码之前,设计不会完成.我们无法解决预编码设计中的所有问题,敏捷背后的全部意义在于编码是解决问题的方法.如果非代码设计在编码之前预先解决了所有问题,就不需要重新考虑,我们只需一步就可以将设计转换为精心设计的代码.

有人记得20世纪80年代末和90年代初的结构化设计方法,在你编写一行代码之前,你在聪明的图表中解决了所有问题吗？