Blog

Blog

PHODAL

浮现式设计

设计模式不是一开始就有的,好的软件也不是一开始就设计成现在这样的,好的设计亦是如此。

导致我们重构现有系统的原因有很多,但是多数是因为原来的代码变得越来越不可读,并且重构的风险太大了。在实现业务逻辑的时候,我们快速地用代码实现,没有测试,没有好的设计。

而下图算是最近两年来想要的一个答案:

浮现式设计

浮现式设计是一种敏捷技术,强调在开发过程中不断演进。软件本身就不应该是一开始就设计好的,他需要经历一个演化的过程。

意图导向

就和Growth一样在最开始的时候,我不知道我想要的是怎样的——我只有一个想法以及一些相对应的实践。接着我便动手开始做了,这是我的风格。不得不说这是结果导向编程,也是大部分软件开发采用的方法。

所以在一开始的时候,我们就有了下面的代码:

if (rating) {
  $scope.showSkillMap = true;
  skillFlareChild[skill.text] = [rating];

  $scope.ratings = $scope.ratings + rating;
  if (rating >= 0) {
    $scope.learnedSkills.push({
      skill: skill.text,
      rating: rating
    });
  }

  if ($scope.ratings > 250) {
    $scope.isInfinite = true;
  }
}

代码在不经意间充斥着各种Code Smell,如:

  1. Magic Number
  2. 超长的类
  3. 等等

重构

还好我们在一开始的时候写了一些测试,这让我们可以有足够的可能性来重构代码,而使得其不至于变成遗留代码。而这也是我们推崇的一些基本实践:

红 -> 绿 -> 重构

测试是系统不至于腐烂的一个后勤保障,除此我们还需要保持对于Code Smell的嗅觉。如上代码:

  if ($scope.ratings > 250) {
    $scope.isInfinite = true;
  }

上面代码中的“250”指的到底是?这样的数字怎么能保证别人一看代码就知道250到底是什么?

如下的代码就好一些:

  var MAX_SKILL_POINTS = 250;
  if ($scope.ratings > MAX_SKILL_POINTS) {
    $scope.isInfinite = true;
  }

而在最开始的时候我们想不到这样的结果。最初我们的第一直觉都是一样的,然而只要我们保持着对Code Smell的警惕,情况就会发生更多的变化。

重构是区分普通程序员和专业程序员的一个门槛,而这也是练习得来的一个结果。

模式与演进

如果你还懂得一些设计模式,那么想来,软件开发这件事就变得非常简单——我们只需要理解好需求即可。

从一开始就使用模式,要么你是专家,要么你是在自寻苦恼。模式更多的是一些实现的总结,对于多数的实现来说,他们有着诸多的相似之处,他们可以使用相同的模式。

而在需求变化的过程中,一个设计的模式本身也是在不断的改变。如果我们还固执于原有的模式,那么我们就会犯下一个又一个的错误。

在适当的时候改变原有的模式,进行一些演进变显得更有意义一些。如果我们不能在适当的时候引进一些新的技术来,那么旧有的技术就会不断累积。这些技术债就会不断往下叠加,那么这个系统将会接近于崩塌。而我们在一开始所设定的一些业务逻辑,也会随着系统而逝去,这个公司似乎也要到尽头了。

而如果我们可以不断地演进系统——抽象服务、拆分模块等等。业务在技术不断演进地过程中,得以保留下来。

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

标签