會議室預約系統從設計到開發和測試都是我自己完成的，這個過程中遇到不少問題，也有很多的收穫，在此分享一下。
1、在**設計階段一定要做好規劃。這是我這次體會最深的一點。因為，在專案前期，功能比較單一的時候，設計還能比較規範，會做一些記錄，到了後期，有其他任務在忙，導致時間比較緊張，就沒有認真的在做設計，導致後期**比較亂，功能疊加的時候容易出問題，後期**優化也花了一定的時間。如果認真做好設計，這些時間在一定程度上是可以減少的。
2、這個專案雖然比較小，但是通過這個專案，我對於原生js有了進一步的了解，並且對於前後端資料傳輸以及servlet有了更深的認識。為以後的學習和工作打下了基礎。
3、在單元測試的時候要盡可能的考慮全面，這種web應用更需要大量的測試。在每個功能開發完成後，我一開始就是簡單的測了幾遍，覺得差不多了，就往下進行。結果在功能疊加比較多之後，測出來乙個比較嚴重的bug：重新整理頁面後單元格多出一塊來。不得不從頭開始找原因，最後，發現是顯示資料的方法中每次迴圈都要獲取單元格的id，但是我獲取完了之後沒有重置，所以導致了這個問題。修改完之後，我認為如果在顯示資料方法完成後進行大量的測試，這個問題當時就能被發現，不至於到了快結束的時候還在改這種功能性的重大bug。還有乙個是查詢資料的時候，我一開始是用的會議室編號加時間作為約束條件進行的查詢，測了幾次發現沒錯之後就覺得可以了，但是隨著後期資料量的增大，這種設計問題就逐漸暴露出來了，資料量大了之後查詢效率比較低，因此後期增加時間段作為約束條件，提高了查詢效率。這些問題如果經過反覆的大量的測試是可以在早期就能發現的，這也為我以後的單元測試提了乙個醒。
4、使用者沒完成乙個操作要給出提示，特別是操作失敗的時候，用瀏覽器的alert()或者confirm()作為提示使用者體驗很不好。一開始的時候只注重在功能的開發上，沒有注意使用者體驗，以後這方面需要更加注意。
5、頁面重新整理可以簡化流程。會議室結束時間的選擇這個功能上，我一開始想的是，在增刪改這幾個操作完成後進行重置，沒有使用頁面自動重新整理，這樣就把問題複雜化了，測試的時候問題比較多，因為在增或者刪或者改這幾個操作完成時都要進行重置，有可能出現遺漏。後來，我設定了頁面重新整理，增刪改完成後每次都重新整理頁面，問題就得到了簡化，測試的時候有問題也比較好找了。
6、這個專案前端部分我是用的原生js寫的，原生js的語句比較麻煩，有時候為了選定乙個元件要寫很長的語句，而且.innerhtml()方法還不一定能顯示所有元件內部的文字，有的需要在瀏覽器裡console出來才能確定。這也花費了一定的時間，所以以後會盡量使用jquery來寫（如果不用框架的話）。
會議室預約系統專案總結記錄
1.id必須是唯一的。2.重複的 要提出來，讓 更簡潔，注意 的復用性。3.c3p0連線池，一定要關閉連線。4.頁面不要寫死，盡量用js去實現，頁面要做到自適應，盡量不要固定大小。5.對於容易出異常的 要捕獲異常並丟擲，要把異常返回到頁面，並進行提醒。6.在用擷取字串的方法操作字串時，要注意判斷空字...
會議室預約系統 檢驗是否被預約核心SQL
會議室預約系統，在工作中經常會用到，這裡我記錄下，首先看下面一張圖 例如有這麼乙個場景，某公司有乙個會議室9 00至11 00預約了，預約這段時間，其他人不得使用會議室。如何通過sql實現？注 這裡9 00至11 00 對應字段分別是starttime和endtime，10 00至12 00 對應字...
django 簡單會議室預約（1）
django 是python的乙個web框架，為什麼要用django，作者之前用過另乙個框架flask，雖然flask比較簡單很容易讓人學，但是flask沒有整體感，會讓初學著茫然。這裡我們用django。現在最新版本是django 1.9.2。從1.7開始就有點區別了，後面會講到。首先搭建環境 u...