近期編程反思
博客半年沒有更新了，自己在嘀嗒拼車的這半年里，更多的是對自己寫的代碼的一些反思，特此書寫記錄下來。
- 代碼如何寫的優雅？
- 這段代碼是否寫的很羅嗦？
- 是否可以換一種寫法或者是否能夠應用某個設計模式很好的解決這個問題？
- ··· </ul>
- 臨近上線日期了，先用這段代碼工作著吧。先不改了。（這樣的解決方案根據實際情況并不是不可以，但當下版本時間充足了，還是花時間重新改寫下為上策）
- 破窗理論：代碼里到處充斥者不良的代碼，改動需要花很大的精力，在時間不太允許的情況下，被動的在不良代碼上進行輸出代碼。
- 知識或者經驗上的短板：如果在某個知識上存在認知不足，很容易用自己僅有的可憐的不良方案來解決問題，殊不知，當你了解了它，換個思路，換個寫法，代碼能簡潔很多。
- 待補充··· </ol>
- 簡單的邏輯寫的異常羅嗦與復雜，容易引起錯誤就不說了，即便能夠正確工作也要花半天理解，難以閱讀；
- 充斥著重復的代碼：
- 似乎沒得選，只能重復？
- 根本沒意識到重復
- 知道重復還copy & paste，偷懶一時爽
- 開發者之間同時開發，交流不到位，重復造輪子的情況，無論是業務輪子還是復用組件的輪子 </ul> </li>
- 難以修改，難以擴展；
- 類過于龐大，承擔了很多其他本應該拆分開來的工作；
- 函數過長，可以通過提煉新函數來縮短函數，提煉的新函數的命名是否恰當直接決定了理解的難度；
- 其他··· </ol>
- 代碼格式整潔，能讓閱讀的人在最短的時間理解，那么它優雅的可能性非常的大。我們這里不談短碼編程，短碼編程是另外一種意義上的優雅，某方面而言；
- 簡單的邏輯，簡單的編寫，復雜的邏輯，還是簡單的編寫，做到這一步需要長時間的磨練；
- 無需注釋，清晰易讀；
- 程序的魯棒性好，易于修改和擴展，修改引入的bug相對少；
- 良好的模塊性，低耦合；
- 算法方面，簡潔、高效；
- 其他 </ol>
- 《重構-改善既有代碼的設計》
- 《修改代碼的藝術》
- 《編寫可讀代碼的藝術》 </ul>
- 提煉函數
- 內聯函數
- 內聯臨時變量
- 以查詢取代臨時變量
- 引入解釋性變量
- 分解臨時變量
- 移除對參數的賦值
- 以函數對象取代函數
- 替換算法 </ul>
- 函數重命名
- 添加、移除參數
- 將查詢函數、修改函數分離
- 引入參數對象
- 以工廠函數取代構造函數 </ul>
- 字段上移、下移
- 函數上移、下移
- 構造函數本體上移、下移
- 提煉子類、提煉超類、提煉接口
- 塑造模板函數
- 折疊繼承體系
- 委托、繼承的取代 </ul> </blockquote>
- 重構改進軟件設計
- 重構使軟件更容易理解
- 重構幫助找到bug
- 重構提高編程速度 </ol> </blockquote>
什么是優雅的代碼？或者說優雅的代碼有哪些特征？
程序員對算法和數據結構的掌握是必不可少的，但軟件工程的相關理論也十分有必要了解和熟練掌握。優雅的代碼不是一朝一夕煉成的，它需要非常多的代碼輸出量以及對既有代碼的反思。我們輸出垃圾代碼并不可怕，可怕的是從來不對垃圾代碼進行改進或者重構。作為一個注重實效的程序猿，我容忍不了項目的的雜亂。但凡有時間，我都會對代碼進行輕微的整理和改進，而整理的力度和改進同時也會受限于自己對項目的認知以及經驗。而我們也要批判地思考所有代碼，包括自己的。
如何寫出優雅的代碼？又或者說如何進行重構？
有很多關于此類話題的書。推薦三本：
在《重構-改善既有代碼的設計》一書中提到了重構的一些方法，很實用，也強烈推薦讀者理解每一條重構方法，結合自己的項目，進行實踐。
我摘取了一部分記錄了下來：
重新組織函數
簡化函數調用
處理概括關系
擼得了壞代碼，翻得了好書籍，反的一腦袋好思，方可擼得了好代碼。無他，僅此而已。
說了半天，壞代碼能工作為什么要重構？
引用《重構-改善既有代碼的設計》
那我要在什么時候重構？
原則：三次法則--事不過三，三則重構
添加功能時重構
修補錯誤時重構
復審代碼時重構
</blockquote>避免不清楚項目上線日期，而進行大規模重構，因為時間以及風險不可控。
多閱讀同事的代碼
閱讀同事的代碼，好處是不言而喻的。我強烈建議你在有時間的情況下，多閱讀下同事的代碼。無論好與壞。
在閱讀他人代碼的時候，覺得他們的代碼寫的不是很好，OK，提出你認為更好的解決辦法或者提出代碼中存在的bug漏洞。這何嘗不是一種進步。記住，跟進代碼，理解代碼的函數設計、調用跳轉從而分析出代碼的設計思路也是一種鍛煉。時間久了，會鍛煉我們閱讀源碼的能力，同時也教會我們分辨出好與壞的代碼。
閱讀他人代碼，如果發現竟然還可以這么設計、這么寫，你就賺了！
所以，多閱讀同事的代碼。
學會知識的分享
公司有一個良好的分享氛圍很重要，嘀嗒在朝著這方面努力。每周都會有分享會，我們移動內部也不定期會有分享。周的第一期是分享是關于Realm的，第二期我分享了LLDB調試以及UI調試，第三期是呆萌的敏捷開發相關分享，整體下來，有不少收獲。而其他朋友在后面都會有分享，蠻期待的。
分享的好處：為了能夠講明白，需要自己在下面做好功課，這本身就是加強學習的過程。能講出來，讓別人學習到，本身也是快樂的。
談責任
在這半年里，或多或少自己寫的代碼，由于QA部門沒有測試出來，而出現在線上的情況。我常常愧疚于自己產生的代碼bug出現在線上而引起用戶抱怨，降低了使用體驗。
然而，愧疚沒用！
拿起你的擔當！
第一件事，Fix the bug。
第二件事，為什么會引起這個bug。
第三件事，總結，以后如何避免？同樣的事情不要在犯。
這也是我在嘀嗒學到的很重要的一課。
最后
這篇文章偏向感悟多點，也作為我重視代碼質量的一個轉折點。
而這條路，沒有盡頭···
來自：https://github.com/dabing1022/Blog/issues/12本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
談代碼的壞味道
有味道的代碼永遠都存在的，每個人都或多或少不定期的產生一些垃圾代碼，而產生此類代碼的原因一般都有哪些原因？我曾經問過自己這樣的問題。常見的幾個原因有以下幾個：
前兩個跟開發項目時的心理有很大關系。而第三條，知識方面的問題，則需要我們不能停止學習，多反思。
而你，而我，中槍了嗎？三個我都中了。我在輸出著垃圾代碼。
以上原因都是引起軟件腐爛的原因，它們會增大軟件的熵。我從我們的移動總監（后文簡稱周）身上也學到了不少東西。周來公司的第一件事，就是干掉項目架構中不合理的地方，重新編寫，并且每個版本持續重構。周做的就是變化的催化劑，雖然一開始重構丟掉了一些東西，但某種意義上，他重新定義了一部分產品，包括交互和設計中不合理的東西。