趁著這段時間還能抽出些時間，我對前一段時間在專案裡的經歷做了很大程度的思考，不得不說前端時間在專案組裡的猶如噩夢一般，詭異的後端架構、不穩定的**實現、緊張的專案進度以及不斷的需求變更都將開發推導了噩夢的邊緣。對比這些專案經歷，我重讀了人與神話這部描寫360os系統的建造者的經驗輯錄。
比較令我震驚的一點是360os的建造者，對於在開發過程中，嚴格的自律所起到的巨大作用的很重的一筆說明。嚴格的規則可以提高創造性。而這點，正是在專案開發的過程中，最為匱乏的一點，而且專案組的成員尚且沒有意識到這點，還以這種極度的自由為豪。針對無法控制後端**的複雜度的情況我不斷的在思考原因，排除我開發經驗的不足，過於自由的開發過程導致了不論是在設計架構的階段、還是在實現**功能階段，都充滿了隨性。表面上這是自由，但其實，這種情況正確的名稱應當是混亂。
除了對於自律的恪守，另外乙個比較引人注目的，便是對專案概念一致性的重視，概念的一致性不僅僅體現在整體設計保持統一，還包括在實現功能保持統一，**風格一致 ，命名規則一致，諸如此類的。**風格和命名規則比較容易理解和接受，但在保持整體的設計統一上，需要一位精英來充當暴君的角色，乙個人擬定好整體應當遵守的規則，然後其他人遵守，對這點而言，沒有所謂的民主可言。
在對專案進行反思的過程 中，值得注意的是 敏捷開發這種設計理念或者說哲學。雖然很早就看過關於 敏捷開發方面的介紹，但是真正在專案中碰到這樣的開發方式 還是覺得非常的突兀。我到現在也沒搞明白如此劇烈和快速度版本迭代，是如何控制專案**的穩定性的。除此之外，敏捷開發對實踐人員的要求其實不低，要求開發者不斷的學習新的理念和技術 ，並及時的融入進專案 裡面。這些都是非常考驗人的。
讀《人月神話》
翻開扉頁，購書日期 2003.2.10。實在汗顏，且此類書，我的案頭還有許多。在兩周中抽出時間，翻看完了這本傳說中的經典。總的感覺，收穫並不多，雖說有些東西並未能完全理解，但大多在作者看來是未來的東西，已早成為現實。大致看來，沒有什麼新的概念。於是，也談不上讀後感，只是把看的過程中的筆記重新寫一遍，...
讀《人月神話》
為什麼中國的程式設計師總是在不斷學習新的開發工具 鑽研程式 而不能逐步提公升自己的視野 思維和經驗？摘自序 所謂人月 man month 是軟體開發中工作量的度量，然而它卻不是線性的，10個人10個月可以完成的工作，很多情況下100個人並不能在1個月完成。以下是我的理解與摘抄 斜體是摘抄 當人數增多...
讀《人月神話》
人月神話的英文是 man month mythical 人月其實是軟體工程管理工程量的單位，乙個人每月的工作量，其實是想說明是使用人月的方式來估算大型專案是不靠譜的，只是乙個神話的方式。而作者frederick p.brooks,brooks被認為是 ibm 360系統之父 他擔任了360系統的專案...