《代碼大全2》學習筆記1

標籤：程式員   支援人員   原始碼   

第一部分：打好基礎

第一章

構建包括的範圍很大：

定義問題

需求分析

規劃構建

軟體架構（高層設計）

詳細設計

編碼與調試

單元測試

整合測試

整合

系統維護

保障維護

----------------

平時接觸的也就是從詳細設計到系統維護，

後面的測試和支援人員都是必須要打交道的，

但是定義問題和需求，基本都屬於產品部門。

----------------

P7：“很多項目，程式員得到的唯一文件就是原始碼本身。需求規格書和設計文檔可能過時，但是原始碼是最新的”

——基本如此，很多工程只有在編碼之前有需求文檔和設計文檔，在以後的修改中，基本都不會去修改這2個文檔。

----------------

構建活動主要是從詳細設計到開發人員測試，也就是程式員的工作，從設計到編碼實現，到最後的自測試。

P7：“構建活動是唯一一項確保會完成的工作”

因為時間原因，需求可能是臨時的，測試可能是不充分的，但是代碼必須編碼完成。

——以前有個培訓，排名程式員的各項條件，我把誠實放到後面了，不是它不重要，而是沒有辦法去不誠實，跟賣商品不一樣，有沒有實現需求，靠嘴說謊馬上就要露餡。

 

第二章

“隱喻的重要性。”

“使用隱喻的方法叫建模。比如分子運動理論是撞球，光的波粒二象性。”

“編程最大的調整是問題概念化，編程中很多錯誤是概念性的錯誤。”——個人認為，不應該是編程中，開始編程基本概念已經確定了，而是在前三步（定義問題，需求分析，規劃構建）

“把軟體的構建過程比作房屋的建設過程，移動承重牆肯定比移動隔牆成本低，軟體的結構改變也根本比周邊功能改動成本高。”

 

第三章

“準備工作的中心目標是減低風險。”

“建設大廈和搭建狗舍的前期準備肯定不一樣。”

“測試不能測試出‘設計了一個錯誤的產品’，解決缺陷要在構建活動之前完成”

準備工作不周全的原因“

1、絕大多數開發人員沒有需求、產品方面的經驗和訓練。

2、程式員無法抵禦‘儘快開始編碼’的慾望。

3、管理者對準備工作的重要性不理解。

--------------------

——對2深有體會，每次總是喜歡寫個大致的詳細設計，然後立刻投入編碼，不過似乎只有在編碼中才能更好的去構想細節，如果不編碼那麼腦袋裡面就沒有具體的印象，可能是沒有使用虛擬碼編程的習慣，在後面的章節裡面有虛擬碼編程的例子。

這也同樣導致了我寧願一個人加班完成工作，也不原因和別人合作完成一個程式。

不過在實際中，可能是我的團隊人數都很少，一個人的效率要比幾個人合作高的多。而且就算是分開每人維護一個模組，介面的調試都會花去很多時間。如果2個模組是自己一個人負責的，介面的調試很快就通過了。這或許也是最早設計報文格式的時候不周全導致的。

-------------------

“有時候使用者一開始不完全確定自己想要什麼，找出他們真正想要的，比做一個錯誤的東西再修正要好多了。”

沒有直接面對客戶，也沒有直接的感覺，但是客戶經常會提出永遠都用不到還必須要有的功能。

 

“需求、架構、構建，缺陷越靠前，修改的成本越大。”

------------------

“我們最好立即編碼，後面有很多調試要做。”和“我們沒有為測試安排太多時間，因為將來不會發現太多的缺陷。”

相對而言，第二個比第一個好。

-----------------

“迭代法開發比序列開發節約成本”

迭代法就是隨著項目的進展，開始檢查並返工，再進行下一步的開發。

序列法是開發完成後檢查並返工。

-----------------

“問題定義只是定義了問題是什麼，而不涉及解決方案。”

“問題定義要用顧客的語言來書寫，而不是用電腦的專業術語來敘述。”

‘我們的出口頻寬總是跑滿’，‘我們需要最佳化緩衝系統，讓出口頻寬不要跑滿’

明顯前一個是問題，而後一個不像問題，倒像一個解決方案了。

----------------

“明確需求有助於使用者駕馭系統功能，有助於避免程式員之間的爭論”

——感覺很多程式做出來，發現需求理解的不一樣，往往研發之間無關緊要的就糊過去了，最多的爭論在於研發和測試對它的不同理解。

“客戶經常改動需求，IBM的統計平均開發過程中，需求會有25%的改動。”

“客戶往往喜歡拍腦門，用成本和進度可以提醒他們。”

——哈

 

P42針對功能需求有疑問，這麼詳細的外部介面，包括握手協議，通訊協定到底是屬於需求還是屬於詳細設計？感覺不應該是需求層的啊。

P46資料設計也一樣的疑問，不過裡面提到的，使用什麼資料結構或演算法要寫出為什麼這麼用的好處，便於讓程式員洞察構架師的思想。

“資料通常只有一個子程式或一個類之間訪問”

“程式員會處於專業自豪感，對自己編寫的類做過度工程”

——的確是事實啊，但是如果有時間的話，難道不好嗎？

“架構應該描述所有主要決策的動機，而不是向來如此”

“優秀的架構很大程度上與機器和程式設計語言無關，但是也不能忽視環境。獨立於環境的好處是避免過度架構。”

 

第四章

構架決策：

選擇程式設計語言

編程約定（代碼規範和風格、效能or穩定）

團隊工作（代碼管理cvs，如何分工）

品質保證（先寫測試案例，評審）

工具（代碼管理工具、編譯工具）

本文出自 “飛翔正義的部落格” 部落格，請務必保留此出處http://xzq2000.blog.51cto.com/2487359/1767389

《代碼大全2》學習筆記1