今天的這篇博文，我不談及具體的編程技術，只想從這段時間的學習以及寫代碼的過程中，分享一下自己的編程體會。

上周呢，項目中碰到了一個新的任務，要接入一個第三方外設廠商的藍?牙設備，對方公司提供了一個sdk。其實接入一個sdk這個小事情呢，每個從業(yè)者都會碰到，合理的選用第三方的sdk服務能大大縮短我們的開發(fā)時間，讓我們把目光都放到自己的核心業(yè)務上去。而碰巧這個sdk是對方公司新寫出來的，于是，本著懷疑的態(tài)度，我開始了對這個sdk包的接入工作。

由于這個sdk包是新版，為了預防后面的升級，為了松耦合，我在這個第三方庫上加了一層完整的封裝。仔細的整理好項目的需求，封裝了一層適用于項目的API接口，并且提供給團隊的小伙伴使用。而既然是要提供給團隊的小伙伴使用的API，我在編寫代碼的過程中慎之又慎，單元測試覆蓋率基本達到了95%以上。很早以前我有一篇博文，是專門講TDD模式和一款Kiwi的測試框架，其實那個階段的我，更多的是停留在對那款單元測試的框架使用和摸索上，并沒有極大程度的重視TDD的思想。而在又重讀《Clean Code》這本書之后，單元測試的這根弦又在我腦子里繃緊了。

于是在這次的編碼過程中，沒有經(jīng)過單元測試的代碼，堅決不能放在生產(chǎn)環(huán)境里成了我堅持的原則，每一行代碼都必須跑過，在各種條件下測試過，才會成為放心的代碼，才能在之后放心的重構。不然小伙伴調(diào)用API的時候如果產(chǎn)生了一堆bug，你讓我這張臉往哪擱。在這樣的實踐之下，我逐漸嘗到了測試驅(qū)動開發(fā)這個思想的甜頭，之前我還有接入其他設備的經(jīng)驗，但是當時趕工期，缺乏系統(tǒng)的單元測試，使得上線后bug不斷，有時候debug時定位都要花費一些功夫，但是當你的每行代碼都跑過單元測試時，你會對你的代碼很有信心，并且能梳理的邏輯更清楚。況且，你要進行單元測試，那么以最小單元模塊為單位的代碼塊或者函數(shù)，也必然是一段短小的代碼，符合短函數(shù)的要求，最近苛刻的要求自己絕對不寫超過20行的代碼。只為函數(shù)的單一職責和邏輯清晰。

通過近期補充自己的數(shù)據(jù)結構和算法知識，我在敲代碼的過程中，對這個方面，也多了一層考慮。從一些細節(jié)方面來思考怎么把代碼寫的更好，除了表層的代碼風格，在組織數(shù)據(jù)時，考慮是否有合適的數(shù)據(jù)結構類型可以使用，并且哪怕小到一個排序算法，或者查找算法，也會想怎么寫才能更有效率，平衡時間復雜度和空間復雜度的關系。這些意識都是之前所不具備的，所以感覺到最近自己在編程方面通過學習還是有一些提升的。而同時也很后悔自己對于這方面知識的學習來的太晚，回顧以前寫的代碼，還是生產(chǎn)了不小量的臟代碼。檢索一組規(guī)律數(shù)據(jù)，使用從頭遍歷這樣時間復雜度底下的方式，實在不應該。

其他的一些編碼細節(jié)也慢慢注意了起來，比如命名的更合理規(guī)范明確，比如函數(shù)在類里的擺放位置，一切其實都是為了一個事情，就是代碼的可讀性。寫出來的代碼20%的時間在開發(fā)，80%的時間在維護，可讀性是非常重要的一件事情，而最近不斷培養(yǎng)的也正是這個意識，只希望寫出能讓人讀的舒服的代碼。僅此而已。

近期敲得代碼比較雜，寫過前端三件套，HTML+CSS+JavaScript,并且系統(tǒng)的學習了Vue框架，也用了stylus這個css預處理器寫過css，算法數(shù)據(jù)結構用Java寫，后端的處理是php，框架使用了Laravel，iOS端Swift Objective-C混寫，慢慢的有種感受就是，其實用什么框架用什么語言真的無所謂，早先時候，自己還是太過于追求框架，有時候?qū)W習的路線反而是不正確是，是要去深刻的理解一門語言，以及這個語言主要解決問題的場景，而非如何使用一個趁手的框架去完成任務，輪子是永遠造不完的，舊的框架以后一定會被新的取代，而語言特性這種小細節(jié)，是需要去細細體會，花時間琢磨的。

今天隨便說說的一些體會，也只是為了寫出更好的代碼，僅此而已。