這一部分的內容不是很明了，但這周經歷的一個項目，讓我對敏捷開發思想有了更深的理解。

　　這周到了第四部分，10~12章。其實這幾章上周就已經看過，只是沒怎麽懂。這幾章說了下設計模式的幾個原則。

　　Liskov替換原則，意思就是子類型必須能替換掉他們的基類。

　　依賴倒置原則，高層模塊不應該依賴於低層模塊。

　　接口隔離原則，客戶程序應該只依賴於他們實際的調用方法。

　　可能是我技術沒到家，基礎太薄弱的原因。雖然今天看了好多遍，也沒有很深入的理解。還是寫點這周發生的一些有關於敏捷思想的事情吧。

　　這周，是個平均每天晚上都10點多下班的一周。讓我思考了許多。也發現了許多自身存在的問題。

　　上周被經理安排幫助同事做項目，應該項目將要延期。首先的問題就是心態上的，我並沒有把這件事當成自己的。還是有很大的學生心態在作怪吧，就像以前老師給學生布置作業似得，布置下來了各人完成各人的不就好了嗎？哪有自己的作業完不成還要別人幫忙做的道理。然而並不是的，我也是雙標的。並不是模塊固定就是誰是誰的，後來我這邊來任務了，但因為我手上有事情，也有另外的同事來幫忙做。在工作時，確實不該只盯著自己手上那麽點工作想，要把思維擡得高一些，想想各方面的運作。項目如果延期了，在和甲方談項目時價格就會被壓低，最後可能會影響績效什麽的。（雖然做的好看起來和我們並沒有太多關系，但做的不好我們必然背鍋）

　　心態方面，一開始很氣，為自己莫名其妙來的活而氣。但換個角度想想，也挺好的，有代碼寫應該開心才對。總比在那沒事，解決現場問題和現場人玩尬聊來的強。

　　影響人心情的另一個原因就是代碼，同事的代碼寫的很多，而且各個頁面相似的代碼很多，都是重復代碼。看起來人很遭重。一開始我是邊寫邊抱怨的。但誰不知道代碼要易讀易修改呢？抱怨些政治正確的話並沒有用，一開始自己寫的時候也是在上面亂亂的基礎上寫，讓代碼更亂了。後來猛然發覺，寧願多花點時間，也要盡可能的把代碼寫的好看點。因為省那麽一時的時間，後續往往要花更多的時間。CV大法只能讓人一時快樂啊！

　　然後本來定的周三發包果然沒有發成。真是符合那條定律啊！往延期的項目中投人，來期望項目不延期，往往項目都會延期。那天大家在那思考了許久，發現了更多的問題。也是那天開始我才發現心態上有很大的問題。在經理交給我任務的那時起，這個“作業”就不是同事一個人的作業了，是我們三個人的。我應當把它當成自己的事情來做的。

　　首先改動的是表結構，本來的表結構只有2個字段，關聯id，列名集合（所有列名逗號分隔存進來），然後取數據的時候又要分成數組，數組裏每個i都要各種判斷，異常復雜。這樣好像也不能提高效率。想起曾經學的，數據庫的表結構設計，一行要能描述出來物品的屬性來，這樣的表結構顯然是描述不出來的。但表結構一動了，前後臺全要動，改動量實在太大了。所以之前就一直沒動。

　　但越不想做的事越會讓人做啊！最終還是改了表結構。不想讓表的字段太多，但想要描述這麽一個功能，就是需要這麽多的字段。現在想著字段太多，會不會影響到以後的效率什麽的，並不需要擔心。數據量真大到那種程度了，自然就知道怎麽提升效率，優化表結構了。目前的首要任務還是讓用戶願意在這個系統中錄入數據，增加數據量才對。這就是敏捷軟件思想吧，別去自作主張的想一些未來可能有的需求。先易於眼下的變化再說。

　　於是改寫了下現有的代碼，找出了其中共同的部分，datagrid（我們框架中用來在網頁展示一個多行表格的對象）和一個主鍵，寫了個方法，每個需要加載列名的時候調用一下就可以。方便省心了許多。。

　　項目在昨天，周六大體上的功能都差不多完成了，還有許多值得完善的部分，但足以周一發包出去了。還是挺有成就感來著的。做一件事情時，比技術更重要的是每個人都要有做成這件事的意願，把事情當成自己的事，才有可能把事情做好。這就是敏捷思想中以人為本的概念吧？

敏捷軟件開發：原則、模式與實踐【讀書筆記四】