背景：公司給高校做專案，籤的緊，給了40天時間做，中間還有國情和中秋。基本天天加班，就歇息了5天，3天中秋回家（PS：回家後還忙著做省廳的資料庫設計和詳細文件說明），兩天國慶休息，做完後給省廳做demo演示。結束時間和高校一致，也就是40天兩個專案。時間上很趕，踩了許許多多的坑。做個總結吧

坑之一：資料庫設計部分，當天原型圖下來，第二天開始做，一天的時間設計資料庫，不少欄位沒有仔細溝通好，註釋也描述的不夠清楚。簡單的學年2017-2018，原先是按照2017來計算的，年月2018/09,2018-09,201809 什麼格式都有，數倉一個人推一種格式。以後註釋後面最好寫一個樣例，讓別人知道格式什麼樣子 坑之二：程式碼建包部分，同一模組下的專案最好放在一個包，讓一個人做。但是由於時間緊，不同模組需要花費的時間長短不一，安排了模組少的人幫助模組多的人寫幾個功能，結果不在一個包下。以後最好先建立好包，和他們溝通好每個模組應該在哪個包下面。

坑之三：程式碼規範部分，嚴格按照阿里規約來進行，前期沒有仔細檢查，後期把所有扔掉的一點點撿起來。嚴格按照規範來編碼把，這一塊沒什麼說的，以後記得檢查吧

坑之四：業務邏輯部分，這是一個大坑，安排下去後，只是說了功能，每個人按照自己理解的來做，總有點區別，近三年，按我的理解是今年，去年，前年。有些人寫的是資料庫時間按大小排序取前三位。這樣的話，假如只有2015年資料那最新年就不是2018，我們期望的是2018為0。詳細設計文件沒有做好，第一次寫詳細設計文件，只是記錄了每個位置對應的表，應該說清楚對應的資料怎麼獲取，時間太趕了。

坑之五：記錄，每一次的修改都應該留下記錄，頁面修改發一份最新的原型圖給我，說那個地方修改了，就按照他說的來，後面才發現其他地方他也改動了，應該每個原型圖對應的時間，每次修改的內容都要記錄下來。

坑之六：資料庫初始化語句，資料庫第一次設計好以後，當原型進行了修改，可能會增加，減少欄位或者表。我需要準備好每一版的SQL，以及從上一版升級到最新版的SQL，實際上只准備了最新版本的初始化SQL，現在需要忙著補齊

坑之七：許可權，資料庫設計好以後，會變動，後期整理的時候，新加表好查詢，但是如果表有修改欄位，那就麻煩了，應為壓根不知道修改了哪一個？需要一個個的對應。而且不僅僅軟體方面修改，數倉導資料的時候有時候會增加欄位和表。而你完全不知道，那表還有資料，你也不敢去刪。