简单的编程体会

2017/04/27 技术笔记

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

上周呢,项目中碰到了一个新的任务,要接入一个第三方外设厂商的蓝牙设备,对方公司提供了一个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混写,慢慢的有种感受就是,其实用什么框架用什么语言真的无所谓,早先时候,自己还是太过于追求框架,有时候学习的路线反而是不正确是,是要去深刻的理解一门语言,以及这个语言主要解决问题的场景,而非如何使用一个趁手的框架去完成任务,轮子是永远造不完的,旧的框架以后一定会被新的取代,而语言特性这种小细节,是需要去细细体会,花时间琢磨的。

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

Search

    Table of Contents