记项目管理大作业Web项目Mandrian的全流程[其一] 整体分析: 功能划分, 组织结构

Mandrian是个图书管理系统, 具体需求老师给出
这个项目的目的主要是管理过程和高层设计的学习和实践
11人小组, 路人局

成员调查

这里由于很多人我都不认识, 所以我提前发了一个能力调查表, 调查范围是代码,管理和设计能力.

结论(如果前后分离):

居然想去前端的人多, 前后人数比接近2:1, 如果不是胡选的话, 是个优势
后端主力语言应当是java
大家都不用git么..., 那么代码版本如何控制?如何多人协作开发?难道要用qq邮件合并代码么-_-

分析和设计流程

以下都是本人的经验, 主要是貌似没有一种固定的分析和设计方法? 还是说我又忘了?

分析: 对需求具体功能划分, 组织结构
设计: db设计, api设计, 开发模块设计, 架构设计, 框架选择

功能划分

目的见上图, 是为了下面的工作做铺垫
需要注意的是:

此处第一次划分只能大组长做, 或者PO们讨论, 因为组织结构还没定, 没有小组长可以分工
第一次划分最大的贡献是定组织结构
第二次划分最大的目的是定下开发的具体任务
开发过程中很可能发现功能划分不正确, 没办法, 我们是增量模型, 不像瀑布模型那样时间长且特别严谨
事实上此处有些像WBS, 这是我之后才接触的, 现在并不清楚WBS是干嘛的

组织结构

为什么设计成这样? 为什么不用按老师讲的三种功能分?

首先按功能分的话, 有两个缺点
- 编码效率低
  同时做某几个功能的话, 如果成员不了解多人合作, 很可能代码合并冲突
  而且前后不分的话, 很可能存在前后端来回改的情况, 怕是脑子转换不来
- 成员学习成本高
  不了解框架或者语言的话, 一边后端一边前端, 谁吃得消啊
如果按前后分离的路子, 我认为一点问题没有
但是相较于按功能划分的话, 这个分工比较难把握文档写作等一系列课程上的事情, 也算是很无聊的原因吧
主功能副前后的话, 会有几个很严重的问题
- 相似功能的合并(比如login的api), 合并之后无论谁要实现这个功能, 都会出现组间的前后端依赖, 其实问题不大, 但这样的话公共部分得我写么?(吐血
- api的设计, 像reader组和librarian组, 都有对reader的crud, 到底是谁写ReaderController? 我觉得要分离成SelfReaderController, LibReaderController, 这不是自找麻烦么?
所以我们很可能是三个后端组合并, 分开写功能(ReaderController, AdminController等, 而非每个人按照功能个写个的)
(注意我们的前后端在开发时是相当分离的, 这个等下再说, 关键词: 前端渲染, ＭockServer

db设计

关键词: 权限五张表(或许三张?)
todo: 日志如何解决? 统计信息如何?

api设计

RESTful API没跑了
很可能首先小组长定义, 出文档, 前后共用
后端先开发api, 前端首先模拟api(mock server), 然后写页面, 高度并行

模块划分

基于上述讨论, 脑子里还是老一套
mandrian-common: 数据访问, 工具类, 配置, 权限aop, 日志aop, 安全aop
mandrian-back: 主要是api (或许叫做mandrian-api?)
mandrian-front: 提供页面访问的url, 还有具体页面
待讨论吧

架构设计

注意到了邮件, 日志还有统计, 可能又要mq了?
待续

框架选择

前: bootstrap, jquery, template.js, (mock server)
后: spring boot, spring mvc, (spring data jpa+mybatis), thymeleaf(几乎静态的页面)
待讨论

吐槽

说起来为什么我不认识大家, 但是还是当了组长?
原因是我们猜拳决定的组长, 这本来就够扯淡了, 但居然我还能输了10个人???