我的编码方式有问题。不管我事先写了多少计划,代码很快就会变得过于复杂。
阅读关于良好实践的书籍,并试图遵循它们的原则是行不通的。
除了在规划阶段更加彻底和专注之外,是否有可靠的审计代码的方法来简化它呢?
发布于 2015-02-09 22:55:39
确实有一些技术可以逐步简化代码,并通过这样做改进设计。一般的技术被称为“重构”。请注意,这个术语是非正式地使用的(意思是“在不改变代码功能的情况下改变代码的设计方式的任何东西”)和形式上(意思是“遵循特定的重构规则”)。我指的是后一种定义。
特别是,Martin对这个问题进行了大量的研究,他的著作"重构:改进现有代码的设计“是软件工程的经典书籍之一,值得一读。
这本书所建议的一般技巧是:
1)为您打算重构的代码部分编写非常详细的测试。
2)对代码做一个特定的小改动。例如,内联一个方法,重命名一个类,将一些代码提取到一个新的方法中,从一个现有的类中提取一个超类,等等(Fowler在他的书中列出了许多这样的小转换的详细列表,以及关于如何/何时进行这些转换的建议。现有的“自动重构”功能的大多数名称,如Eclipse、IntelliJ等,都是从他的书中使用的。本质上,这些类似于“设计模式”,但用于修改现有代码,而不是最初用于设计代码。)
3)重新运行你的测试,以验证你还没有破坏任何东西。
4)重复,直到你对结果满意为止。
因此,可以通过积累多个小的更改来对代码进行较大的更改,并在每个更改之间进行测试。
显然,如果您一开始就习惯于为代码编写和保留详细的测试(单元测试套件、回归测试套件等),那么上述过程将比在开始重构之前必须编写测试容易得多。而且,如果在每个更改之间重新运行的测试套件中的部分能够相当快地运行,那么这样做就容易多了。
请注意,以这种方式重构代码是一项纪律。这与简单地随意地改变代码是不一样的。在此过程中进行频繁的测试对于确保您对程序的行为所做的任何无意中的更改都能很快被捕捉到,而您仍然可以记住您做过的事情。因此,将重构与添加或更改程序行为的其他开发分开通常也是一个好主意,因为这些更改可能会使现有的测试无效。例如,您可以选择一个阶段:添加一个特性,然后稍微重构一下,然后添加另一个特性,然后再重构一些,然后修复一个bug,然后重构等等。
如果使用这些技术来简化代码的编程是一致的,那么随着时间的推移,代码的总体趋势将是逐渐变得更简单、更容易阅读,而不是相反(遗憾的是,这在行业中更为常见)。
您还可能会发现,围绕敏捷和/或XP软件开发方法的一些社区对于如何/何时/如何重构可能很有帮助,因为以这种方式进行持续重构被认为是许多此类方法所必需的特性。
我看到许多项目逐渐变得如此残酷和复杂,以至于没有人理解它们,它们最终不得不被抛弃,因为维护它们最终比重写它们花费更多的精力。重构是避免此问题的一种方法。
发布于 2015-02-09 12:53:56
练习。
不,真的。
在你写完第一盘意大利面或大泥球之前,你永远不会完全欣赏一本书或博客文章中的一项技术,并意识到这些技术中的许多都是驯服复杂性的有效方法。然后你会在一个更深的层次上理解他们,远比那些只是把图案串在一起看上去酷,但并不完全理解背后的原因的货主更深。
看看这些图案。他们中的任何一个容易吗?好吧,他们肯定比写一盘意大利面或一大团泥巴简单得多,而且以后还要保持它。但你还是得研究一下这些模式。即使是最好的画家也使用不止一种画笔。
发布于 2015-02-09 13:26:58
我唯一肯定的方法是:
第一次暗示代码变得复杂时,不要害怕重构计划。
(当然,这一点丝毫不否定你已经提到的关于在规划阶段更加彻底和专注的说法。)
https://softwareengineering.stackexchange.com/questions/272669
复制