记一个命运多舛的项目总结

概况

(去年)上周末开始做一个新的需求,大概三周左右加班加点做完。上次还问同事提交仓库的图标什么时候颜色加深(和提交的次数有关系),这次是真知道了(笑cry)。
刚开始接到需求的时候是懵逼的,不知道这是要干什么,也没给咱开会说太细。设计稿也暂时还么有,只有个原型图。全程还得自己一个人搞,大家看了都说比较难搞(求此时我的心理阴影)。

实际回顾

有设计图才能及时知晓最新动态,问清情况后开始搭台唱戏。还好之前有自用的一套样式,或者总结有类似的,这样写起来稍微快了那么一点点。

关于技术选型

一开始不太清楚是要做什么,还说要公用部分代码。不管是用什么框架或者库,反正 样式是少不了要写的,可以先写样式,先走两步再说。
后面还有排序,这个自己没做过,先去GitHub上面搜索有没有相关的第三方库可以使用,看看 demo,至少做到心里有数。

系统与部分,重要与紧急

因为这次涉及到的端和人太多,所以得在关键节点保证关键流程可以打通。因为我的页面是嵌套在后台系统里面的,而且将来移动端页面也会用到我的组件,并且,androidios、企业微信等各端都需要链接跳转。下面这个图,至少在N年前就看过了,不过,我从来没有实践过,这次自己在规划事情的时候,突然想到了这个图。

哪些功能要先做?哪些可以先放一放?哪些必须提前做?哪些是在别的功能完成之后才能开始做的?时间比较紧急的情况下,如何保证开发进度?

举个例子:数据结构是要提前确定的,这是整个过程中都在使用的一套数据,基本上就是在这上面增删改查。
列表搜索,这个功能属于锦上添花或者重要程度不是太高的,我差不多是放到了最后才做的,这个在产品经理在开会的时候也向对方说明了。
排序:这个功能得在基本的模块可以增删改查之后才能实现,不过保险起见,还是先找了好几个第三方库的 demo 去看,先收藏文件夹中(为此项目专门建立的收藏夹)

理想和现实

因为写具体代码的并不是开会的人,信息这么一层层传递下去,出差错是免不了的。于是,待我差不过开始调接口的时候发现,除了老接口,新接口基本上和实际情况不一样,再往后,后端理解的和前端的实际情况也不一样。大概是最近一段以来,我说话最多的一天。最后的结果是,后端重新写接口。尽管后端有验证接口正确与否,但是这也仅限于后端。后端接口开发完毕,最重要的是要保证这些接口可行,这时候一些细枝末节就先不用考虑了。

数学里面讲提取公因数,因为要做的几个模块大致差不多,这时候先做把一个做成,其他的即使还没写,写起来也快了。不过,时间规划上并不是按照这样来写的,于是我差不多是每个模块并行推进。排期显得太理想化了。还有不少东西没有考虑到,后期及时加进去了。产品还在更改着时间和具体的功能,但是对于我来说,朝三暮四和朝四暮三是没有区别的,工作量并没有减少,时间还是那么点。

现用现查

部分网页如何转为图片并上传到七牛云?antd 里面的表格该如何用?这些以前虽然留意过,但是并没有写过,这次基本上是现用现查,还好,虽有惊险,但是基本上解决了。

及时总结

包括现在。不浪费每一段经历

不足之处

前后端有一些数据字段没有统一。这个看后期改的时候顺带一块改了。
有些功能需要提前再思考一下,脑子里面先运行一下大致的流程。
心情可以不好,但是不能影响到工作。
掌握常用的技术,平时多流汗,战时不流血.

后期改动

字段保持一致。
改之前留下的。闲的时候和忙的时候
类命名要再多注意下。

原文地址:https://www.cnblogs.com/zxhycxq/p/13746256.html