我的工作生涯中关于项目的需求和功能分析（论坛项目）
先说明，这个帖子只讲需求分析和实现，不是具体到用哪些语言，哪些具体技术，内容也比较简单，是面向比初学者更高一个层次的，也就是初入职场的菜鸟的，因为我也是从菜鸟阶段过来的，很希望有一些项目分析的博客，因为刚毕业的时候，通常很难进入到大公司，这里指的是985/211之外的学校，小公司因为人少，所以各种事情都会做一点，那么在小公司需要的可能不是技术，而是和人沟通的能力以及项目的分析能力，技术能力反而不是重点。
我稍微说一下，小公司的老板很可能只需要你把功能做出来就行了，你用什么技术有什么优化，都不是重点，但我要说一句，能使用新技术就使用新技术，能使用新版本就使用新版本，能用高层次的语言或技术就尽量使用，因为高级语言封装的功能，框架远比其他语言来的简单和快速，新人刚进入公司，首先要做的就是完成项目的能力，其他都不是重点，然后为什么要使用新技术和新版本，我是这么理解的，比如java 6 和 java 8 ，当然是用 java 8，新版本有新的api，lambda和新的时间函数就值回票价了，更不用说新版本bug修复和性能提升，反过来想想，如果没有新功能或者bug修复，为什么要更新版本呢，当然如果公司要求，那就没办法了，总之就是假如你自己能拿定这些东西，就尽量用新版本，而且新版本碰到问题，也能更加熟练地使用谷歌，github 上用issue报告bug's等等，能提升自己的能力。
这里只是我个人的见解，不代表其他人的意见。
因为技术分析的博客已经够多的了，但是我看了很久都没有看到过项目分析，或者说有一些项目分析，都是具体到技术，但是这些技术，要么听都听不懂，要么很高深一时半会又掌握不了，那就很尴尬了。
欢迎提出建议。
昨天离职，闲着无聊就写一下关于之前项目的需求分析和功能解析。
历数这将近2年，呆的2家公司做过的项目，花费时间最多的就是之前的一个论坛项目。
这个论坛项目真的是一波三折，之前我们公司和另一家公司接收做了快2年，还使用网上购买的模板，2年过去之后居然还没完成，然后甲方就把乙方和我之前的公司告了，也真是可以的。
然后因为各种原因，项目轮到我之前的公司单独做了，然后项目就堆到了我的头上，我作为我们公司唯一一个后端程序员兼测试兼运维兼实施，压力山大，毕竟小公司。
之后就是需求分析。
首先作为一个论坛，肯定是先借鉴一下康盛的论坛系统，发现有将近300多个表，对于急于上线的来说，肯定是来不及抄的，然后甲方又不希望用康盛的论坛，最后就使用c#+sql server + iis 的平台。
然后我们出了一系列论坛的功能和甲方讨论，把能阉割的地方全部阉割，最后留下了如下若干个部分：
- 论坛首页要包含重点板块，板块推荐，帖子推荐，翻图，热门帖子（瀑布流）以及顶部的用户状态栏。
- 论坛版块部分，有一级板块和二级板块，一级板块里有若干个二级板块，同时一级板块无法进入，只作为标题使用。
- 板块详情 头部的背景要可替换，头部要显示名称，帖子数，回复数，板块描述。
- 根据最后回复，最后发帖 的时间筛选帖子。
- 帖子列表显示用户头像，帖子名，最后回帖时间，最后回帖人，发布人，发布时间，查看人数，回复人数以及签到功能。
- 发布帖子，目前有普通帖，提问帖，投票帖，视频帖，新技术帖。视频帖和新技术帖目前只允许运营人员发布。
- 自动获取帖子内第一张图片作为热门或推荐的图片。
- 帖子有点赞和收藏。
- 引用其他人的回复。
- 举报帖子。
- 用户中心修改用户基本资料和头像，退出登录。
- 查看收藏的帖子，发布的帖子，发布的回复，历史浏览，积分商城和意见反馈。
- 黑名单，关键字屏蔽，xss防御。
- 版主功能
- 手机html5部分（基本和上面整理的部分一样，页面展示不同）。
- 场景秀接口部分（只有手机端有）。
- 后台管理部分。
- 预留功能（站内信,App接口等）
我花了一点时间，从项目任务书中细化和整理出了上面的这些功能。
之后就是程序分析，因为是小网站，所以就超简单的方向来分析。
使用 rwby RBAC 来创建用户 角色权限控制，来实现积分功能，页面访问权限，同时使用OAuth 来增加 App登录授权功能（预留功能）。
首页部分就是根据条件从数据库中查询并显示到页面中，这部分没什么好讲的，无非就是增加缓存以优化查询速度，不过我记得之后可能会上数据分析以智能显示首页内容，那么这里使用内存作为缓存可能就不合适了。
同时表内，
论坛板块，首先是一级板块和二级版块，本来是计划做在一张表，逻辑上使用树状态结构，但是这么做的话，sql 比较难写，而且可能导致嵌套板块或者一个板块又是父板块又是子板块，又因为 不要过早优化 和 越简单越好的原则，做成了2张表，就是一级板块表和二级版块表，
一级板块中只有板块名称和板块图片，一级板块作为二级版块的外键，形成一个一对多关系，一个一级板块中有若干个二级版块，同时这里有排序功能，也就是在表中增加一个字段，通常是int类型，通过这个字段来排序。
显示在页面上的字段也可以使用缓存也可以直接查询。
筛选功能，一般是在 帖子和回复加入创建时间，根据创建时间排序，帖子发布时间排序是最简单的，order by createTime 就可以了，根据最后回复时间，那就需要查询出对应帖子id的回复，根据回复的最后时间排序，同时要获取最后回复人的用户名。
签到功能，这里有2种实现方法，1是判断时间，也就是当前时间减去上次签到时间是否大于24小时，2是判断今天天数减去上次签到天数是否大于1天，这里按照逻辑上来说应该使用第二种方式，这样不管第一天在任何时候签到，都可以在第二天0点之后又立刻签到，但是因为那时候并没有想到第二种方法，或者说因为时间关系，这部分也没有特别指定，又不是什么重要的功能，所以项目中我是用了第一种，这里可以优化一下。
发布帖子，这里可是重头戏，论坛的主要功能就是在这里，首先帖子分为普通帖，提问帖，投票帖，视频帖和新技术帖，甲方认为新技术是单独的一个功能，但是以我的经验来说，这部分除了不能回复之外，其他和帖子都没什么区别，那么就可以理解成不能回复的视频帖。
那么同理，视频帖也就是比普通帖子多了视频字段（视频表），投票贴比普通帖多了投票的字段（投票条件表），提问帖和普通帖没区别，新技术不能回复。这样的话，把帖子的基础部分抽离出来，然后当提交对应帖子的时候，根据上传的帖子类型获取对应的表单，再拼接成字段，同时前端校验和后端校验 。
这样就只需要一个帖子表和一些其他字段表，就组成了帖子内容。
这里我因为帖子的字段包含的内容可能有点多，所以帖子其他部分和帖子内容是分离的，这部分可能有问题，不建议新手这么弄，因为我这么做导致了这一部分的复杂性更高了。
帖子列表使用order By和 then By 来显示。（c# entity framework 对应的lambda查询语句，先order by 查询置顶帖子，之后then by 查询普通的帖子，并 skip 和 take 传入分页参数。）
（对应到 mysql 应该就是 order by 传入2个参数就行 例如 ： select * from table order by isTop,id desc，table 是表名，isTop 是bool字段，id是主键）
还有另一种做法，就是固定哪些帖子显示在各个页数的前几条，先查询出置顶的部分，再根据Id排序的结果，使用 UNION ALL 连接2个结果，这样每个页面都有这几个查询出的置顶结果。
这里发布帖子和发表回复，有关键字检测，和xss防御，xss防御是转义js 和 css代码，这里因为富文本编辑器是从第三方的，所以只用正则在后端屏蔽了<script></script>标签和 <style></style>标签，因为是小网站，所以就这么简单防御一下菜鸟就可以了。
使用正则 获取帖子中第一张图。
点赞可以取消，同时又要确保用户只能点赞一次，那么就需要记录对应哪些用户点赞了哪些帖子以保证能够取消点赞和不允许重复点赞。
收藏和点赞同理，先查询用户是否已经收藏，如果没有则保存帖子编号，如果有则删除对应的记录。
积分商城，最重要的是用户如何获取积分，需要一个用户积分获取表和用户获取积分的记录表，在积分获取表中，可以根据对应action 添加获取积分规则，字段：间隔多少天可以获取一次积分，获取的积分数量，获取的间隔，多少天中允许获得几次积分，和控制器选择。
例如 用户签到，那么就是 间隔1天获取积分，获取的积分数量为1分，单位获取时间为1次，获取间隔为0秒，控制器为签到控制器。
又例如回帖积分奖励，那么就是间隔1天获取积分，获取的积分数量为1分，单位获取时间为19次，获取间隔为0秒，控制器为回帖的控制器。
，这里因为使用了角色权限控制，那么只要在对应的权限上增加拦截器，在拦截器中查询对应的action 是否和用户当前操作一致，如果一致则查询用户上次的记录，如果匹配条件，则给用户加上积分，如果其中任何一步未做，那么直接结束拦截器。
商品表则很简单，有商品兑换数量，已兑换数量，兑换商品属性，然后是兑换记录表，记录了每个用户兑换的记录，以防止记录出错，在程序里判断如果兑换数量小于已兑换数量，则允许被兑换，如果等于或大于则显示已兑换光了，这里显示兑换光了是一个运营的小技巧，显得奖品多和兑换人数多。
用户回复的引用功能，在我看来是分析功能的耗时大于实际操作的耗时，因为康盛的引用，是在回复中有一个引用的样式，同时在表中增加引用回复的编号，然后在对应引用回复的用户添加被引用回复了的记录。
在我看来，这部分实现起来，比较困难，并且耗时和对应表复杂度较高，那么我就向甲方介绍了这部分的问题，然后向他们推荐了百度贴吧的处理方法，这里我就不贴图了，百度贴吧的效果，就是在回复中再加一级，类似帖子下面有回复，那么就是回复下面有引用回复。
但是引用可以引用其他的引用回复，所以引用表设计就包含了被引用的回复id，回复id，回复内容和创建时间，分离了回复表和引用回复表，在我看来这一部分应该还是能够再优化的，但是一个人的能力有限，我也只能做到这里了。
既然分析出来这部分的问题，那么解决起来就很简单了，依旧和回复一样，排序通过主键或者创建时间，如果存在引用引用回复的编号则查询对应的名称并显示 。
版主功能依赖于RBAC框架，但是版主的页面还是要重新做，所以程序在初始化的时候定义了管理员，版主和普通用户三个角色， 同时初始化一个用户以允许进入后台。
版主不允许使用网站后台，所以版主是在板块页面下修改，版主也只能修改和删除某一个或一些板块中发布的帖子，甚至不能修改板块的描述。
这里因为项目是mvc的，所以是在拦截器中检测是否是版主，如果是则跳转到版主专用控制器，这个控制器返回能够修改帖子的页面。
然后是手机html部分，可以使用相同的控制器只需要判断对应用户是否是手机还是电脑端来返回对应的视图 ，但是还是有些内容是不相同的 ，所以我新建了其他的控制器，还是因为赶项目的原因，还有就是 都写在一起的话太臃肿了，项目管理起来不是很方便，代码复杂度也更高了。
手机因为操作和页面是和pc不同的，所以某些功能做了特殊的处理，比如 手机端的富文本编辑器 只有上传图片功能。
场景秀接口，这个就是很简单的一个提交表单的接口，返回成功或失败的结果。
后台管理部分，这部分其实也没什么好说的，大部分都是增删改查，同时因为只有工作人员才会使用，所以也不会特别优化什么内容，页面是bootstrap加上一系列的表单js框架，我是用的是整合模板。
最后就是预留的功能了，app接口 使用了rest风格, 例如 /api/forum/1/ 这样的，功能也是从项目中提取的，当然也是能直接使用项目中已经存在的接口，但还是不推荐这么做，项目管理起来太麻烦了。
最后站内信是因为初期没有规划，但是我也做了，不过没有开放，先简单说一下站内信功能，用户能够向另一个用户发送，也可以根据用户组（角色）发送，也可以群体发送。
那么就需要 信息表和查看记录表，用户发送信息表，在业务逻辑中判断发送类型，如果是发送给用户的，则当该用户上线时，查询记录表，如果不存在记录，则显示还有x条站内信未查看。
同理如果是群发用户组或者群发全体用户的，则当这些用户上线时，查询是否有查看记录，如果没有则依旧显示 还有x条站内信未查看，当时是这么想的，不过当站内信一旦多起来，则性能依旧是大问题。
总结：
现在的项目分析和功能分析，主要还是看老板和领导的意思，毕竟是做给客户（或老板）的，他们的需求才是最重要的，当然在有限的条件内还是需要自己定夺，另外最重要的就是 时间一定要充裕，有些老板说话跟放屁一样就一定要立下合同，如果是内部项目 那么一定要有邮件并一定要保存好，这只能说是我作为开发这将近2年的血的教训。
写给 程序员职场新人
只做了一点微小的工作，很惭愧。
