软件设计之美
郑晔
开源项目 Moco 作者
19890 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
软件设计之美
15
15
1.0x
00:00/00:00
登录|注册

01 | 软件设计到底是什么?

你好!我是郑晔。
一个软件需要设计,这是你一定认同的。但软件设计到底是什么,不同的人却有着不同的理解:
有人认为,设计就是讨论要用什么技术实现功能;
有人认为,设计就是要考虑选择哪些框架和中间件;
有人认为,设计就是设计模式;
有人认为,设计就是 Controller、Service 加 Model;
……
你会发现,如果我们按照这些方式去了解“软件设计”,不仅软件设计的知识会很零散,而且你会像站在流沙之上一般:
今天你刚学会用 Java,明天 JavaScript 成了新宠,还没等你下定决心转向,Rust 又成了一批大公司吹捧的目标;
你终于知道了消息队列在解决什么问题,准备学习强大的 Kafka,这时候有人告诉你 Pulsar 在某些地方表现得更好;
你总算理解了 Observer 模式,却有人告诉你 JDK 中早就提供了原生的支持,但更好的做法应该是用 Guava 的 EventBus;
你好不容易弄清楚 MVC 是怎样回事,却发现后端开发现在的主要工作是写 RESTful 服务,Controller 还没有用,就应该改名成 Resource 了;
……
我们说,软件设计要关注长期变化,需要应对需求规模的膨胀。这些在不断流变的东西可能还没你的软件生命周期长,又怎能支撑起长期的变化呢!
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

软件设计不仅仅是技术实现和框架选择,而是在需求和解决方案之间建立桥梁。核心在于构建模型,描述业务实体和功能组件。模型应具有高内聚、低耦合特点,并可分层构建。良好的模型能有效隐藏细节,提高理解和扩展性。规范约束也是软件设计的重要组成部分。缺乏统一规范会导致项目混乱,规范不符合软件设计原则也会带来问题。模型与规范相辅相成,项目初建模型需符合规范,规范制定也依赖于模型。软件设计应包括模型和规范。文章强调了软件设计的重要性,以及模型和规范的相互关系。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件设计之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(52)

  • 最新
  • 精选
  • 段启超
    防腐层是模型的一个规范,分享下我对防腐层的认知: 我接触防腐层的概念是从DDD的限界上下文开始的。Eric用细胞膜的概念来解释“限界”的概念,细胞膜只让细胞需要的物质进入细胞,同样,我们的代码之间业务也存在这个样一个界限,同一个对象的业务含义在不同的上下文中是不一样的。以在网上买书为例,在购买页面,我们的关注点在于这本书的名称,作者,以及分类,库存等信息;提交订单后,这本书就成为了订单上下文中的一个订单item,我们会关注这个item 的数量以及购买他的人是谁,以及书的配送地址等; 订单提交给仓库后,仓库会关心这本书还有没有库存,以及打包状态,分拣,物流等状态。 防腐层是在限界上下文之间映射(说白了就是交互)的方式,体现在代码上就是一个对象的转换,这个转换的意义在于隔离变化,防止因为对象在一个上下文中的变化扩散到其他的上下文中。 关于规范: 规范也是团队文化中很重要的一部分,以持续集成为例子,它的执行严格依赖于团队的开发纪律文化,以为了所谓赶进度而单元测试覆盖很低或者直接不写;采用分支策略方开发,一星期都合并不了主干,类似的人到处倒是,也就因为这一点,很多团队都在持续集成这个环节上掉队了。所以开发规范真的很重要,时刻谨记:混乱始于没有规范。

    作者回复: 非常好的补充!

    2020-05-26
    6
    97
  • 西西弗与卡夫卡
    业务讨论之后进行领域设计,画出出静态模型(包括子系统、模块等)和动态结构(交互等),或者先勾勒接口(内内外系统的区隔),再做模型。实际过程有很多反复,并且会进行角色代入,看模型能否支持业务,直到模型比较稳定

    作者回复: 你们做得很好

    2020-05-25
    5
    36
  • Ghoul Zhou
    慢慢的,某个瞬间,突然觉得自己的工作不再是码农,而是软件设计,并且在工作中得到强烈的自我肯定。 一个好的软件设计思路,首先是符合大众习惯行为、符合日常常理,其次再是数据模型设计、技术范畴设计。 一个好的软件设计实现,往往可以很容易兼容正常合理的需求变更,对开发工作来说,掌握其核心,理论与实践相结合,可以事半功倍!

    作者回复: 你把自己当做码农,你就是码农;你把自己当做优秀的程序员,你就是优秀的程序员。心理学上称之为皮格马利翁效应。

    2020-05-25
    33
  • 光明
    简单一点的项目,成员相互讨论(主要讨论业务场景和流程),内心会意即可。 复杂一点的项目,设计一般落脚在粒度较粗的文档上,往往也以说明业务流程为主,很少对实现过程中的细节文档化。 所以,我们的项目设计,模型一般会被业务场景和流程替代。文中的「模型」和「规范」,更多取决于工程师了。。。

    作者回复: 对,你说的确实符合大部分做设计的方式。这种设计的关注点在于实现功能,而非构建模型。 这种做法容易让人忽略掉哪个东西是核心的,是模型,还是流程。流程是容易调整的,而模型如果变了,这个软件整个就变了。做设计的关键是,找到不变的东西。

    2020-05-26
    3
    16
  • 木云先森
    还需要前面有个好的产品经理或是业务专家。以及公司有个好的文化。各种频繁的插队的需求,各种前后都无法闭环的需求。都是,软件产品异常大的阻碍

    作者回复: 《10x 程序员工作法》在先,《软件设计之美》在后。

    2020-05-25
    13
  • 渔夫
    很多软件产品的需求都是一点点冒出来的,甚至中途需求还会去溜出去绕个弯,然后又回归,设计有种被牵着鼻子走的感觉,工期紧迭代快,结果就是设计的模型中有大量名不符实的定义,还有很多定义的补丁,实在很糟心,当然需求发展方向终会明朗,这时候就需要重构整理,包括设计和实现,同时又要应对新的业务开发,于是形成了两线或多线作战,苦啊!这样的情况除了增加团队,不知道老师有什么好的建议?

    作者回复: 先去学《10x程序员工作法》,先别让人给自己捣乱,有一个合理的工作计划。如果你没时间学习,没时间做改进,别的东西都不用说了。 有了一个合理的安排之后,才是说要怎么改进,要怎么做得更好,消除欠下的技术债。

    2020-05-25
    2
    12
  • 迈步
    老师您好,我们有一套基于DDD思想的程序开发模板,我们为了避免个体开发差异,所以建议大家都使用统一的开发模板。目前我面临着两个问题 1、针对某些使用简单分层架构即可解决问题的服务,是允许使用简单分层架构还是使用统一的DDD开发模板? 2、统一开发模板在一定程度上规避了个体差异上的劣势。那么个体差异上的优势如何更好的体现呢?

    作者回复: 把 DDD 当做一个模板,这个理解方式本身是没有问题的,它就是告诉你,如何把设计中的模型分门别类的放置,后面我们讲 DDD,差不多也是这个思路。 对于任何一个系统而言,需求都是一点一点增加的,前期不做设计,后期改动起来,难度就非常大了。所以,核心的点在于,设计要做好,别看它现在简单。分层不是你的设计,而构建出你的模型才是设计。 我不是特别理解你们按照 DDD 思想的开发模板到底是个什么东西,是一个开发框架,还是一个思维工具,所以,不敢妄加判断。 对于一个团队而言,开发的一致性比个性要重要,因为没有人可以保证一直在一个团队工作下去。 如果你真的有不错的理念,去做规范和框架的级别的优化、去做算法上的优化,不要在小的地方体现创造力,意义不大。

    2020-06-17
    10
  • escray
    文章在开篇提出的关于软件设计的问题,其实也是我现在的困惑,因为在做求职前的准备,感觉有很多东西要学,极客时间的专栏那么多,眼花缭乱。如何才能提高自己的求职成功率呢? 软件开发是为了解决问题,而软件设计就是在需求和解决方案之间的桥梁。 对于“软件设计就是构建出一套模型”这个说法,我感觉似乎有点过于抽象了,虽然文中列举的那个交易系统模型,确实很简洁、准确。 如果单独来看“模型”和“规范(约束)”都比较容易理解,但是如果说软件设计就是设计出模型和规范来,又有些不好理解了。特意去看了一下 Wiki: Software design is the process by which an agent create a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints. 感觉上自己以前可能更看重软件开发的结果,而忽视了其中的模型和约束。 在这之前,如果拿到一个项目,大概会先看看是 CS 还是 BS 的,一般会采用 MVC 或者是分层模型,然后再去看看有没有其他的开源软件可以借鉴,之后就开始码程序了,编写代码边修改,可能从整体设计上考虑的比较少。 看了一下留言,发现自己之前可能局限于个体软件作坊,并没有正式或者完整的软件设计过程。那么我有一个问题:软件设计是只适用于相对复杂一些的软件开发过程么?如果程序本身比较简单,而且是那种“用完即焚”式的,是否还需要设计? 另外一个问题,就是软件设计和架构设计的区别在哪里?应该不仅仅是范围大小的差别吧 。 期待后续的专栏。

    作者回复: 非常感谢你的补充! 我不会为 Hello,World 做设计,因为它真的“用完即焚”,在开篇词里我说过,设计是应对需求规模的算法。需求越来越多,设计和不设计的差别就会体现出来。但是,你不学习软件设计的话,想直接应对复杂软件是不可能的。 关于软件的设计过程,我们后面会讲到 DDD,你可以关注一下。 软件设计和架构设计,其实是没有区别的,只不过,通常把高层一些的设计称为架构设计,但我们这里所学的设计原则同样适用于架构设计。

    2020-05-27
    10
  • 学习学个屁
    刚开始按照模型和规范走着,后来随着需求的改动,客户不停的催促,代码改动越来越乱,先把工作完成后再改规范,还是有什么好的办法。

    作者回复: 首先,要分清楚哪些是人为的问题,哪些是设计的问题。赶工绝对是人为的问题,需要设置正确的预期,这是《10x 程序员工作法》讨论的范畴。 其次,如果是设计问题,需要把分清楚哪些是变的部分,哪些是不变的部分。不变的部分花力气去设计,变的部分需要等一等,等它相对稳定一些,再花大力气去设计。 规范主要是针对你需要花力气去设计的部分,混乱的部分,就先混乱着。让子弹飞一会儿。

    2020-05-26
    2
    8
  • 小文同学
    我独立设计的第一个项目整体来说,是失败的。就是盲目模仿前项目,没理解,分层,抽象,接口,模型等设计概念,最终项目陷入很麻烦的技术问题。

    作者回复: 应该说是独立“实现”了一个项目。

    2020-05-25
    2
    5
收起评论
显示
设置
留言
52
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部