1、把握需求。
例如切月份,实际上是一个代价特别大的功能,因为若要对以往的月份评分,就要保留以往月份一整套的数据。当时并没有考虑到这点就开始做了,最后才发现根本做不了。这是最大的一个失误。
后来发现做不了之后,就想着把切月份功能做成一个展示历史数据的功能。但是之后发现也没必要这样做,因为用户是不需要查这些历史记录的。虽然有权知道,但是并不是一个必须的功能。而且也不该在这里做,应该在一个专门展示历史记录的地方做。并且历史记录有历史记录的逻辑,我依据谁给谁评得分得出的下属历史记录虽然行得通,但是依据这个找到主创团队,然后关联项目而得出历史记录就很怪异了。
这两个需求的变更耗费了几天的时间才改好,尤其是第一个,涉及面广,导致代码复杂度的无谓增加。
2、把握进度。
多了解一下其他人的进度情况,及时反馈。
3、还是把握需求
OA是我家,增加新功能一定要谨慎,一定要详细考虑这个功能带来的影响。先审核需求,设计方案,最后才开始编码。
其次,
以简洁为主,没必要展示的信息就不展示。把握主干与核心。
4、entity命名
entity的命名关系到整个模块所有对象的命名,所以一定要命名好。有时,由于数据库表的命名按照规范是要以模块打头的,例如score_dept_own,这时entity可以适当的去掉模块名,变成DeptScore,这样命名会清晰很多。
5、类属性命名
像积分系统中,分数的种类太多,可用积分、已分配积分、已用积分、变来变去,很难命名。先命名了useScore
6、缓存 PK SQL
SQL:适合复杂逻辑,需要各种运算的系统。
缓存:适合只简单筛选,逻辑不复杂的系统。