一個“奇怪”的Web項目

首先簡單的描述一下這個項目，一個Web考勤系統，數據庫SQLServer，8個頁面。其中2個頁面在IPad中使用，其他6個PC使用。

規定無論是IPad和PC中，使用的客戶端是WebKit內核的Safari瀏覽器。

現在這個項目，只做了三個頁面，因爲設計在不停的更改，所以代碼屬於在一直修改中。

既然提到了是個奇怪的項目，就給大家看看奇怪的地方吧。

奇怪1：項目體制

這個項目由一個項目Leader帶領3個設計人員及1個半代碼人員，半個是我，我只做了Ipad的一個畫面就撤出了這個項目組。Leader主要負責業務和數據庫表設計，3個設計人員負責

業務邏輯，代碼人員當然負責代碼了。

體制奇怪處1：4個設計對應一個開發人員，想累死寫代碼的人吧。

體制奇怪處2：3個設計人員是剛進公司的新人，無開發和設計經驗，當時討論畫面時，連Textbox是什麼都不知道。

奇怪2：流程

先不說新人做設計文檔能做成什麼樣子，單說Leader帶這些設計人員，只是對Leader對業務的口頭描述拷貝成設計文檔。描述有的，可能丟了，沒有的，更直接沒有。

在後面的代碼過程中，基本上由代碼人員去找Leader確定設計，然後由設計人員修改。

奇怪3：業務

本身這個項目沒有用戶基礎表的錄入畫面，用戶的基礎信息由一個batch從Excel中導入。導入時將用戶的5年考勤記錄，作爲空信息插入到數據庫表中。

開始我們一直奇怪的是，爲什麼設計裏面對於考勤打卡這個手續，爲什麼只有Update，而沒有Insert。後來在詢問Leader的時候才知道因爲batch都做了Insert處理了。

奇怪4：數據庫設計

在設計中，對於出勤時間的計算，跨天的當作前一天的數據計算，

數據庫表設計爲

出勤表：

出勤1~退勤3爲number(4,0) ,其他爲Varchar類型

第二行數據是跨天數據

打卡畫面獲取的是服務器時間，奇怪的是，我怎麼能在第二天打卡點退勤按鈕的時候，將數據記錄在前一天裏面，而且不是前2天，前三天裏面。

爲此還跟Leader討論的半天，終於Leader無語了，在每個出退勤的字段後都加上了一個輔助計算字段。格式是YYYY/MM/DD HH:mm。還是不放棄的保留了原先的出退勤字段。

此上改動爲做到第三本畫面時，口頭瞭解到出退勤時間計算方式時，找Leader確認計算方法時才知道。設計書上就沒有說過，那個汗啊。

幸虧是個小項目，大項目不就徹底崩潰了。

奇怪的人（日本人）帶奇怪的項目，奇怪的項目出現奇怪的設計，奇怪的設計出現奇怪的代碼，最後不出現BUG，就更奇怪了。