我用github写代码

学习python,从网上找教程、找书、找开发工具,一路走来,基本上可以说掌握了python的基本知识,在这段说来非常漫长的学习过程中,学习到的经验知识都放在了印象笔记中;2018年在工作中接触到了使用类似github的代码工具管理代码,几十人的团队为了一个目的写代码,我看到了每次提交时代码的增删改一目了然,在提交的注释里也写明了这次修改是解决了什么问题、还是增加了什么功能,每个人都在自己的分支里提交代码,每次发布代码会有一个专门的分支,每个人写的代码在测试环境验证测试成功后,会发起merge请求合入这个待发布的分支,发起merge请求时要有merge请求的代码测试成功的截图,这样在大概率上避免了引入新的bug导致版本发布延迟的问题。

在工作上接触github之前,我就开始接触github了,只是没有意识到github能带来什么,改变什么。最近我在学习使用python写网络爬虫,看的是《用python写网络爬虫》这本书,鉴于在工作中看到的github所能带来的效果和好处,于是按照书中的例子自己实现的时候,就先建了一个git仓库,每次有内容修改、bug修改、新增功能时就push到这个git仓库,而且是在master分支之外建立了一个分支,先提交到了这个分支,然后后期再merge到dev或master分支,假装有很多人一起在给这项目写代码。这样的好处是哪天自己写了代码,代码上有哪些变化,一清二楚。

要写好代码,需要写真正的实用的项目,这是我最近的感受。

这个感受源自工作中当我真正的写了一些代码后,在此之前我只是在看书,写一些为了掌握这些知识点的例子,最多只是网上找到一些练习的项目;我开始在工作中写代码,是为了解决一个bug,这个bug别人反馈后因为我对这块的业务比较熟悉,通过查看源代码很快找到是代码中的一个bug引起的,也知道如何修改代码解决这个bug,代码修改后找了一线的一台服务器测试,发现没有问题后,就推广使用,没有想到很快一线反馈有问题,原因是修改的这个值可能是一个全局变量,导致这个变量的值不断累积,比如最开始的值是 var = 123 结果到了后面变成了 var = var: var: var: var: 123,最后通过增加一个新的变量来解决这个问题,问题虽然解决了,但是当时因为没有充分测试带来的问题也使我在后面解决其他bug和优化功能时要求自己要更加的仔细。后面在解决其他问题时,也发现了测试使用的测试版本和版本真正要使用的某个软件版本不一致,导致安装有问题,原因是这个软件的两个版本配置文件发生了变化,我们的工具在安装这个软件针对新的版本做了适配,如果测试时继续使用旧的版本,则要么测试不出问题,要么测试出问题也不是新版本的问题,和测试沟通后已经更换为最新的软件版本进行测试。

抓住机会参与到更多的代码开发工作中,在实战中提高自己的代码水平,同时也是克服自己没有真正编码经验感到软弱的方法。