最新消息:欢迎访问Android开发中文站!商务联系微信:loading_in

软件开发工作过程中的一些总结

热点资讯 loading 426浏览 0评论

声明

  • 本文还在不断完善中,更多的是希望能引起思考,不要照搬。

核心

  • 尽最大可能帮助企业更加高效协作,以更好的数字化体验吸引客户,同时让维护更加容易、低廉。
  • 每个公司的组织结构都有其特点,本文无法直接套用,需要根据其结构优化调整
  • 持怀疑态度对待任何问题,包括本文任何字眼,多思考。
  • 有序、规范化不等同于要失去灵活,它们之间有一个度,而我们再寻找那个度、平衡

理念

  • 敏捷:快速响应市场的变化,争取活下来,再谈盈利。
  • DevOps:开发运维一体化,目标一致,高效沟通、配合。
  • 测试驱动开发(TDD):有助于做更好的开发质量,协助开发量化指标,从而有更高效的响应。
  • 无状态:保证 API 接口可伸缩性
  • 功能开关:开关多样化可以尽可能避免回滚和多次发布
  • 分享精神,促进沟通,凝聚力根本(必须)
    • 开发总结,文章分享(必须)
    • 优质文章,开发分享心得
    • 图书分享
    • 教程分享
    • Switch 游戏分享

会议

  • 项目启动会
    • 需求概要
    • 利益关系
    • 主要目标
  • 每日站立会(15 分钟)
    • 前一天工作内容
    • 遇到什么困难
    • 今天计划工作内容
  • 项目交接演示会
    • 总体功能点描述
    • 主流程演示
    • 具体功能模块演示
    • 客户反馈
    • 首次交付的开始也是真正考验的开始
  • 项目回顾会
    • 需求、分析、设计、演化、交付过程中各个心得
    • 技术分享

过程文档

  • 产品
    • 产品说明书(Markdown)
    • 产品需求文档(Markdown)
    • 产品操作手册(Markdown)
  • 开发
    • 项目设计文档(包括概要、详细),突出流程图,关系图,结构图,文字描述尽可能少。(Markdown)
    • 数据库实体关系图(表结构关系 ER 图)(StarUML)
    • 详细表结构设计(协同 Excel)
    • API 接口(Swagger API、YAPI)
    • 测试用例(Markdown)

团队常见问题(尽可能避免)

  • 目标不明确
  • 人员不稳定
    • 增加人手并不能百分百增加效率,除非是有计划的调整,不会影响到现有团队成员的进度。
  • 工位不集中(借调)
  • 有各类原因的干扰
  • 多种不同类型的需求并发一起处理
  • 需求不够细化
  • 团队角色模糊
  • 需求变更
    • 无法避免的事实,它也是让软件不断退化的主要原因
    • 尽可能 持续有效的沟通 是避免不断返工的最好办法之一
    • 变更发生得越早,风险越小
  • 测试工作在开发结束后有大量堆积
  • 每个工程师在沟通能力、技能水平、主动性、服从性、一致性、责任心上都有着巨大差异,每个人都是需要特殊对待。
  • 与外部沟通不顺畅
    • 上游协作:客户
    • 下游协作:运维
    • 交叉协作:其他开发团队

需求、任务、问题的跟踪

  • TAPD
    • 看板
    • TAPD 敏捷全生命周期项目
  • JIRA

开发环境搭建(统一所有版本)

  • JDK
  • IntelliJ IDEA
  • Git
  • Maven
  • Node
  • MySQL
  • MyCAT
  • 中间件版本
    • Redis
    • RabbitMQ
    • Kafka
    • Zookeeper
  • 大数据
    • Flink
    • Hadoop
  • 自动化
    • 严格禁止漏提交引起的无法构建行为
    • Gitlab
    • Jenkins
    • Sonar
    • Nexus
  • 部署
    • CentOS
    • Zabbix
    • Nginx
    • ELK
    • Ansible
    • Docker(Portainer、Rancher、K8S)
  • 开发系统
    • macOS(黑苹果优先)
    • Windows 10
    • Ubuntu
  • 硬件(个人提供)
    • 便携投影仪
    • MacBook Pro

测试环境搭建

  • 数据库
    • 清洗个人隐私数据(密码、身份证、手机号、邮箱地址、居住地址)
    • 数据同步规则、同步周期
  • 自动化测试
    • TestNG + Selenium,UI 自动化
    • TestNG + Http,做接口自动化
  • 压力测试
    • Gatling + Maven(优先)
    • JMeter

运维生产环境搭建

  • 服务器监控(Zabbix)
  • 跳板机
  • 防火墙(端口)
  • 基础服务(版本与开发环境一致)

项目流程(路线)

  • 需求
    • 明确利益关系,特别是多方利益
      • 多方利益的情况,尽可能先与每个利益方单独沟通,遇到矛盾需要再沟通和划分利益优先级
      • 多个利益方一起沟通很容易得到更多需求,不易于需求把控
      • 对于 信息透明化 的点,需要大家自行把控
    • 持续有效的沟通
    • 调研、写需求、画原型
    • 划分需求优先级,明确迭代周期
    • 标出不确定域
    • 客户需求确认
    • 召集:需求评审
  • 项目组长
    • 根据需求写系统设计说明书(召集评审)
    • 细化主要开发任务(TAPD)
    • 召集:估算扑克
  • 前端开发
    • 细化前端需求任务(TAPD)
    • 根据需求和原型实施前端组件
    • 前后端联调
    • 冒烟测试,确保主流程
    • 主流浏览器性能调优
    • 召集:代码评审
  • 后端开发
    • 细化后端需求任务(TAPD)
    • 根据需求、原型、系统设计说明书开发功能
    • 监控埋点
    • 前后端联调
    • 冒烟测试,确保主流程
    • 单元测试(优先保证主流程:新增 + 删除 + 单个查询 + 分页查询的单元测试)
    • 微基准测试
    • 接口压力测试
    • 测试人员测试出的功能:必须写单元测试
    • 召集:代码评审、SQL 审查
  • 测试开发
    • 细化测试需求任务(TAPD)
    • 根据需求写接口自动化测试用例(优先保证主流程)
    • 根据界面写 UI 自动化测试用例(优先保证主流程)
    • 冒烟测试,确保主流程
    • 回归测试
    • 压力测试
    • 召集:测试报告分析和反馈
  • 运维部署
    • 根据系统设计说明书,预先调研部署结构,部署脚本,网络评估,系统监控
    • 自动化部署环境准备
    • 自动化测试环境准备
    • 压力测试环境准备
    • 蓝绿部署支持
    • 金丝雀发布支持(尽可能采用随机样本)
    • 召集:监控报告分析和反馈
    • 升级回滚设计
      • 开关设计的回滚
      • 整个环境回滚
      • 回滚脚本设计
      • 数据库补丁回滚设计

接口压力测试

  • 上层 API 接口:95% Line 控制在 3 秒以内
  • 底层 API 接口:95% Line 控制在 300 毫秒以内
  • JVM 异常监控(VisualVM、JProfile)

源代码管理

  • Gitlab
  • Git flow
  • 项目版本号:SemVer 标准

认证

  • OAuth 2.0 协议

细化监控、反馈

  • 服务器监控
  • 应用程序监控
  • 流计算
  • 日志监控
  • 对错误进行响应
  • dashboard
  • 邮件/IM 通知

容量规划

  • 长期容量规划
  • 短期容量规划

Wiki 管理

安全

  • SQL 注入
  • CSRF 跨站请求伪造
  • XSS 跨站脚本
  • 密码加盐再加密
  • OAuth 2.0
  • 对称加密(AES) + base64
  • 非对称加密(RSA) + 签名和验签方式
    • 请求参数
    • 按照第一个字符的键值 ASCII 码递增排序(字母升序排序),如果遇到相同字符则按照第二个字符的键值 ASCII 码递增排序,以此类推。
    • 将排序后的参数与其对应值,组合成 “参数=参数值” 的格式,并且把这些参数用 & 字符连接起来,此时生成的字符串 为待签名字符串,类似格式:aa=11&bb=22&cc=33
    • 签名:安全BASE64(SHA256WithRSA(代签名字符串 + 私钥))

后端开发 KPI 设定

  • 分为 A、B、C、D 四个等级,采用加分、减分计算方式
  • C
    • 正常情况
  • D
    • 有生产事故
      • 超过 1 小时无法恢复,必然 D
      • 有财务风险,必然 D
      • 1 个小时内恢复
        • 无投诉,无财务风险,不影响
        • 有投诉,最高加分到 B
    • 测试反馈报告显示质量低
      • 由于个人原因,超过 30% 的功能需要返工,必然 D
      • 缺少核心主流程单元测试,必然 D
    • 有个人原因的异常,阻碍其他人、小组进度
      • 每月累计阻碍累加超过一天(7 小时),必然 D
      • 每月累计超过半天(4 小时),最高加分到 B
  • B
    • 小组类优秀文章(没有减分行为前提)
    • 小组类优秀文章定义:组内成员打分,去掉最高、最低分取平均分
  • A
    • 公司类优秀文章(没有减分行为前提)
    • 公司类优秀文章定义:公司开发主管打分,去掉最高、最低分取平均分
    • 主动改良系统瓶颈性能(提高 30%),并经过压力测试的考验,各开发主管审核代码。(有任何减分行为不影响)

转载请注明:Android开发中文站 » 软件开发工作过程中的一些总结

您必须 登录 才能发表评论!