現在的開發往往是很多人合作完成一款軟體應用，不同的開發人員之間就存在依賴關係。我需要呼叫你寫的**模組，你也需要呼叫我寫的**模組，但是因為不了解模組的變化，模組沒有達到高內聚低耦合造成了對其他模組的影響，往往會產生錯誤。在確定發布這個模組的時候，要經過完整的單元測試，為了達到事半功倍的效果，我們可以把規格說明說寫得詳細一些，詳細到各項要求都可以表示為乙個單元測試用例。
卡耐基梅隆有一套個人開發流程，很適用於我們做個人開發。接到專案之後我們可以按照以下幾個步驟來進行，
估算時間--->需求分析--->生成設計文件--->設計複審--->**規範--->具體設計--->編寫**--->**複審--->**測試--->記錄用時--->測試報告--->計算工作量--->總結--->討論改進。隨著工作年限的增長，編碼所佔的比例會越來越小，因為開發不再是一味地編碼，測試所佔的比重會越來越高，保證質量要求。
那麼，我們為什麼要用軟體工程呢？因為軟體工程把開發，運營，維護的過程中的技術，做法，習慣和思想結合到一起（軟體開發流程）提高了軟體開發，運營，維護的效率。同時，運用軟體工程，也減輕了我們的工作量，避免不必要的返工。
怎麼提高技能？通過不斷的努力，把那些低層次的問題都解決了，變成不用經過大腦的自動操作，然後才有時間和腦力來解決較高層次的問題。我們要精通低層次問題(int arr還是int arr,arraylist 還是 array),中層次問題（使用何種架構),高層次問題
構建之法閱讀筆記（4）
這週我閱讀了構建之法的第五章。這一章主要講述了團隊模式以及團隊開發的流程。學會了正確的區分團隊與非團隊 1.團隊有一致的集體目標，團隊要一起完成這目標。乙個團隊的成員不一定要同時工作。2.團隊成員有各自的分工，互相依賴合作，共同完成任務，而非團隊成員則是各自行動，獨立把任務完成，對其他人無實質影響。...
《構建之法》第4章
第四章是關於兩個人合作的概論 大概就是 規範性 複審 結對程式設計 和兩個人的合作的方式技巧 軟體從來不是乙個人的工作，是乙個團隊的作品。在開始之前我們需要先對程式設計有乙個規範性，不然團隊中的每個人只按照自己的思維去 行走，這是不行的。所以我們要準守 的規範性，這樣對團隊以及他人在工程進行中對 的...
讀構建之法筆記
目錄對於乙個專案的構建在這本書被分為了大概以下幾個步驟 在我看來其實總的來說可以用以下幾個計算機行業的名詞來概括 抽象化，互資訊，遞迴，模組化，規範 這本書在講到程式設計師的成長會在幾個方面都需要持續公升級，包括 的編寫 團隊溝通能力 工程構建 程式設計思想 並且在微軟的高階工程師和初級工程師的地方...