随着时间的推移，我的上一份工作已经告一段落，今后的一段时间离我将会作为Golang软件工程师而存在，而不是现在的Java程序员。

关于语言

我由初入职场时的Java语言开发到现在的转向Golang开发，这并不意味着我觉得Golang比Java好，只是单纯的改变了一下技术方向而已。对于编程语言，我并不像大多数人那样有固定的偏好，而且部分人在语言之争上比较偏激；对于我来说我接触过的所有的编程语言我都喜欢，同时，我也不像大多数人那样只会一门编程语言，比如Java或PHP，在某些技术社区上Java开发者与PHP开发者总是为了诸如“谁是最好的编程语言”这一议题争得不可开交。

从我接触编程到现在先后接触了一些语言，最早在高中的时候是Visual Basic，后来进入大学了正式学习编程了，在大一上学期自学入门的语言是JavaScript，因为我在高中时候就有一个建网站的梦想，所以了解前端技术栈相对于我的同学要早，因此我进入大学的时候就知道了JavaScript在前端技术中的地位。大一下学期大学课程开始学习C++了，与此同时我开始自学PHP，开始了解并使用MySQL数据库，也是此时我正式开始理解“面向对象”这一概念，后来大二学校课程学习了C#这门语言，同时这一年我在学校学生组织里面开始为学校建设网站，用的是PHP语言，MySQL数据库以及Linux服务器，对Linux服务器的了解也是从此时开始的。用PHP写网站大概写了一年多的时间，期间由于我对前端非常了解，那时的我算是个比较菜的全栈工程师了。大二是疯狂的一年，每天晚上至少凌晨2点才睡觉，因此导致一些课程挂科了，大三是反省的一年。同时大三也是技术沉淀的一年，大三我开始重新学习C语言，这回是认认真真的学习，在解决了一个个的内存错误（segment fault）之后，对编程有了新的理解，对于内存，指针，文件，网络这些东西有了进一步的了解。那一年我开始写了一些小项目以及pinyin-php，同时学习了Golang，当时我觉得Golang太好学了，从完全不了解Golang到用Golang的Beego框架写出一个博客系统只用了两周时间，或许是因为之前在学C语言，初学Golang感觉自己如同解放了一般。

总之，我对任何语言都是一视同仁，我并没有觉得Java不好，相反，我觉得Java是各方面都比较完备的一门语言。而且，就我目前来看，我更想了解的是语言的本身，因此我将编译原理作为我之后要研究的领域之一。

关于项目

论项目经验，我从大学时开始做第一个真正的项目到现在也有大约4年了吧。最初无人领路不框架为何物，靠着自己的毅力不停的堆代码，发现最后自己堆砌的PHP代码的复杂都已经超出了我的理解范围了，项目开始混乱得我已经无法维护了，于是，第一个项目以失败告终。后来，了解并学习了Web框架发现使用框架写代码更加得心应手。而最近的项目中的经历再次印证了一个好的框架是多么的重要；由于目前的项目的创始人打着“验证无框架开发的思路”的旗号搞了现在这么个项目——底层封装度非常底，该封装的都没有封装，而他所写的简单的封装并没有做到一个“框架”所应当做的事情，导致现在这个项目面临了许多比较坑的问题，比如数据库不能使用联查，这一问题同时导致了大家尽量避免联查，因此，项目在建数据表的时候也尽量的避免联查，于是数据表中出现了大量的冗余，再加上项目的各种改需求，数据结构已经变得不能看了。

这些项目经历告诉我“无框架”是扯淡，当项目复杂到一定程度“无框架”的项目将会复杂到无法维护，一个比较好的项目首先是要有一个比较好的框架，而不是无框架，好的框架应该是低耦合的，而且该有的基础功能都是有的，并且应该是可以扩充的，比如某些框架中的中间件概念。

关于工作

有时候在一个岗位上待久了并不是一件好事。首先，时间一长，在技术上就难以有新的收获，每天过着写业务逻辑的日子早就让我厌倦。然后，呆久了就不知道自己现在的价值如何了，也不了解市场的行情如何，所以我觉得不管是否有换工作的打算，每年都应该出去面试一波，一来了解一下自己目前的价值，二来了解一下市场行情。

关于生活

这一年，我有了她……

在公司团队协作用了大半年的Git了，PR工作模式也用了半年。由一个用Git装逼的假老手成长为真正用Git进行团队协作开发的老油条。这其中也有一些值得反思的东西。我很崇拜PR的工作模式，因为它基本上是优秀的开源软件工作模式的代表，众多的开发者自发的给开源项目发送PR，以前总是盼望着自己的开源项目会有人发送PR，若是接收到PR就像是收到别人的礼物一般高兴。

我之前赞同的PR工作模式是这样的，开发者拿到开发需求之后，在自己的分支开发，然后向主仓库的相关分支发送PR，之后由测试人员在测试机上拉取主仓库相关分支的代码，然后fetch PR所在仓库分支的代码合并(merge)到本地主仓库相关分支，进行测试，测试完毕通过之后才合并PR到分支。我这一想法的灵感来源于 travis-ci 单元测试的工作模式：开发人员发送PR，travis-ci自动进行单元测试，PR管理者参考PR在 travis-ci 上单元测试的结果进行初步判定是否可以合并。但是我忽略了一点，测试人员并非是 travis-ci 上的单元测试。在工作的过程中往往是这样的：

开发人员初步开发出某个功能，然后经过自己的初步测试，发送PR到主仓库，测试人员看到有PR了，需要测试了，于是开始测试，但是测试有问题，于是开发人员就必须继续修改提交，然后再次测试，还有一些问题被发现依然存在，继续开发……可是，你突然发现，你的PR被合并了或者是被关闭了，因为要下班了；或者是要下班了，PR管理员会问这个PR能否合并，测试人员暂时没发现新的问题，于是测试人员告诉PR管理员“没有问题”，于是PR被合并了。或者没有上面的“PR管理员的询问”，但不管怎样，最后的结果往往是PR被草草的合并了。于是，没有充分测试的PR进入了仓库，甚至进入了发布分支，最终的结果可想而知。

在这个过程中，人们往往没有意识到其实是被PR给影响到了。因为开发者一个PR创立之后，在他会有一个潜意识希望PR被合并，测试人员同样也有这么一个潜意识，因为测试PR就是他的工作之一，他也希望PR被合并，对于PR管理员来说同样也有这么一个潜意识，希望PR被处理，不管是合并还是关闭。就是这些潜意识推动这个PR尽早被合并。

我个人感觉正确的做法应该是当测试人员测试充分之后再发起PR，避免这些潜意识促使PR过早的被合并。事实上，不管PR是否存在，测试人员都能够从开发者的分支上拉取到开发者的代码合并到主仓库，PR不过是一个形式而已，给合并者带来方便。但是那些错误的理解了PR的人们往往会搞出诸多莫名其妙的东西，比如PR用来人工做代码审核，比如搞个CheckList让人工去查代码中哪儿写得不规范，这些应该是让 Sonar 自动扫描PR中存在的不规范，谁又会有时间去为别人的PR人工做Sonar该做的事情。经过测试人员的充分测试之后，开发者创建PR，这时单元测试测试一遍，然后Sonar扫描一遍，后两者自动化测试通过之后代码才能入库。

总之，测试人员功能测试通过之后开发者才能创建PR，自动化工具进行单元测试和Sonar扫描通过后，PR管理员才能允许合并。这才是比较靠谱的PR工作流。