首先我了解了與第一章內容：概論
1.1軟體=程式+軟體工程
第一章主要講述了
軟體團隊的成員每天都在修改各種源**，怎麼保證軟體在修改過程中質量不斷提高，至少要維持以前的質量?有些時候，我們要為某個需求寫些特殊功能， 不久後又要把這些功能再合併回主要版本。有些程式要配置不同的介面，執行在中文、英文或其他語言的作業系統上:有些程式還有32位版本、64位版本等。這是源**管理( source code contol )的問題一也叫配置管理(sofware confuration management)。我們還有一系列的工具、 流程和文件來保證程式的正確性，這些工具(也是軟體)、流程應該達到很高的質量，才能保證開發出來的軟體的質量。這就是質呈保障(quality asurance)具體的驗證過程叫做軟體測試(test)。乙個軟體或者服務要有人買，就得找到顧客。顧客有各種需求，有些靠譜，有些不靠譜:有些容易做到，有些難以做到。軟體團隊要從需求分析( requirement analysis)開始，把合適的需求梳理出來，然後逐步展開後續工作，如設計(軟體架構)、實現(寫資料結構和演算法)、測試，到最後發布軟體。
軟體團隊的人員也會流動，新的成員要盡快讀懂已有的程式，了解程式的設計，這叫程式理解( program comprehension)。軟體在執行過程中還會出這樣那樣的問題，也許我們要時不時給軟體打乙個補丁，或者維護眾多的服務，團隊的新老成員要起修復各 種各樣的問題，這叫軟體維護( software maintenance),或者服務運營( service operation)。這系列過程就是軟體的生命週期(sofware life cycle, slc).在這週期中，有人得負責軟體專案的管理( project management)。
軟體還有其他特性：
·有許多不同的程式語言、軟體工具和軟體開發平台
·存在許多不同的軟體開發流程
·軟體團隊中存在許多不同的角色
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...