信息系统项目管理师

理论知识:

https://www.bilibili.com/video/BV1oN41127QH/

备注

计划报考中项，通过率挺高的，高项就算了

项目组成的一个例子:

  • 后端应用代码

  • 后端测试代码

  • 日志记录

  • 前端应用代码

  • 前端测试代码

  • drone - cicd平台

  • gitea - git平台

  • 文档

渐进式升级

第一阶段: 裸应用代码轻步兵

只实现功能, 简单实现

第二阶段: 自动化测试和运维重兵器

测试驱动开发，devops

第三阶段: 持续迭代优化

大胆优化和重构跟需求无关的应用代码需要多个条件:

  • 足够的测试覆盖率

  • 开明的上级或客户(理解升版出错)

  • 开放的环境，能ssh连接开发环境, 能实施自动化部署

  • 改动的地方保证有对应的测试用例

要满足幂等效应，即当部署出问题时，事故原因应该要能和新需求扯上关系, 并且不影响同事

若以上条件存在一条满足不了, 应该将精力和重新放在重兵器保障下限，只要应用代码能实现功能就可以。 即使满足以上条件，正式动手优化与需求无关的代码前还要好好思考以下几点:

  • 这个项目是否值得我投入时间和精力?

  • 是否发自内心喜欢应用功能?

  • 是否有持续盈利的希望?

  • 真出问题，不能马上解决的情况下能否在第二天处理，而不是当晚通宵解决?

否则，还是建议将时间和精力投入到其他项目或者兼职。

版本号和代码仓库规范

https://blog.csdn.net/weixin_38984879/article/details/124819491

https://semver.org/lang/zh-CN/spec/v2.0.0.html

对标django项目

master分支为生产环境版本 dev分支为测试环境版本

X.Y.Z

X - 主版本号 Y - 子版本号 Z - 修订号

每次增加一个修订号就创建一个tag，每次增加一个子版本号就创建一个新分支，例如:

当前版本号2.0.0, 对应分支v2.0.X, 代码 __version__ = 2.0.0

在v2.0.X分支修复完一个或N个BUG后，修改修订号, 代码 __version__ = 2.0.1 , 发布一个tag: v2.0.1, 依此类推。 有比较大的功能变更或实现，创建新分支v2.1.X, 代码 __version__ = 2.1.0 ，依此类推 出现不兼容变更或者项目重构，创建新分支v3.0.X, 代码 __version__ = 3.0.0 ，依此类推

在docs记录每一次版本号的变更内容，便于日后追踪问题

建议同时维护两个版本，一个是稳定版(LTS)，另外一个是加入了新特性的版本(Current)

django

在server下的 __init__.py 维护版本号

__version__ = '2.4.4'
__date__ = '2023-08-15'
__author__ = '蝉时雨丶'
__contact__ = '397132445@qq.com'

维护多个不同版本的最佳办法

场景

有两个版本, 2.1.X是稳定版本, 目前在生产环境运行, 2.2.X是下一个大版本

构建一个2.1.X和2.2.X的基础分支, 假设命名为dev分支, 当2.1.X发现新BUG时(意味着2.2.X和dev分支都存在这个BUG), 在dev分支创建新分支,假设命名为 fixBUG, 处理完BUG后，同时合并到2.1.X和2.2.X和dev三个分支。

日志

官方文档提供了丰富的 参考案例

使用异步日志

提供应用程序性能

字符串变量拼接使用占位符的方式

import logging
logger = logging.getLogger(__name__)
name: str
# √
logger.info('新增关注, 关注者姓名: {}'.format(name))
# × 降低性能
logger.info('新增关注, 关注者姓名: ' + name)

占位符会先判断日志级别

如果变量是json，使用+号会先进行变量的转换后再判断日志级别，json转换str的过程中会影响性能

所有日志至少保存15天

敏感操作至少6个月, 比如说金钱的提现或修改

避免打印重复日志

造成浪费，底层往外面抛出信息，在接口层收集起来打印日志

error日志应该包含简短信息和异常堆栈信息

logger.error("错误: {}".format(err))

在单元测试覆盖不到的地方打印日志

例如访问外部接口

升级框架

推荐增量更新方法

完整流程参考django文档: https://docs.djangoproject.com/zh-hans/4.2/howto/upgrade-version/

版本控制

一种是一个版本一个release, 对被引用方不友好

一种是同一个代码仓库，v1目录是一个版本，v2目录是一个版本，对被引用方更友好

对于我所在的企业项目中，其实采用第二种方式更合适，因为第一种需要有专人管理版本发布的事项，而目前并没有这个人选对象

标准化开发流程

渐进式阶段+小步重构

渐进式阶段:

第一阶段: 接到需求后, 以最快的速度实现模块功能, 不用管性能和是否优雅, 存在不伤大雅的Bug也没关系，核心功能实现下来就行。 第二阶段: 修复第一阶段留下来的Bug 第三阶段: 以更优雅的代码的实现功能 第四阶段: 以更高效的性能实现功能

小步重构:

从当前阶段重构到下一个阶段, 一有机会就重构, 不停重构，但每次的步伐不要过大。

其他

  • 项目文档开发使用Python的sphinx框架

    • 文档代码统一存放在根目录的docs目录

    • 主题首选sphinx_rtd_theme

  • CI/CD服务器的搭建使用Python的buildbot框架

  • 使用Python的ansible作为自动化运维工具

  • Vue使用选项式API风格编写代码: 可以理解为面向对象的风格，更接近Python的编写习惯

  • npm install 改为 cnpm install, 安装速度更快

  • 静态页面和同步表单使用django模板, 响应式数据和异步表单统一交给vue处理

  • 项目结构统一化命名:

project/docs       ; 文档代码
        src        ; 后端代码
        web        ; 前端代码
        crawler    ; 爬虫代码
        playbooks/ ; 运维脚本
                 deploy.yml ; 部署, 手工触发;
                 release.yml ; 发行, 手工触发;
                 test.yml ; 持续集成;

  • 参与开源项目的挑选优先级: 个人有使用但是没有视频只有文档的, 例如sphinx, 参与插件开发，体积小，容易从github下载

面向对象设计(OOD)

  • 单一职责原则: 设计目的单一的类，与结构化方法的高内聚原则是一致的

  • 开放-封闭原则: 对外扩展开放，对修改封闭；

  • 李氏/里氏(Liskov)替换原则: 子类可以替换父类

  • 依赖倒置原则: 要依赖于抽象，而不是具体实现; 针对接口编程，不要针对实现编程

  • 接口隔离原则: 使用多个专门的接口比使用单一的总接口要好

  • 组合重用原则: 要尽量使用组合，而不是继承关系达到重用目的；

  • 迪米特(Demeter)原则(最少知识法则): 一个对象应该对其它对象保持最少的依赖关系

设计模式

针对重复出现的问题所总结出的最佳经验

创建型模式

用于描述如何创建对象

  • 工厂方法模式

  • 抽象工厂模式

  • 原型模式

  • 单例模式

  • 构建器模式

结构型模式

用于描述如何实现类或对象的组合

  • 适配器模式

  • 桥接模式

  • 组合模式

  • 装饰器模式

  • 外观模式

  • 享元模式

  • 代理模式

行为型模式

描述类或对象怎么交互以及怎么分配职责

  • 模板方法模式

  • 策略模式

  • 命令模式

  • 职责链模式

  • 观察者模式

  • 迭代器模式

  • 访问者模式

  • 中介者模式

  • 备忘录模式

  • 状态模式

  • 职责链模式

sdk开发

实现案例: https://gitee.com/TencentCloud/tencentcloud-sdk-python/blob/master/tencentcloud/tsf/v20180326/tsf_client.py

参见

如何编写sdk?