《程序員修煉之道–從小工到專家》閱讀筆記03

第六章閱讀筆記及其我的感覺

咱們想要讓編寫代碼所花的時間越少，想要儘量在開發週期的早期抓住並修正代碼錯誤，想要在一開始就少製造錯誤。若是咱們可以深思熟慮的編程，那這些會對咱們有所幫助：

• 老是意識到你在作什麼。
• 不要盲目的編程。（試圖構建你徹底不熟悉的應用或者使用你不熟悉的技術）
• 按照計劃行事，無論計劃是在你的大腦中仍是在別的什麼地方。
• 依靠可靠的事物，不要依靠巧合或假定。
• 爲你的假定創建文檔，「按合約設計」。
• 不要只是測試你的代碼，還要測試你的假定。不要猜想，要實際嘗試它。編寫斷言測試你的假定。
• 爲你的工做劃分優先級，把時間花在重要的方面。
• 不要作歷史的奴隸。不要讓已有的代碼支配未來的代碼。準備好進行重構。

筆記1）爲你的工做劃分優先級，把時間花在重要的方面。

我的感覺1）我之前j老是把時間花在小細節上，結果最後弄得特別拖延，耽誤了整個項目的運行，這樣作是不對的，要學會分清什麼是重要的什麼是不重要的，劃分好優先級，先把控大方向，將時間花在重要的方面。

筆記2）不要作歷史的奴隸。不要讓已有的代碼支配未來的代碼。準備好進行重構。

我的感覺2）重構，能夠經過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提升軟件的擴展性和維護性。要知道一個完美得能夠預見將來任何變化的設計，或一個靈活得能夠容納任何擴展的設計是不存在的。系統設計人員對即將着手的項目每每只能從大方向予以把控，而沒法知道每一個細枝末節，其次永遠不變的就是變化，提出需求的用戶每每要在軟件成型後，纔開始"品頭論足"，系統設計人員畢竟不是先知先覺的神仙，功能的變化致使設計的調整再所不免。因此"測試爲先，持續重構"做爲良好開發習慣被愈來愈多的人所採納，測試和重構像黃河的護堤，成爲保證軟件質量的法寶。

第七章閱讀筆記及其我的感覺

筆記3）與用戶一同工做，以像用戶同樣思考

我的感覺3）有一種能深刻了解用戶需求、卻未獲得足夠利用的技術：成爲用戶。其實咱們老是以爲挖掘需求很難，或者抱怨用戶提的要求很過度時，那是由於咱們沒有站在用戶的角度去考慮問題，甚至咱們歷來沒有把本身當成過用戶。可實際上，咱們本身就是這個項目的第一個用戶，咱們要想一下，本身做爲用戶會有哪些想法或者叫需求。要學會創建需求文檔挖掘而不是搜索需求，學會使用用例圖（能夠用UML活動圖捕捉工做流，並且有時要爲手邊的事務建模，概念層類圖頗有用。用例能夠含有指向其餘用例的超連接，它們也能夠相互嵌套。）

筆記4）不要在盒子外思考，要找到盒子

我的感覺4）咱們可能會遇到不少棘手的問題，這個時候列出全部的在你面前的可能途徑，不要排除任何東西，無論它聽起來是否愚蠢，而後分類，從最爲嚴格的逐個擊破。

第八章閱讀筆記及其我的感覺

1、注重實效的團隊

不要破窗戶

質量是一個團隊問題。

煮青蛙

做爲總體的團隊甚至更容易被煮熟。

交流

團隊做爲實體須要同外界進行明晰的交流。

不要重複你本身

交流、不一樣的人指派不一樣的工做、即時聊天軟件

正交性

圍繞功能，而不是工做職務進行組織。

自動化

確保一致和準確的一種很好的方式是使團隊所作的每件事情自動化。

知道什麼時候中止繪畫

團隊是由個體組成的，讓每一個成員都能以他們本身的方式閃光。給他們足夠的空間，以支持他們，並確保項目的交付可以符合需求。

筆記5）不要重複你本身

交流、不一樣的人指派不一樣的工做、即時聊天軟件

我的感覺5）咱們的團隊就是一開始特別亂，一鍋粥，你們作一樣的事情，結果效率低下，就連這件事情也沒作好，因此啊得學會團隊分工，不一樣的人指派不一樣的工做。

筆記6）早測試，常測試，自動測試。

我的感覺6）一旦有了代碼，就要開始進行測試，越早發現bug，進行修補的成本就越低。「編一點，測一點」，要經過所有測試，編碼纔算完成。

測試什麼

• 單元測試
• 集成測試
• 驗證和校驗
• 資源耗盡、錯誤及恢復
• 性能測試（壓力測試、負載測試）
• 可用性測試（真實用戶在真實環境下進行的）

怎樣測試

• 迴歸測試——把當前測試的輸出與先前的做對比
• 測試數據——一種是真實數據，一種是合成數據
• 演練GUI系統——每每須要專門的測試工具
• 對測試進行測試——故意引入bug，以證明測試可以抓取
• 完全測試

什麼時候測試

許多項目每每會把測試留到最後一分鐘——最後期限立刻就要來臨時。咱們須要比這更早就要開始測試吧，任何產品代碼一旦存在，就須要進行測試。

有些測試可能須要頻繁進行測試，一般是單元測試和集成測試，每一次在代碼簽入源碼倉庫以前都要測試一下。

有些測試可能不容易頻繁進行測試，好比壓力測試，這些測試就不那麼頻繁，好比每週或每個月一次。