今天的这篇博文，我不谈及具体的编程技术，只想从这段时间的学习以及写代码的过程中，分享一下自己的编程体会。

上周呢，项目中碰到了一个新的任务，要接入一个第三方外设厂商的蓝牙设备，对方公司提供了一个sdk。其实接入一个sdk这个小事情呢，每个从业者都会碰到，合理的选用第三方的sdk服务能大大缩短我们的开发时间，让我们把目光都放到自己的核心业务上去。而碰巧这个sdk是对方公司新写出来的，于是，本着怀疑的态度，我开始了对这个sdk包的接入工作。

由于这个sdk包是新版，为了预防后面的升级，为了松耦合，我在这个第三方库上加了一层完整的封装。仔细的整理好项目的需求，封装了一层适用于项目的API接口，并且提供给团队的小伙伴使用。而既然是要提供给团队的小伙伴使用的API，我在编写代码的过程中慎之又慎，单元测试覆盖率基本达到了95%以上。很早以前我有一篇博文，是专门讲TDD模式和一款Kiwi的测试框架，其实那个阶段的我，更多的是停留在对那款单元测试的框架使用和摸索上，并没有极大程度的重视TDD的思想。而在又重读《Clean Code》这本书之后，单元测试的这根弦又在我脑子里绷紧了。

于是在这次的编码过程中，没有经过单元测试的代码，坚决不能放在生产环境里成了我坚持的原则，每一行代码都必须跑过，在各种条件下测试过，才会成为放心的代码，才能在之后放心的重构。不然小伙伴调用API的时候如果产生了一堆bug，你让我这张脸往哪搁。在这样的实践之下，我逐渐尝到了测试驱动开发这个思想的甜头，之前我还有接入其他设备的经验，但是当时赶工期，缺乏系统的单元测试，使得上线后bug不断，有时候debug时定位都要花费一些功夫，但是当你的每行代码都跑过单元测试时，你会对你的代码很有信心，并且能梳理的逻辑更清楚。况且，你要进行单元测试，那么以最小单元模块为单位的代码块或者函数，也必然是一段短小的代码，符合短函数的要求，最近苛刻的要求自己绝对不写超过20行的代码。只为函数的单一职责和逻辑清晰。

通过近期补充自己的数据结构和算法知识，我在敲代码的过程中，对这个方面，也多了一层考虑。从一些细节方面来思考怎么把代码写的更好，除了表层的代码风格，在组织数据时，考虑是否有合适的数据结构类型可以使用，并且哪怕小到一个排序算法，或者查找算法，也会想怎么写才能更有效率，平衡时间复杂度和空间复杂度的关系。这些意识都是之前所不具备的，所以感觉到最近自己在编程方面通过学习还是有一些提升的。而同时也很后悔自己对于这方面知识的学习来的太晚，回顾以前写的代码，还是生产了不小量的脏代码。检索一组规律数据，使用从头遍历这样时间复杂度底下的方式，实在不应该。

其他的一些编码细节也慢慢注意了起来，比如命名的更合理规范明确，比如函数在类里的摆放位置，一切其实都是为了一个事情，就是代码的可读性。写出来的代码20%的时间在开发，80%的时间在维护，可读性是非常重要的一件事情，而最近不断培养的也正是这个意识，只希望写出能让人读的舒服的代码。仅此而已。

近期敲得代码比较杂，写过前端三件套，HTML+CSS+JavaScript,并且系统的学习了Vue框架，也用了stylus这个css预处理器写过css，算法数据结构用Java写，后端的处理是php，框架使用了Laravel，iOS端Swift Objective-C混写，慢慢的有种感受就是，其实用什么框架用什么语言真的无所谓，早先时候，自己还是太过于追求框架，有时候学习的路线反而是不正确是，是要去深刻的理解一门语言，以及这个语言主要解决问题的场景，而非如何使用一个趁手的框架去完成任务，轮子是永远造不完的，旧的框架以后一定会被新的取代，而语言特性这种小细节，是需要去细细体会，花时间琢磨的。

今天随便说说的一些体会，也只是为了写出更好的代码，仅此而已。