雖然這是一個類似於api形式的項目，每個api裏面只有固定的get,post,之類的才能成爲方法。如果我在這個現有的風格上做一些修改，應用一些諸如《代碼大全》中定義的“最合適7”的規則，或者一個函數的篇幅最好是一個屏幕那麼高的規則，那麼會在現有的代碼中顯得格格不入。我還是把自己的心得記錄下來，作爲自己的一種追求和努力的方向吧！如果以後有機會，還是需要在一個能夠提升代碼風格的項目組鍛鍊下。
- 一個函數本應該只完成一個功能。
現在的系統中，很多地方做一些必要的參數合法性校驗，也一股腦寫到了函數體中。這導致可能需要閱讀幾十行代碼才能真正進入到核心功能部分的代碼。 - 寫了setters,getters的類，卻堂而皇之地將變量寫成了類變量，而且絲毫沒有用到private,protect。那在類外可以隨便直接調用這些類變量，還用setters和getters作甚？
- 分層混亂。下層操作和上層操作經常混在一起。例如，明明可以實例化類的時候，傳入一個構造函數的參數，就可以完成一些初始化操作，卻用了一個函數成員去專門進行了類操作。然後在定義了對象之後，先調用初始化操作的函數成員，然後再調用真正需要的操作。
- 類方法和普通的方法並沒有加以區分。一個類裏面，有的方法在外部不需要訪問，只在類的內部進行訪問，卻也被寫成了成員函數。
- 函數的命名不太有解釋性。這一點和第一點有交叉的地方。如果一個函數將很多毫無聯繫的操作揉在一個函數裏，那麼這也僅僅只是一種毫無意義的強硬做法。就是因爲它完成了很多功能，導致在起名字的時候不能有一個很好的答案。既做了大篇幅的合法性校驗，又去讀取了文件，還實例化了類變量，還對變量進行了修改。那麼最終這個函數應該叫什麼呢，這真的是一個讓人頭痛的問題。
- 在python深究中的“賦值引用問題”是我在讀代碼時，發現了不能理解的地方，然後進行的實踐。我不明白爲什麼原作者要給一個要操作的變量起了一個名字，然後對它做了一些修改，然後並沒有把這個修改過的新變量賦給原來的變量，結果運行結果卻還是正確的！如果說寫這些代碼的人明白其中的真理，那還好。如果是誤打誤撞，碰到了python這門語言的特性，那麼下一次呢？
Ps.如果是python的特性，倒是值得了解一下。所以我在知乎上提問，希望有高人指點我。 - 變量名非常ugly.在使用flask_restful的時候，需要定一些用於解析參數的變量，當一個api有多個參數時，就用了parser1, parser2, parser3這樣的命名方式。非常沒有意義，以及容易帶來迷惑。
- 代碼邏輯混亂。《代碼大全》裏面提到，一個好的做法是花更多的時間去想實現的具體細節，在還沒有想清楚自己怎麼實現的時候，還不是動手寫代碼的時候。現在的項目中很多代碼明顯沒有經過謹慎的思考就動手寫了。一個例子是，一個用於自動化獲取數據的線程中，包含了三個部分。提取數據部分的代碼，和線程的控制部分的代碼，混在一起，可讀性非常差。更好的做法是將獲取數據的部分，也就是業務部分，定義爲函數，將代碼放在裏面。然後控制線程運行的部分，只寫這部分邏輯的代碼。另外一個不好的例子，從數據庫中刪除數據，同時再從本地刪除。實際上，不管數據庫刪沒刪數據，本地刪沒刪，這個刪除的api都應該是成功的。區別就是刪除了數據，和沒有數據可刪。這個區別也只是爲了給程序員debug使用，但是代碼裏卻將這兩個刪除操作的結果組合起來寫了4條分支用於處理不同的情況。例如：刪除數據庫成功，本地數據沒有可刪。或者兩者都成功。因爲我後來加的代碼還要多刪一個數據庫的數據，那豈不是得寫8個分支了，用這麼多的代碼就爲了處理這麼簡單的邏輯，不是浪費資源嗎。明明只要將不同的刪除結果作爲參數返回就好了。一句if else都不需要。
===============
感覺現在呆的項目組一點東西都學不到了。
雖然svn也是版本控制系統，它不如git好用（個人觀點）。但是，svn也有branch呀！現在的svn倉庫中，基於不同的開發需求，不同的開發者，有很多個源代碼庫！在這樣的環境中，如果我做了正確的事，其實會被當成另類。
關於技術雖然沒有學習到，但關於工作態度還是學到很多。現在的leader是一個非常有責任心的人，也非常的上進。總是很積極主動地去做一些項目上的事情。真的很佩服他。如果讓我帶一個項目，如何跟客戶溝通，如何統籌成員的工作任務，這些都是我不太擅長的。
在這樣的環境中，以及當前的局勢下，我還是好好想想如何保持我的雞頭不動吧。
希望這篇流水賬式學習心得能夠給你哪怕一絲幫助~祝好！