编写高质量代码改善C#程序的157个建议——建议154:不要过度设计,在敏捷中体会重构的乐趣

时间:2022-02-21 10:52:56

建议154:不要过度设计,在敏捷中体会重构的乐趣

有时候,我们不得不随时更改软件的设计:

  • 如果项目是针对某个大型机构的,不同级别的软件使用者,会提出不同的需求,或者随着关键岗位人员的更替,需求也会随个人意志有所变更。
  • 如果竞争对手增加了新需求,我们也不得不为正在研发的新产品调整设计方案。
  • 刚开始的架构太糟糕了,这可能源于设计经验的不足或者架构师的不负责任。

以上分别从外部和内部描述了必须修改需求和设计的几种场景。也就是说,在软件开发过程中,变化几乎总会发生。

为了捕捉需求上的不断变化,软件开发必须变得足够“敏捷”。设计也应该停留在“高层次”上,具有指导作用,而功能模块(或者说代码)则需要逐步改进。我们把改进的过程称为“重构”.

传统的瀑布开发由于不能满足需求的变化,在软件领域被各类敏捷开发框架所取代。

敏捷开发模式把整个开发过程分成了一个一个的迭代,每个迭代的周期大概是两周到一个月。每个迭代大致分为如下几个步骤。

编写高质量代码改善C#程序的157个建议——建议154:不要过度设计,在敏捷中体会重构的乐趣

敏捷开发使用“用户故事”(User Story,在TFS敏捷规范中,它被归类到BackLog)来核定需求和工作量指标。在一个迭代开始的时候,开发团队应该挑选用户故事作为本次迭代的目标;而在每一次迭代结束的时候,用户故事应该开发完毕。整个开发部门必须发布一个可以运行的版本交付给客户(对象可以是真实的用户,也可以是团队运营部门)。这有助于客户及时调整他们对产品的预期,并修正可能存在的需求变动。而作为开发团队,也可以根据客户的反馈修正需求,甚至是设计。

正是因为敏捷开发拥抱变化,所以站在整个开发流程来看,设计应该是可以修改的,而落实到代码上来,也就是重构的地位提升了。在敏捷开发体系中,我们可以将其作为一个任务(Task)引入整个开发流程中。

作为一个团队,需要定期审视模块是否可以被重构。而作为开发人员,建议一旦嗅到代码的坏味道,就需要重构我们的代码。

我们不追求让代码第一个版本就保持非常整洁的程度,那不现实,而且会让开发者觉得无从下手。当然,我们更不应该让繁杂的代码永远保持在第一个版本的状态,那样的代码,让我自己都不满意。

转自:《编写高质量代码改善C#程序的157个建议》陆敏技