美文网首页
架构思考读书笔记 六

架构思考读书笔记 六

作者: syserr | 来源:发表于2018-12-29 15:37 被阅读0次

    维护技术

    尽然已经把这项技术引入到公司或项目,那么就需要持续的维护它。使用一些质量指标可以衡量它对当前软件架构的影响,具体如何进行,请参考后面的内容。

    质量属性

    质量属性,其实就是软件系统的非功能特性。对客户来说,他们更关注的肯定是显而易见的功能属性,除此之外他们根本不关注。但是,作为架构师,一定要站在更高的角度,看到这些非功能性需求的重要性。

    在之前我们曾称针对这些质量属性的设计为DFX(Design For X),这个里面的X指的就是各种各样的非功能特性,一般包含这些方面:

    • 可维护性;
    • 可扩展性(伸缩性);
    • 可靠性;
    • 安全性;
    • 易部署性;
    • 简单性;
    • 可用性;
    • 兼容性;
    • 容错性;
    • 隔离性(解耦性);

    其实,除了列表中的内容,还有很多其它的方方面面,具体哪些属性需要重点考虑,这个和产品的应用场景强相关。架构师在设计时,不可能在所有方面都做到最有,只能有选择性的增强。而且,有些质量属性是互斥的,比如安全性和可用性,如果要保证密码安全性,规则就会非常复杂,无法保证可用性,因为没有人能记住一长串大小写字母数字特殊字符。

    所以,架构师的另一个主要工作就是在这些质量属性之中进行取舍、衡量。并且需要让管理层认识到这些质量属性的重要性,以及你选择某些属性而放弃其它属性的可靠理由。

    不过,这一步有些困难,因为对于管理层来说,他们可能会认为,功能实现完成就行了,这些无用的东西可以不用关注,你需要想办法让他们看到实现这些质量属性可以带来哪些好处,如果不实现,将会有什么样的后果。

    另外,为了让管理层认识到这些特性的重要性,尽量不要用“非功能性需求”来描述,可以使用“质量属性”、“质量需求”来称呼,因为它们确实事关产品质量。

    对质量属性打分

    假如我们手上已经有了一堆质量属性需要关注,那么具体要实现哪些,抛弃哪些呢?这时,就需要对每一个质量属性进行打分,在实现时,我们只关注那些分值较高的属性;

    不过,打分也是一个比较主观的过程,因为从不同的视角来看时,关注的点可能不一样,所以架构师进行打分时尽量综合考虑各种情况,并在每一个打分后面,有一列备注说明为什么打这个分。

    另外,对于分值比较低或者不打算考虑的属性,最好也一起列出来(包括理由),至少表明你不是完全没有考虑到它们,而且还可以避免一些争论,比如“我认为XXX属性也很重要”。

    文档说明质量属性

    不要使用过于复杂的文档,也不要依赖特定软件才能查看,最好是可打印的文本或图片,方便分享和交流。

    将质量属性加入到架构

    当已经确定了要实现某些质量属性时,架构师就需要考虑在系统中如何实现这些能力。对当前的架构有什么影响,以及如何改进架构来适应这些能力,可以通过下面这个简单的表格来描述:

    优先级 质量属性 应对策略
    1 可用性 UX在设计界面时,尽量考虑到用户不需要任何培训和文档,就可以直接上手使用
    2 安全性 实现分权分域管理;个人敏感信息加密;

    制定准则

    作为一个架构师,不可能在每时每刻都盯着每一个开发人员,也没有经理关注到项目实施的每一个细节;但是,我们可以执行一些准则,或指导性框架,开发人员可以参考这些内容,做出正确的判断;

    一般架构师的职责是制定一些决策,从而构建出一个系统的不变框架,然后有开发团队补充血肉。但是,我们都知道,唯一不变的就是变化,架构也需要不变演进,因为我们没法预判未来,一步到位。

    架构演进

    业务我们可以改变一些假设,不是设计好一个固定的架构,然后被迫改变;而是,一开始就设计一个允许改变的架构?

    这种架构的目标不是说一次性构建全部的能力,而是分别构建可部署的单元,然后把这些单元组装起来,形成一个系统。之后的变动可以局限在单元内部、引入新的单元、或改变单元的组装方式,这些变化都是可以接收的。

    见证功能

    见证功能,这个词来源于可演变的计算。当一个算法变异时,我们会管着它是向好的方向发展,还是坏的方向?需要有一个评判专责,“见证功能”就是这样一个准则,用来评判对架构的影响。

    首先,需要识别出当前项目的关键目标;然后,你怎么来评估这些目标是否满足;现在,你就可以制定一些见证功能了,例如:

    • 所有的服务必须在100毫秒之内响应;
    • 如果有应用挂掉,应该立即自动创建一个新的实例出来;

    记住,架构师不是测试人员,你不可能验证所有的功能,需要分析并识别,制定核心的见证功能,并且这些动作完全和系统的实现逻辑无关,可以在系统实现之前进行制定,需要考虑以下几点:

    • 关键性: 非常关键的决策点或结果;
    • 相关性: 考虑到的,不应该对系统架构产生影响的点;
    • 非相关性:不应该影响我们的决策;

    将你的见证功能列表公开,让所有的人都可以看到,你也应该定期更新这个列表,以保证覆盖性。

    其实,这个见证功能,和我们之前的“门槛用例”比较相似,保证我们系统的核心能力的稳定性,不管做了任何变动,这些用例都应该是通过的。

    实践:

    引入一项新技术仅仅是一个开始。你需要确保你的产品在一个生命周期内正常运转。可以参考以下几个实践:

    • 识别出当前产品的关键质量属性,并打分;
    • 和同事讨论这些评分标准;
    • 制定出见证功能列表,用来验证这些关键的质量属性;

    终结

    架构思考读书笔记 一
    架构思考读书笔记 二
    架构思考读书笔记 三
    架构思考读书笔记 四
    架构思考读书笔记 五
    架构思考读书笔记 六

    相关文章

      网友评论

          本文标题:架构思考读书笔记 六

          本文链接:https://www.haomeiwen.com/subject/qqqplqtx.html