《代碼大全2》 讀書筆記一

需求分期要做好，架構要搭好，如果沒有優秀的設計，架構，那麼程序員就不可能在垃圾堆裏編寫好的代碼。


架構就比如要在需要建造的小區裏的小水道和光纖、電纜的佈置規劃。這樣在蓋好一個樓之後，避免在樓下
挖下水道的問題。


早起的需求缺陷代價更加高昂。


問題定義應該用客戶的語句來描述，不應該帶有計算機專業術語，或者是聽起來像一個解決方案。


評估需求和架構的質量。


最激進的構建軟件的解決方案是根本不去構建它，購買軟件，插件，直接使用。否則，就需要知道我們自己定製的
組件在哪些方面勝過現成的組件。


優秀的架構與機器和編程語言無關。要儘可能獨立於環境，避免過度架構。架構師應該瞭解架構的羣補實現，並精簡架構必要的功能之外的其他鍍金功能。


有很多軟件架構的書籍推薦，但是都比較過時，而且不適用於遊戲開發，筆者準備在後續搜索一下，單獨發表出來一個遊戲架構方面的書籍列表。同時，程序
不應該被技術限制死，所以任何架構書應該都是可以瞭解的。


程序員所使用的編程語言所具有的單詞或功能，影響了程序員所理解的東西和理解的範圍，用A語言很熟悉，再用不熟悉的B語言，就容易寫出僞A思想的B代碼。