項目編寫時的注意事項

标簽（空格分隔）： 個人總結

最近學了很多知識點，也通過幾個作業、項目将這些知識點串聯在一起，互相協作完成一個程式豐富的功能。

在寫項目的時候，最大的困難是沒有一個很好的編寫流程。雖然對于項目的每一個功能都可以單獨的分析并提出解決方法和思路，也可以寫出對應的知識點來完成此功能。但是多個功能之間的互動、函數劃分、接口調用方法等等，涉及子產品之間或者說涉及全局規劃時，就會無從下手。

自己分析過，可能有幾個原因：

1、看的其他人寫的代碼太少，其他人寫的架構、思路是可以借鑒的
2、自己寫的代碼太少，（不過在沒有架構思維的情況下一味的練習隻會轉牛角尖出不來）
3、需要一個全流程的指導，并分析各個環節的作用，環節之間的互相作用           

經過1個多月的學習，從自己的代碼、别人寫的代碼、一些書籍的閱讀之後，大緻對于全局編碼，有如下幾點經驗：

設計角度：
1、函數大小：不應該超過1頁
2、高聚合：一個函數裡的代碼應該有一個共同完成的目标，如果有兩個，應該拆分
3、耦合性：
    a、使用參數和return來提高耦合，盡量甚至不使用全局變量
    b、避免修改傳入的對象内容，如果有必要，可以考慮copy
    c、避免import *，一是可讀性差，二是污染目前子產品命名空間
    d、函數接口設計要功能分離，同時，将系統函數（或常用函數）與自定義函數分開，友善後期測試           

類角度：
1、類的接口，哪些需要對外提供，哪些是内部接口（使用 _ 或者 __ 來隐藏接口）
2、類中方法的抽象層次，一般來說，相似的功能應該有相同的抽象層次，抽象層次的設計就是函數結構的設計
3、函數的通用性，函數應該盡量設計成可以通用的，這樣可以提高抽象程度           

編碼角度：
1、每次應該隻寫一小部分代碼，聚焦一個小功能的實作，不要這裡寫一點，那裡修改一點，聚焦視角
2、每完成一小部分代碼的編寫，立馬測試
3、小步走，多測試
4、要有架構思維、全局思路，但是實際編碼的時候應該一步步寫，日漸豐富程式功能。一開始就寫好架構再填寫代碼并不合适（至少目前對我而言），非常容易發生：寫到某一部分時發現需要重構架構，導緻整體推翻。
5、内部接口和外部接口一樣要整潔漂亮，内部接口代碼（對内使用）不應該随意編寫。           

幾點教訓：
1、不應該過于抽象化，因為抽象化意味着高耦合，一旦需要重構，需要修改每一處被抽象的地方。
2、不應該過長時間思考和編碼，如果連續編碼8個小時，基本上已經沒有思路和創新，應該休息和放松。
3、精力很重要，是以要經常鍛煉身體，我發現身體的鍛煉可以提升腦力容量。
4、編碼的速度越快、一次性想要做的事情越多，就會做的越差，慢即是快，真的是一個沖突但是有效的事實。