【项目训练营】 时间轴和知识点分布(全)

为了方便大家看回放学习，整理出时间轴和知识点分布范围，结合鱼皮直播笔记食用：

第一天：如何做好项目的负责人

时间轴和知识点

00:00:00~00:30:20 国庆训练营介绍(看回放的同学可以直接跳过)

00:30:21~00:32:00 搞项目前要考虑哪些事情？

1. 要做什么项目
2. 怎么去招人
3. 怎么去权衡成本

00:30:21~00:45:30 立项：项目信息文档+立项时要思考的一些问题：

1. 为什么想做？
2. 项目能解决什么问题？有什么实际意义？
3. 项目的核心亮点在哪里？
4. 项目名称（中英文名、域名）

00:45:31~00:56:59 调研的重要性

1. 市场上目前有没有同类的项目？有的话其他网站和你的网站有多相似？
2. 你的网站相对于已有的网站有哪些优缺点？网站有哪些缺点，可以改进的地方？
3. 竞品分析很重要(至少3个竞品)
4. 完善好项目信息文档

00:57:00~01:07:58 需求分析

1. 需求信息表
2. 思考功能点(越细越好)
3. 需求优先级 (p0->p3) p0核心，到p3优先级递减(p1最好有、p2可以有、p3可有可无，有更好)
4. 需求进度
5. 需求管理工具，比如tapd(企业用)，表格(简洁清晰，小团队用)

01:07:59~01:33:01 组队

1. 不要养成总想抱大腿的习惯，要有一些基础的技术
2. 加入团队，描述自己的优势(想自己能给别人带来什么)
3. (队长)招人：
4. 找能力和技术匹配的
5. 要知道自己缺什么，不要根据简历招人，要控制人数
6. 清晰列举需求，文档很重要
7. 队长要带领队员确认：
8. 沟通协作方式（交流群、腾讯会议等）
9. 团队文档沉淀方式（语雀等）
10. 代码协作方式(Git、GitHub等)
11. 确认分工和对接方式
12. 建立好知识库，并给成员开设对应权限

01:33:01~01:49:55(结束) 提交国庆项目表单以及接下来的组队、计划等(看回放的同学不用看)

第二天：如何做好架构师

时间轴和知识点

00:00:00~00:06:53组队安排(看回放的同学直接跳过)

00:06:54~00:25:20 项目点评(看回放的同学直接跳过)

00:25:21~00:26:50 提出问题：如何做好架构师？

1. 架构师的定义
2. 技术负责人要做好哪些事情
3. 技术选型
4. 资源准备
5. 系统设计
6. 开发规范
7. 需求排期

00:26:51~00:30:10 00:34:11~00:56:45 如何做好技术选型？

技术选型两步走

1. 1、选
2. 系统开发
3. 前端、后端、上线的方式
4. 工具链
5. 开发、测试、上线工具
6. 技术选型原则：
7. 看人：团队对哪个技术最熟？有没有一个技术大佬
8. 看需求：
9. 项目的量级？大项目考虑扩展性(百万并发、消息队列、分库分表)，小项目尽量简单
10. 项目的功能？
11. 尽量用热门技术
12. 技术选型渠道
13. 搜解决方案：掘金、GitHub、openbase（前端）
14. 百度开发者搜索
15. 星球内鱼皮对系统设计的回答
16. 第三方平台（直播、短信、视频点播、第三方存储、OCR文字识别等）
17. 数据库选型
18. 思考数据量级
19. 思考数据的应用场景(数据间联系等)
20. 2、用
21. 能在技术选型阶段确认的技术尽量提前确认，怎么确定技术可以用呢？
22. 看文档确认版本号
23. 先跑起来一个demo，跑起来没问题再确认技术选型

00:56:46~01:15:10 资源准备

资源包括：服务器、数据库、第三方服务（短信发送）、开发软件等

开发最省钱的方案：

1. 服务器指标
2. 带宽、内存、服务器CPU、硬盘
3. 带宽计算：计算每秒访问的总资源大小（人数单位资源大小(比如打开一次网页的带宽消耗)） x 2
4. 内存估算：本地开发时查看进程占用，或者在linux部署运行查看(top命令)
5. 服务器CPU：核心数
6. 硬盘大小、云数据库
7. 团队资源文档/表

01:15:11~01:48:30 系统设计

只用语言、图描述系统，不写代码

系统设计：

1. 功能模块图
2. 分为哪些功能模块，功能模块图(类似流程图或者思维导图)
3. 从整体到局部，从大到小，比如（用户前台，管理后台）-》（XX，XX。。）、（XX，XX。。）
4. 功能间管理不大的可用思维导图
5. 技术架构图
6. 更加清晰地展示项目用到了哪些技术，便于后期扩展和改造，起到对项目宏观地指导意义
7. 库表设计(关键)
8. 对着需求表来
9. 划分哪些库-每个项目一个库
10. 划分哪些表-每个大的功能一个表
11. 确定每个表有哪些字段
12. 养成存储建表语句的习惯
13. 表之间的关联关系（通过字段约定式关联）
14. 反三范式
15. 设计很重要，前期要确定字段，后期避免上线库加字段(可能会锁表，查询卡死)
16. 必有的四件套字段
17. id(int)、create_time(current_timestamp)、update_time(current_timestamp 并且加 on update current_timestamp)、isDelete（软删除，逻辑删除）
18. 将设计清晰地记录下来
19. 每个功能的实现逻辑
20. 每个需求详细设计
21. 结构怎么设计
22. 流程越详细越好

01:48:31~02:08:23 开发规范(非常非常重要)

1. 编码规范很重要，架构师维持编码规范的几种方式
2. 人为约定(Alibaba Java开发手册等等)
3. 工具：插件 后端idea的alibaba java coding guide 、checkstyle、前端的Eslint等
4. 提交规范(隐私保护)
5. 同一的提交记录，比如关联需求文档
6. 忽略某些文件的提交，保护隐私，可用使用.gitignore

02:08:24~02:12:15 需求排期

1. 先做需求评估和设计
2. 排期稳一点，比预期时间多一些
3. 预留时间改 bug
4. 排期前预估和提出风险

02:12:15~02:16:59 组队安排+回答问题(看回放的同学跳过)

第三天：前后端协作，如何做好开发第一步

时间轴和知识点

00:00:00~00:02:09 介绍今天的主题(看回放的同学直接跳过)

00:02:09~00:04:21 总结和回答前两天的问题(看回放的同学直接跳过)

00:04:22~00:09:45 怎么做好前后端协作？

1. 接口文档
2. 大家一起参加需求评审，都知道要做什么事情
3. 前端和后端分别考虑怎么实现这个需求
4. 前端找后端要哪些接口？
5. 后端数据库表怎么设计？提供给前端哪些接口？
6. 本质上前后端对接依赖于接口文档
7. 前后端对齐，确认了字段信息，接口信息，前后端并行开发
8. 后端独立写接口
9. 前端mock数据或者写死数据

00:09:45~00:15:14 点评大家的项目(看回放的同学直接跳过)

00:15:15~00:46:56 如何做好开发第一步

拿到新项目，搭建好demo之后，第一步要做哪些：

1. 开发第一步：先把增删改查做好
2. 字段规范以团队内部约定为准

以寻爱项目为例，讲解项目结构

1. 简单逻辑可以按需放到controller层中，稍复杂的业务逻辑一定写到service层中(controller写接口，service写业务逻辑)

00:46:56~00:59:55 根据数据库设计如何快速开发增删改查

1. mybatis-x插件生成代码，逻辑删除
2. 创建 controller，生成增删改查接口
3. 创建请求类DTO，方便前端
4. 最好是编写单元测试

00:59:56~01:04:44 接口设计规范

1. 自己定义开发规范
2. 遵循业内的开发标准
3. RESTful接口设计规范
4. OpenAPI

01:04:45~01:27:37 前端部分讲解

1. 前端目录结构
2. 前端增删改查步骤讲解
3. 前端开发经验分享

01:27:38~01:28:50(结束) 任务分配(看回放的同学直接跳过)

第四天：如何聪明地写代码

时间轴和知识点

00:00:00~00:03:10 介绍本次直播内容

1. 原则：先做设计，再写代码
2. 寻爱网项目功能具体设计+讲解
3. 从设计到开发一个新的功能

00:03:11~00:52:15 寻爱网项目功能(点赞功能)具体设计+讲解

后端部分到00:48:29，之后是前端部分到00:52:15

1. 需求分析：功能的一些需求上的限制，比如每个用户只能点赞一次等
2. 方案设计：为什么要写：
3. 便于开发
4. 自己总结
5. 明确依赖
6. 更好地沉淀，给他人给团队做参考
7. 流程设计要清晰、详细，后期实现和调试方便，提升开发效率
8. 方案设计：业务流程，描述越详细越好，以点赞功能为例
9. 基本流程
10. 输入：接收请求参数：用户id、帖子id等，分析参数：尽量让用户传递最少的、最安全的参数
11. 校验原则：”高性能校验原则“
12. 优先校验不需要查数据库的、操作第三方资源的
13. 参数校验
14. 业务无关的校验：判断请求参数是否为null、id是否>0
15. 业务相关的校验：帖子是否存在，帖子的状态是要能点赞的(比如必须审核通过)
16. 权限校验
17. 判断用户是否登录：获取当前用户信息
18. 执行点赞操作
19. 单独点赞表
20. 1、用户是否已点赞：根据userId和postId查询点赞表，如果存在表示已点赞，否则未点赞
21. 2、如果已点赞，执行【取消点赞】操作
22. 从点赞表删除数据
23. 帖子表点赞数量-1
24. 两个操作要用事务（可以用事务注解），下同
25. 3、如果未点赞，执行【点赞】操作
26. 点赞表增加数据
27. 帖子表点赞数量+1
28. 返回一个能区分是点赞成功还是取消点赞成功的值，比如返回1、-1表示点赞成功、失败
29. 除了基本流程，还要考虑
30. 安全性
31. 权限
32. 幂等性
33. 用户不能重复点赞/取消点赞，加锁保证幂等性(注意锁力度，给用户id加锁，注意加锁要是同一个对象，比如String.valueOf(xxx).intern())
34. 性能
35. Redis实现点赞-》提升接口性能，减少响应时长
36. 存储
37. 硬删除等
38. 前端要做什么
39. 请求后端接口
40. 根据后端返回数据改变图标和帖子点赞数

00:52:15~00:54:30 测试根据什么测试？

1. 测试左移：在需求分析阶段考虑要做哪些测试。
2. 自动化测试

00:54:31~00:57:10 回答问题

1. 加锁会影响性能，尽量减小锁的粒度
2. 为什么要做详细地设计，特别是详细和流程？在设计方案找出问题成本是最低的，理清逻辑很重要

00:57:14~01:34:38(结束) 从设计到开发一个新的功能

切换 banner

1. 需求分析
2. 管理员在管理后台可以切换首页的 banner 图
3. 切换方式
4. 本地上传文件
5. 上传图片地址
6. 在线裁切
7. 程序员关注：怎么实现方便
8. 产品关注：用户怎么用方便
9. 选用那种方式根据情况具体分析
10. 没有最好的实现，只有最合适的。要灵活。
11. 系统设计(以上传图片地址的实现方式为例)
12. 图片的地址如何存储
13. 存配置中心里
14. 存数据库表里
15. 本地文件/内存（不推荐）
16. 库表设计
17. 四件套
18. 根据具体情况设计
19. 避免上线对数据库的改动
20. 表可以思考通用
21. 尽量保证扩展性
22. 跟着需求走，灵活一些
23. 实现
24. 后端提供给管理员的接口
25. 前端提供页面

理性分析，不要到代码实现阶段再改来改去的

第五天：如何给项目画龙点睛

时间轴和知识点

00:00:00~00:05:00 回顾前四天的直播内容

00:05:01~00:08:22 今天直播内容介绍

00:08:23开始 如何给项目画龙点睛

1、两个收获：(00:08:23~00:10:55)

1. 打开思路，自己做项目时可以想到这些优化点
2. 写简历时多一些亮点

2、如何优化项目(00:11:23)：

1. 新增功能(00:12:27~00:15:28)
2. 把现有功能做的更好，比如增强用户体验
3. 尽量避免无用的功能堆砌，尤其是重复的增删改查
4. 从一些维度(00:15:29~)
5. 这块可以对照星球鱼皮《如何优化项目文档》学习
6. 性能优化(00:17:18)
7. 前端(00:17:30~00:33:28)
8. 缓存（浏览器缓存）
9. 减少文件体积（压缩、减少代码、减少依赖等）
10. 按需引入、按需加载
11. 懒加载
12. CDN加速(减少文件的传输时间) 如果服务器是小水管效果显著
13. 升级传输协议 http1.1->http2
14. 代码层面：减少无用的请求，减少无用的状态变更、渲染
15. 前端请求合并
16. 后端(00:33:29~00:55:34)
17. 缓存（多级缓存）要注意数据一致性问题
18. 查询合并（多条数据库查询合并为一条，减少重复操作）
19. 并发编程（重要）
20. 异步，不影响主流程的操作可以开线程、消息队列处理
21. 并发，多线程处理
22. 池化，线程池、连接池
23. 限流 保障服务的稳定性
24. 降级（有损服务）
25. 数据压缩
26. 返回给前端
27. 存储前做压缩
28. 成本（00:55:35~01:09:55）
29. 成本在企业中非常重要
30. 成本优化方式
31. 分析自己用了哪些资源
32. 降低CPU利用 e.q.降低定时任务频率
33. 节约内存：GC、调优，及时释放、分批处理、用占用空间少的数据结构、内存分析工具等
34. 节约磁盘：低频存储、人工分析、定时删除、淘汰策略、数据压缩等
35. 节约带宽：连接复用、本地查询、数据压缩等
36. 可用性(01:09:56~01:14:58)
37. 集群、主从、自动故障恢复(Redis哨兵)、监控告警、容灾（异地机房）
38. 可靠性(01:14:59~01:16:05)
39. 尽可能让系统提供可靠服务
40. 集群、主备、异常处理、降级、容灾等
41. 稳定性(01:16:04~01:23:39)
42. 接口稳定性：响应时长、操作处理时长稳定，成功率高，响应结果正常
43. 保证服务节点状态正常、性能相等等(看鱼皮文章详解 )
44. 怎么排除稳定性？
45. 链路追踪(微服务)
46. 打日志
47. 容错性(01:23:40~01:24:37)
48. 分区容错性
49. 集群、反向代理、故障转移
50. 健壮性(01:24:38~01:27:20)
51. 异常处理（在代码层面上多考虑）
52. 进程监控
53. 全局异常处理器
54. 系统复杂度(01:27:21~01:30:22)
55. 软件开发原则、设计模式、架构设计、开发规范、工作流
56. 可维护性(01:30:23~01:33:03)
57. 软件开发原则、设计模式、架构设计、开发规范、工作流、抽象复用：模块化组件化，方便维护
58. 可扩展性(01:33:04~01:38:09)
59. 系统能更好地应对之后的业务增长
60. 开闭原则*
61. 设计模式、架构、集群、分库分表、技术选型
62. 可观测性(01:38:10~01:44:49)
63. 能够清晰了解系统/服务的运行状态
64. 埋点上报(埋点+定时任务上报)、ELK日志、监控告警、可视化分析等 实现方式
65. 前后端都有可观测性的要求
66. 可观测性可以作为亮点写到简历上
67. 可伸缩性(01:44:50~01:45:49)
68. 动态扩缩容，应对流量高峰，节约成本
69. K8S、Docker、云原生
70. 用户体验(01:45:50~01:48:37)
71. 前端用户体验
72. 响应速度、骨架屏、设备适配、浏览器兼容性等
73. 满意度调研
74. 安全性(01:48:38~01:53:00)
75. 保证数据库、服务、机器安全等
76. 防爬虫、限流、防火墙等

01:53:01~01:55:31(结束) 今日任务(看回放的同学不用看)

思路很重要

第六天：如何绽放项目的价值

时间轴和知识点

00:00:00~00:03:06 回顾前几天所讲内容

00:03:07~00:04:21 介绍今日所讲内容

00:04:22~ 项目上线

1. 准备资源：域名、服务器
2. 区分环境
3. 新的服务器可以装宝塔面板，可以方便管理服务器，快速上线项目
4. 前端(00:04:22~00:28:10)
5. 打包构建-》把网页文件放到服务器上=》用Nginx等web服务器提供访问能力
6. 用了框架-》参考官方文档学习部署
7. 区分多环境，即前端请求后端的环境(编译/打包阶段)
8. 开发环境(localhost:xxx)、测试接口
9. 上线环境：前端请求的是正式地址
10. 后端(00:28:11~00:42:50)
11. 对于Java项目：编译构建-》把jar包放到服务器上
12. 区分多环境（启动阶段）
13. 开发环境、测试环境、上线环境
14. 注意跨域问题

00:43:28~01:06:17 如何做好开源(提升项目影响力)

1. README文档
2. 证明项目是认证在做，正经开源
3. 向别人介绍项目，吸引关注和star
4. 介绍怎么参与项目，吸引别人参与
5. 便于自己梳理业务逻辑
6. 写简历时，可以给面试官看的
7. 关键点
8. 项目介绍
9. 简洁清晰的话语描述项目
10. 最好能提供线上可访问的地址或者介绍视频
11. 项目功能
12. 解决了什么问题
13. 有什么优势（写到最前面）
14. 技术栈
15. 快速启动
16. 启动项目的流程和命令
17. 使用说明
18. 方便用户使用
19. 架构设计
20. 代码讲解
21. 目录结构
22. 做的好的点，一些小细节等
23. 具体业务流程
24. 功能模块图
25. 技巧：
26. 多列举些截图
27. 把最重要的、最想让别人看的的前置
28. 贡献指南
29. 如何让别人参与这个项目
30. 多参考知名项目的README
31. 代码脱敏
32. 数据库、服务器地址等敏感信息
33. .gitignore
34. 开源协议
35. 注意不同开源协议的区别
36. 开源推广
37. 知识点同下面的推广

01:06:18~01:16:36 如何做好推广

1. 清晰介绍、网址、相应的标签-》方便别人搜到
2. 取好记的项目名词
3. README文档写的好一些
4. 前提：作品用心、质量高
5. 友链
6. SEO(重要)搜索引擎优化
7. 内容标签清晰，多出现一些关键字
8. 写文章、做视频推广=》利用其他平台的SEO。利用其他渠道，比如发布视频，在合适的时候推广项目等
9. github漫游指南
10. 怎么做好github开源项目

01:16:36~01:21:17(结束) 总结(看回放的同学可以不看~)