在我們軟體設計與實現之前，我們是做過典型使用者分析的，部落格中也有提到過，並且針對我團隊專案做了相關分析。點向使用者分析過程中，我們能夠從使用者的角度去模擬使用的過程，從而去實現對使用者需求的分析，還有對不同使用者的不同使用需求，目的是搞清楚軟體該如何解決使用者的需求。個人感覺這個工作在前期去做很有必要。那麼在做完了典型使用者分析之後，我們是不是應該去對軟體進行具體的實現呢，構建之法中講到了這個內容。
軟體的「設計與實現」的目的則是搞清楚軟體是怎樣解決的使用者的這些需求。常見的方法有雞兔同籠**法，就是對問題的理解、抽象以及找到合適的數學模型，然後去解決問題。方法還有以文字為主的文件，以數學語言的描述，用類自然語言+**構造的描述。在影象建模中又有如何表達實體和實體之間的關係、資料之間的流動、表達控制流。掌握了這些方法之後，我們又不能隨意的去程式設計，日常開發中我們又會遇到很多問題，開發中的日常管理又是一門學問。
「閉門造車」也是一種方法，只不過是一種錯的方法。當時平常我們又真的會遇到這樣的情況。比如：我們團隊程式設計時，可能看到乙個bug之後，又想把它整出來，但是思路又不是很明確，就自己坐在電腦前面，無論是發呆，還是在思考，反正時間是保證了8-10個小時的程式設計，要問成果，幾乎為零。這就是所謂的閉門造車。我們應該做的是每日構建，或者每週構建，在衝刺階段這尤為重要，當我們一天沒有進度的時候，為什麼不去問問別人或者去**一下解決的辦法呢。這也是老師叫我們使用github的最重要的原因吧！在構建過程中，**規範、單元測試又顯得極為重要。我們團隊總會出現這樣乙個角色，當團隊成員把某些功能的**敲出來以後，由乙個人負責整合，往往他完成的工作就是構建伺服器，除錯構建，這樣的人成為「構建大師」。
我們在團隊開發中，往往需要團隊成員之間相互交流，相互合作，避免出現閉門造車的情況。靈位還有乙個體會，自己的**只有自己用起來如魚得水，往往整合別人**時候，出來的bug總得去問**原主人，這其實還是因為**規範問題。
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...
構建之法閱讀筆記06
夢斷 06 程式設計師常依賴一種稱為 媽媽測試 的手段，以對計算機一無所知的父母為假象用例，有時甚至請這類使用者親自體驗。這是現在程式設計師的通病，做出來的軟體或許在計算機上是完美無誤的程式，甚至是最優化做快的演算法，但是使用者的體驗和反饋卻並不是很好，這就要考慮到軟體設計的問題了，良好的軟體設計像...
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...