基于架构的软件设计（Architecture-Based Software Design，ABSD） 是一种架构驱动的设计方法，强调通过功能分解、选择架构风格和使用软件模板来实现质量和业务需求。

功能分解

功能分解是ABSD方法的基础之一。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。通过这种方式，可以将复杂的软件系统分解为更小、更易管理的模块，从而提高系统的可维护性和可扩展性。常见的方法包括：

领域驱动设计（DDD）：通过领域建模拆分功能。
模块化设计：将系统拆解为多个独立模块，以降低耦合度，提高可维护性。

选择架构风格

选择合适的架构风格是实现质量和业务需求的关键。不同的架构风格可以满足不同的需求，例如分层架构、微服务架构等。在架构设计阶段，通过选择合适的架构风格，可以确保系统在满足功能需求的同时，也能满足性能、可扩展性等非功能需求。

使用软件模板

软件模板是ABSD方法的另一个基础。软件模板是一种特殊类型的软件元素，描述了这种类型的元素在共享服务和底层构造的基础上如何进行交互。在软件产品线系统中，软件模板显得格外重要，因为新元素的引入是一个通用的技术，用来使产品线架构适应一个特定的产品。如选择合适的设计模式：

• 工厂模式（Factory Pattern）：用于创建对象，提高代码复用性。
• 观察者模式（Observer Pattern）：适用于事件驱动系统，提高解耦性。
• MVC 模式（Model-View-Controller）：适用于前端和后端分离的 Web 应用。

基于架构的软件开发模型

ABSD模型把整个软件开发过程划分为六个主要阶段：架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化

项目实施流程中，评审是很重要的一环，并且复杂的流程会有各种评审，比如需求评审，概要设计评审，详细设计评审， 用例评审等。 为什么需要有这么多评审？ 不评审会有什么影响？ 为什么很多开发人员反感评审，认为很多评审浪费时间？ 原因是对评审的目的和收益不理解，或其参与的评审已变质。 评审核心目的形成共识， 好的评审可以大大降低项目延期风险。

项目延期是工程研发过程中经常遇到的问题， 也是过程管理的一大难点，是体现项目经理管理能力的一大指标。 项目延期的原因有很多，根据个人几十个项目经验分析， 大部分原因是评审执行不到位。有的是评审退化为宣贯，有的是评审变成了批斗会， 还有的是根本取消了评审，其后果就是很多时候它就会在延期项目的反思会上会被拿来作为根因（很多时候再下一层的根因是不会去反思的）。个人遇到过的与评审有关延期理由有：

• 与产品理解不一致，导致开发返工。
• 产品逻辑不严谨，需要加需求。
• 测试回归发现，与前产品产生兼容性或逻辑性问题。
• 第三方原因导致。

以上几种或多或少都是因为没有共识，而一边项目中主要形成共识方式就是评审，因此这类延期大部分是与评审有关的， 有可能是没有评审（一般是小需求），或评审只是走形式退化为宣贯， 或评审组织出问题没有达到应用的目的。 那么什么时候该有评审，又如何组织评审呢。

我们都知道开发过程中很多阶段都是可以有评审的， 严格执行的话会导致评审形式化，评审成本增加，所以项目实际实施的时候确实很多评审会精简掉，到底哪些是需要保留呢？根据个人经验来看，存在以下情况需要保留对应的评审：

• 需求涉及多人或多方式时，必须有需求评审, 除非连专门测试都不需要的小需求外，因为需求评审是达成需求共识的最佳方式。
• 技术方案里涉及三方（调用或输出接口），或做了特殊解决方案时，必须要有技术方案评审。核心目的在于确认研发验证对需求理解
• 新项目需要有独立概要设计评审， 这对共识技术架构方案， 规范的统一有重要作用。
• 测试用例评审。 如果有测试接入，则用例评审是不可缺少。核心目的达成需求理解共识，确认测试的覆盖度。

个人认为开发过程中的评审不是能省则省的，而是要有尽有。 我们会发现项目里该有的评审都有，但还是经常出现理解偏差； 另外，是否项目里除了Leader 都方案评审。 这其实都评审实时问题， 为了让评审目的能够实现， 有几个方面是容易忽略却对评审目标达成有关键作用的。

• 大范围的评审，评审资料需先进行组内，或组织相干专家先进行小范围讨论，确认无颠覆性问题。
• 评审需要安排在整体项目开发计划中。 不是临时找时间，特别找非工作时间来安排， 评审的目的是发现问题达成共识，类似头脑风暴，是需要消耗参与的相干人员大量精力的。一般需要提前安排，且安排到上午，或下午上班1小时后。
• 评审资料要提前将资料发送到参与评审的相干人，且要求核心相干人员（如明确的关联研发，产品，测试等）充分了解。 可以采用协同编辑的问题收集列表方式，即使没有问题的也需要填写”无相关问题“，被评审人不用评审前去核对问题列表，以免造成干扰。被评审人讲解完，需标记问题列表的问题是否还存在，且记录新产生的问题。需要避免相干人临时进会， 导致对于相干人来讲评审会变成宣贯会。
• 评审会议不要变为问题解决会。 被评审人需要把握节奏，只做宣贯方案，解决理解偏差导致共识问题，其他问题如逻辑问题，遗漏问题等只做记录，避免直接讨论解决方案或修改方案。后续可小范围讨论解决， 解决方案通知各项目参与人，特别注意不要只解决不通知， 避免解决方案导致关联方出新问题。
• 参与评审人员应关注实质性问题。 即提问题要核心关注当前评审内容， 不要关注一些非实质问题，如文档格式，措辞等等， 也不要提自己联想到的与当前评审内容无实质关系的问题。
• 重视评审的组织。 首先相关负责人需要重视起来，注意组织工程，会议时间， 相干人选择， 通知， 场所都要有要求。 另外，除被评审人外，有一个主持人，主要把控会议流程，及时组织偏离目标的讨论。

总的来说，核心的问题还是要重视评审，特别是相关负责人，需要起到带头作用，带领并督促组员形成对评审重视的风气，不要让评审形式化，也不要评审变宣贯。

1. InvalidVersionSpecError: Invalid version spec: =2.7

anaconda 版本低导致， 下载了官网最新版本后解决。

2. anaconda SSLError(MaxRetryError(‘HTTPSConnectionPool(host=\’mirr

在命令行中输入conda config --set ssl_verify false修改设置，或者在文件~/.condarc末尾添加一行ssl_verify: false（有则修改即可）, 或将配置的源https改成http

3. jupyter连接不到内核, 后台400错误

 nginx 转发导致， 增加 web socket 支持
location  /api/kernels/ {
                proxy_pass            http://notebook;
                proxy_set_header      Host $host;                
                proxy_http_version    1.1;  # websocket support
                proxy_set_header      Upgrade "websocket";
                proxy_set_header      Connection "Upgrade";
                proxy_read_timeout    86400;
        }
        location  /terminals/ {
                proxy_pass            http://notebook;
                proxy_set_header      Host $host;                
                proxy_http_version    1.1;  # websocket support
                proxy_set_header      Upgrade "websocket";
                proxy_set_header      Connection "Upgrade";
                proxy_read_timeout    86400;
        }

4. AttributeError: type object IOLoop has no attribute initialized

conda install -c conda-forge jupyter-lsp

5. 404 GET /api/kernels/

conda install -c conda-forge ipywidgets

conda install -c conda-forge jupyter-collaboration

conda install -c anaconda pyzmq

conda update setuptools