讀《構建之法》後的疑惑

1.我在讀到第2頁時，我看到這一段文字：阿超要不斷地根據客戶們的要求修改完善本身的程序，咱們能夠看出，客戶對阿超的要求從一個簡單的程序，擴展到一個知足各類功能的應用軟件，再擴展到一個能保證服務質量的軟件服務，有這個問題 ，軟件團隊的成員天天都在修改各類源代碼，怎麼保證軟件在修改的過程當中不斷提升，至少要維持之前的質量？我查了資料，有這些說法：　高效的軟件開發團隊是創建在合理的開發流程及團隊成員密切的合做的基礎之上的，成員共同的迎接挑戰、有效的計劃、協調和管理各自的工做以致完成明確的目標。 據個人實踐，我獲得這些經驗：軟件是一個根據客戶要求不斷跟新，與時俱進的，做爲軟件工程的學習者，我應該認真的看待每個相關軟件問題。可是我仍是不太懂，個人困惑是，那麼咱們以前編寫的那些軟件就毫無心義了嗎？

2.我看了這一段文字現代軟件產業通過幾十年的發展，一個軟件有一我的單槍匹馬完成，已經不多見了，軟件在相互的合做中完成，合做最小的單位是兩我的，兩個工程師在一塊兒，作的最多的事情就是「看代碼」，每一個人都能看「別人的代碼」，並對發表意見。有這個問題 程序員寫的代碼是給人看的，仍是機器看的？ 我查了資料，有這些說法：人在看，機器也看，但最終是人在看，咱們的代碼要讓旁觀者看的「清清楚楚」,根據《計算機程序的構造和解釋》（簡稱爲SICP），這本書提到，代碼是寫給人看的，不是寫給機器看的，只是順便計算機能夠執行而已。若是代碼是寫給機器看的，那徹底可使用匯編語言或者機器語言(二進制),直接讓機器執行。我以爲：高級語言(java，php等都算),之因此被稱爲是高級語言，是相對彙編和機器指令而言的，他們更加可閱讀性，更加符合人類語言的閱讀習慣。低級語言讓人看起來很是吃力，不容易編寫，因此產生高級語言，容易上手點，代碼是寫給人看的，因此要作到良好的編程風格，方便其餘程序員閱讀，維護。因此這點我很是感悟，這確實是一個有力的證據。代碼的可讀性很是重要：註釋，空白對其，工整都是風格的提現。保持這些編程風格最終目的只有一個：方便人類閱讀。誠然，就算你不按照好的風格來編寫，編譯器也能識別，經過編譯。但基於可閱讀性、方便維護考慮。程序員仍是要有良好的編碼風格。可是我仍是不太懂，個人困惑是，代碼量小的話，能夠獨自一人完成，但代碼量極大的時候，則就須要多人協做完成代碼的編寫，那麼，在人和人不同，在和別人合做的時候，要如何作到我的的表達觀點的方式和思考的方式保持一致呢？

3.第11章中，有下面這樣一段內容 「5. 寫好代碼後，小飛對照設計文檔和代碼指南進行自我複審，重構代碼。」 對於代碼重構不是很清楚。我查了一些資料，都在強調着重構的好處，由於軟件產品最初製造出來，具備良好架構的。可是隨着時間的發展，需求發生變化，爲了實現變動，不可避免的要違反最初的設計構架。通過幾回修改後，軟件的架構就千瘡百孔了，並制約着新功能的實現等。最後新需求的開發成本會超過開發一個新的軟件的成本，而致使這個軟件的死亡。而重構在「軟件系統的過程, 它不會改變代碼的外部行爲, 同時改善其內部結構。 這是一種嚴格的清理代碼的方法, 它能夠最大限度地減小引入錯誤的可能性。 本質上, 當重構代碼時, 是在編寫代碼以後改進它的設計」可是我對於具體的狀況依然不是很瞭解，重構是對於舊的架構進行修改，來知足新的需求，那是否只是使用如今積木（代碼）搭建一個更漂亮更優秀的大樓呢？ 什麼時候應該進行重構呢？