V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
BigDogWang
V2EX  ›  程序员

写架构设计文档有感

  •  
  •   BigDogWang · 2020-02-05 15:51:31 +08:00 · 3430 次点击
    这是一个创建于 1782 天前的主题,其中的信息可能已经有所发展或是发生改变。

    原文发布在我的微信公众号


    前段时间写了篇架构设计文档,一直想就这件事聊点什么,结果一拖就拖到现在了。算起来这是我第二次写架构设计文档了。一路摸爬滚打,算是有一点点领悟,也不知道对不对,就随便说说。

    很多人觉得架构文档没有什么写的,或者说不知道要怎么写。其实我觉得这是因为自己对架构、或者对业务需求并不是那么理解。如果真的理解了,再来写这个文档,会发现真的有很多可以写的地方。因为你在明白架构设计文档的目的、作用后,就知道这个东西不仅仅是拿来糊弄公司的,而是真的有指导意义的。

    首先要理解架构设计文档的作用,架构设计文档其实对项目开发是有很大帮助的,而且在写架构设计文档的过程中,也能让设计师认真的重新梳理一遍业务需求,从而有针对性的去设计,而不是在写代码过程中临时决定要用什么方法去写。

    突然想起之前面试的时候问面试者,架构是什么? 听到的回答五花八门,什么都有。有的人干脆就说架构就是 MVC,MVP 等等,让人有点无奈。我在这里简单聊一下我的理解。

    什么是架构?

    架构这个词其实并不是软件领域专有的。它甚至可以追溯到人类起源的时候。

    刚开始人类只有很简单的需求:有东西吃、有地方睡。一个人就能做完所有的事情。但是随着需求变得多样性,还有技术领域的细分化,一个人做不完所有的事情了,而且也学不会那么多技能。这个时候社会分工就出现了。随即演变出了社会组织架构。包括现在的企业组织架构,都是为了更好的分工而生的。

    建筑中的架构也是类似的。一开始就一个茅草屋,一个火坑,简简单单的屋子就够了,不需要什么架构设计。随着社会的发展,人们对建筑功能的需求也越来越多,空间的切分也越来越细致。以居所为例,出现了客厅、餐厅、厨房、卧室、卫生间等专用空间。随着人们对空间划分变得细致、空间组合变得多样,建筑架构就应运而生了。

    那么在软件领域,架构最根本的目的,我认为也是为了让一个团队能更好的分工,进而更好的合作


    之前说了,写不出文档一方面是因为对架构理解不到位。另一方面就是因为对业务需求理解的不到位,那么为什么业务需求对架构这么重要呢?

    什么是业务需求?

    业务在很大的程度上决定了一个团队的分工。但是在讲业务需求之前,我想先聊一下程序员所需要解决的两类问题

    第一类就是生意问题。我们制作的软件,其实都是为了做生意。而且很多时候,这个生意没有了软件一样能做,只是比较低效而已。我们只是生产了一个工具,可以提升做生意的效率

    另一类问题,就是计算机问题,是用来支撑我们去生产这个工具的,比如计算机、数据库、网络等等,都是为了更好的支撑我们去模拟做生意的过程。

    这两类问题,都会对我们的架构设计产生或深或远的影响,所以一定要在设计前就有一定的了解。

    接下来聊聊业务需求为什么会对架构设计产生深远的影响。我们先看一下建筑的用途是怎么影响到建筑的架构的。

    像农村里的普通住宅(一般规模),砖混结构就够用了;城镇的中低层住宅楼(规模变大),就需要框架结构;高层住宅(规模进一步变大)的结构也不一样,是核心筒 + 剪力墙;至于像机场、车站这种需要超大空间的建筑体(另一种使用场景),则又需要大跨结构。你看,建筑上不同的空间诉求,对架构的要求也是不同的。

    回到软件领域,不同的业务,它的特点也不一样。像活动这种,天天在变,那么架构设计上就需要考虑快速迭代和快速开发;像日志系统,每天都有大量写入,但是读取比较少,所以在设计的时候也要考虑性能和稳定性等因素。不同的业务需求,有不同的特性,我们要在架构设计的时候就考虑进去这些特性,并且尽力去满足这些需求。

    在这里我再多嘴一句,很多时候我们接收到的任务,其实是别人给过来一个解决方案,并不是他想解决的问题。我们要学会识别这个陷阱,因为别人给的解决方案可能并不是最优的解决方案,甚至可能是错的。我们需要直面问题,然后解决问题,这样是最高效的。

    怎么写架构设计文档

    说了这么多,到底要怎么写架构设计文档呢?

    我觉得架构文档最应该体现的就是:对业务需求的合理分解,以及对各个子业务的特性的理解。对业务进行了合理的分解后,我们的项目就有了一个比较合理的骨架,这个骨架就是我们的底层架构。然后再对每个子模块做概要设计,随后将底层架构和上层的各个子模块的设计进行融合。其实这个过程就是一个化繁为简的过程,将繁琐的业务转化为一个个关键类和协议接口。

    到了这一步,我们对业务已经有了很明确的认知了,自然也清楚每个模块的特性,此时再做技术选型,就有很强的目的性了。这样一来计算机问题也就随着业务问题一起解决了。


    这里有一个文档纲领,只要思路正确,直接填鸭也没啥问题。

    一、概述
    二、目的
    三、项目背景
    四、系统建设目标
    五、参考资料
    六、架构设计
    6.1 架构分析
    6.2 设计思想
    6.3 架构体系
    6.4 系统视图
    6.5 模块划分
    6.5.1 模块描述
    6.5.2 模块接口
    
    5 条回复    2020-02-06 19:40:39 +08:00
    linbomb
        1
    linbomb  
       2020-02-05 21:30:38 +08:00
    DEVN
        2
    DEVN  
       2020-02-05 22:06:18 +08:00
    有那么点意思 👍
    dreamerlv3ex
        3
    dreamerlv3ex  
       2020-02-06 09:10:13 +08:00
    努力向大佬们靠近
    arlicle
        4
    arlicle  
       2020-02-06 10:49:22 +08:00
    安利你一个接口设计和管理工具,超好用:Panda Api,它能够生成文档、提供接口模拟服务(在你没写任何代码之前)、自动测试后端接口,[https://github.com/arlicle/panda-api]( https://github.com/arlicle/panda-api)
    BigDogWang
        5
    BigDogWang  
    OP
       2020-02-06 19:40:39 +08:00
    咋全都是收藏😂
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   914 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 19:45 · PVG 03:45 · LAX 11:45 · JFK 14:45
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.