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

声明

• 本文还在不断完善中，更多的是但愿能引发思考，不要照搬。
• 首次发表：www.youmeek.com/java-sofawa…

核心

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

理念

• 敏捷：快速响应市场的变化，争取活下来，再谈盈利。
• 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 管理

• 有道云协做
• 腾讯文档
• hexo-theme-Wikitten

安全

• 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%），并通过压力测试的考验，各开发主管审核代码。（有任何减分行为不影响）