工作的一些经验和教训

经验：

1. (未验证)，nihonjin喜欢看表格，尤其是带筛选功能的表格
2. excel成果物需要解释清楚，如果提交成果物对方看不懂，需要口头解释，那么成果物无意义
3. 个人粗心大意导致的miss会严重降低他人对自己评价，实际工作中不能说，万一出现的话需要准备其他符合逻辑的借口
4. 一定要确认清楚对方的需求。user共通时**安排了一个任务，说不懂的地方再讨论，先做一个模板让其看一下。我记录了再三强调的需求，但对需求的全貌不了解，以前的话应该会确认，但因为核心逻辑比较复杂，就把精力全放在逻辑上，结果成果物大幅度偏离了需求。在无关的地方花费了大量的时间。
5. (重要)记性太差，一切交代工作的发言，预计没有文字记录的情况下，尽量全部录音。
6. 某©同事帮我完成了某工作，但成果物有小瑕疵(自己做的话很可能出很多miss)，被问到时很自然的说不是自己做的(跟自己无关)。这是智商掉线，极度不好的行为。。
7. 写设计时，关键的业务逻辑(尤其是DB)需要尽早搞清楚，否则会留下巨大的隐患，将来花更多时间修改，包括但不限于：
   各种表是1对1/1对多/多对多的哪种关系
   inner/left/right/outer join的选择(一定要考虑清楚各种情况，尤其是差集的部分和合计数量时用哪张表的主键)
   通过某表的某字段(比如学习开始时间)是否为空进行判断时，需要同时处理db数据本来就是空和表连接后没有数据造成的空两种情况(可以考虑用该字段和该表主键一起判断)
   表a和表b进行连接，使用了表c的字段d，搞清楚是否需要连接表c
   写sql时一开始就考虑优化的问题，否则将来可能会改
   表a,b,c连接的字段可能多个表都有，一定要选对表。如a left b inner c的情况，本来b有没有数据不影响a和c的逻辑，但是如果用c.字段=b.字段，a和c相匹配的数据，会出现b为空时c也找不到的情况。
8. 写设计时其他要注意的
   考虑开发和测试的实现的难易度
   非常不适合写详细设计的逻辑，如本项目的勤务地树状排序，组织层级donwload和user检索共通的条件因子入力的处理，应该采取sample之类的方法，用尽量短的篇幅和时间搞定，即使表达效果较差。因为写出来也很难理解，大概率是无用功。