设计和架构:业务开发指导原则

栏目: 后端 · 发布时间: 6年前

内容简介:计划写一个系列文章,总结自己在四年iOS生涯中对设计模式和架构的理解。主要包括自己的总结、Apple源码和优秀三方开源项目中设计模式和架构的学习。这只是自己的总结,每人理解不一样。希望能抛转引玉,让大家加深理解。系列中的第一篇文章主要介绍自己在码业务时的一个指导思想,主要解决在

计划写一个系列文章,总结自己在四年iOS生涯中对 设计模式 和架构的理解。主要包括自己的总结、Apple源码和优秀三方开源项目中设计模式和架构的学习。

这只是自己的总结,每人理解不一样。希望能抛转引玉,让大家加深理解。

业务与重构

系列中的第一篇文章主要介绍自己在码业务时的一个指导思想,主要解决在 快速开发 过程中最常遇见的2个问题:

  • 业务开发中如何避免过度设计?
  • 何时需要重构?

为什么会有这样的问题? 通常我们的版本是呈现出 小步迭代快速开发 的开发规划,主要就是功能多,开发快。所以就会要求我们在码业务时:尽量快速的开发功能,同时又要追求高质量的代码。在一段时候后业务越堆越多再去添加新功能越来越麻烦,又需要我们重构代码。这些问题是非常矛盾的,我们如何去判断何时该进行代码抽象?何时又该去重构?

God, Grant me
the serenity to accept the thing I cannot change,
the courage to change the thing I can change,
and wisdom to separate the difference.

业务开发中如何避免过度设计?

DRY原则

DRY原则是Don't repeat yourself 的缩写,DRY原则想要表达的是:系统内的每一个知识点都应该是单一,明确,权威的标识。同样的功能不应该重复多份实现,应该提取成一个共用的功能。

YAGNI原则

YAGNI原则是You aren't gonna need it 的缩写,YAGNI原则主要含义是:不要添加多余功能除非那是必需的。

Rule Of Three原则

Rule Of Three原则是指当一个功能直到第三次出现时,才进行功能提取。为什么是三次?在数学领域如果要提取一个模型:

Complete the pattern:
1, 2, _, _, _, _
复制代码

当这个模型只出现2次时,推导完整的模型是非常不清晰的,依靠出现2次的话可能有以下模型:

1. x2 模型
1, 2, 4, 8, 16, 32
复制代码
2. +1 模型
1, 2, 3, 4, 5, 6
复制代码

如果出现3次才进行模型提取:

Complete the pattern:
1, 2, 3, _, _, _
复制代码

这个时候得到的模型将更加清晰,只会是+1模型。通过第三次重复才开始提取能更加确定这个模型,在代码中同样适用这个理论,这样能避免提取错误模式情况下的浪费时间。

计算机领域其实有很多地方有3这个数字,比如HTTP需要最少3次握手才能建立信任关系下的稳定连接。并不是说大于3次不行当然是越多越好,但是3次是最少的次数。

总结

软件开发中如果不依靠这些原则,假设有足够的经验和直觉下:

我们只看到一次出现的代码就进行抽象,这可能非常耗时因为特定场景的不同很多细节也有差异,这些差异会出现在抽象代码中,你的经验和直觉可以给出更好的设计,但还是有风险。所以现在只管去做先不要抽象。

第二次出现就抽象能让我们更好的了解哪些细节需要出现在抽象代码中,哪些不需要。但是抽象模型不够清晰,可能在第三次出现时需要大量修改逻辑,这样还是很费时。所以在第二次重复出现时不去抽象非常让人反感,但是还是可以非常快的copy过去进行修改。

第三次出现再抽象,基本魔板已经确定,所有细节哪些需要抽象哪些不需要的也能确定。哪怕第四次出现的偏差也能快速确定是否需要抽象,快速调整。

上面介绍的三个原则相互补充,尽可能完善的指导我们何时才需要对代码进行抽象。帮助我们快速开发,节约时间。

何时重构?

什么是重构?有两种解释:

重构(名词):对软件内部结构的一种调整, 目的是不改变软件可观察行为的前提下 ,提高其可 理解性降低其修改成本

重构(动词):使用一系列重构手法, 在不改变软件可观察行为的前提下 ,调整其 结构

何时重构?

  1. 添加功能时重构

我无法理解之前的代码。

代码的设计无法帮助我们轻松添加我嗦需要的特性。

  1. 修复Bug时重构

代码结构复杂不容易看出bug,这时重构能帮助我们理清逻辑。快速看出Bug。

  1. review代码时重构

review是很有价值的事,在review过程中可以阅读其他人的代码提出更多恰当的建议。同时重构能帮助我们更好的理解代码,提出更有意义的代码。但要记住一个团队中保留多个意见也是很有必要的。

以上重构时间排列是有先后顺序,同时重构前需要有足够的测试用例或单元测试支撑。重构遍布在每个版本开发过程中。

以上引用内容摘自 《重构 改善既有代码的设计》 ,非常推荐。

总结

过度设计非常浪费时间,想半天可能再最后全盘推翻。绞尽脑汁,封装极好的模块可能就一个地方在使用。

重构是软件开发过程中不可缺少的一环,重构应该伴随在整个版本开发过程。

希望上面两点总结,能对大家有用。:)


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

马云现象的经济学分析:互联网经济的八个关键命题

马云现象的经济学分析:互联网经济的八个关键命题

胡晓鹏 / 上海社会科学院出版社 / 2016-11-1 / CNY 68.00

互联网经济的产生、发展与扩张,在冲击传统经济理论观点的同时,也彰显了自身理论体系的独特内核,并与那种立足于工业经济时代的经典理论发生显著分野。今天看来,“马云”们的成功是中国经济长期“重制造、轻服务,重产能、轻消费,重国有、轻民营”发展逻辑的结果。但互联网经济的发展却不应仅仅止步于商业技巧的翻新,还需要在理论上进行一番审慎的思考。对此,我们不禁要问:互联网经济驱动交易发生的机理是什么?用户基数和诚......一起来看看 《马云现象的经济学分析:互联网经济的八个关键命题》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试