工作的一些經驗和教訓

經驗：

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之類的方法，用盡量短的篇幅和時間搞定，即使表達效果較差。因為寫出來也很難了解，大機率是無用功。