今天的這篇博文盒揉，我不談及具體的編程技術，只想從這段時間的學習以及寫代碼的過程中怠苔，分享一下自己的編程體會。
上周呢仪糖，項目中碰到了一個新的任務柑司，要接入一個第三方外設廠商的藍?牙設備，對方公司提供了一個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)境里成了我堅持的原則簸州，每一行代碼都必須跑過鉴竭，在各種條件下測試過，才會成為放心的代碼岸浑，才能在之后放心的重構搏存。不然小伙伴調用API的時候如果產(chǎn)生了一堆bug，你讓我這張臉往哪擱矢洲。在這樣的實踐之下璧眠，我逐漸嘗到了測試驅動開發(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混寫，慢慢的有種感受就是荣赶，其實用什么框架用什么語言真的無所謂凤价，早先時候，自己還是太過于追求框架讯壶，有時候學習的路線反而是不正確是料仗，是要去深刻的理解一門語言，以及這個語言主要解決問題的場景伏蚊，而非如何使用一個趁手的框架去完成任務立轧，輪子是永遠造不完的，舊的框架以后一定會被新的取代躏吊，而語言特性這種小細節(jié)氛改，是需要去細細體會，花時間琢磨的比伏。
今天隨便說說的一些體會胜卤，也只是為了寫出更好的代碼，僅此而已赁项。
