gopher 成长之路 (四)：GO 开发工程师写 QT

你比你自己想的要强大。

这个看起来或许在别的地方挺正常，但对于我来说是另一个感觉，写 QT 这一段的成长是关于责任与挑战。

如果你在读这篇文章，你可以想想你会怎么做。当时的我，工作快 3 年，带小团队半年，无 QT 开发经验，有服务端开发经验。

时间拉回 21 年 7 月底，此时的我是管理一个小团队，同时这个团队在 7 月初离职 3 人(总 6 人)，这个离职原因改天再说，不是那种撕逼那种就是了。其中一个离职的同事是负责之前 QT 开发的，为什么会用 QT 呢，这个是基于之前的产品开发选型，所以选了这个 QT。

为什么我要写或者说我要接这个 QT 呢？你可能会说这个人离职了，那就在招一个嘛，关键就在于，这个产品平时需求不多，加上我们是 Go 团队，就很尴尬。这个产品不考验性能，有功能就行，所以招一个过来反而会晾在那里，没有活。但是，这个产品如果客户提出需求你不做，又不行，有时候还不管你的排期，得按照他们的修改走，很难受。而且这个产品是在公司的产品线规划里面，丢不能丢，但也没想往里面投人。因此，就造成这种局面，招也不是，不招也不是。最后呢，内部消化。

Q1：如果是你，你会怎么处理，会接下这个任务吗？

当时在我们公司没有人会写 QT 了，但有人会写 C++(QT 可以算是 C++的一个框架)，然而他们是算法团队，不是很想接应用开发的活。那怎么办呢？只好我自己接了，团队里的其他人要写这个更困难。那我真的想写吗？在当时，答案是不想，因为觉得没什么前途，与我的职业发展方向，背道而驰。这个活只为了完成而完成，没有动力去写？当时我也在努力学 Go 中，所以有些排斥，而且 7 月份我还在出差。

Q2：如果在 Q1 选择了接受，那是真心的吗？

这个产品的开发，不写也得写，不写的话，对公司某条业务线会受到影响。那怎么办呢？硬着头皮写，带着抱怨写，完成了就行了。接这个活一开始担心的啥呢，无非就是不会写，因为没有用 C++开发或，所以觉得还得去花很多时间去学。但是会看过去几个版本的迭代，虽然有不会的，也很想去问前同事，但是大多数都是自己解决的。自己的性格也是那种不想麻烦人的，而且是离职的同事，更不好意思一直去烦别人。相较于我在开发 Go 服务端，这个产品还需要用 wsdl，我真的是。。。

Q3：如果碰到不会的，你会频繁地去问前同事吗？

说到 wsdl，再退 2 年左右，我也要写 wsdl，要写一个服务端接这个 wsdl，当时我想了 1 周，学了 1 周毫无头绪。那时候，还是我的领导写出来的，当时我就在旁边看。2 年后，我在写 wsdl，虽然不是用正规军的讨论，但我用别的方法把这个功能实现了，就用了 1 天。如果说 2 年有么有成长，那看起来还是有点的。

接下这个任务的时候，也只是说大体上只会改接口字段，其他不会改。然而，慢慢地随着字段要添加，UI 要改，QT 布局又不好做。到后来，wsdl 不要了，要改成 http 接口。其中一个接口 50 60 个字段，调用逻辑还全都改了。还多了弹窗，要做页面弹窗，原本的记录还得支持修改，就是那个 50 60 个字段。

Q4：如果是你，你会怎么去开发呢？

最后结果呢？经历了 2 个大版本改造，几个小版本迭代，顺利地交付给客户，更新他们的系统。也从只会改接口，到最后可以改 UI，加页面弹窗等等，在刚接任务的时候，想都不敢想。在这条产品线，虽然不是说给公司带来多少收益，但是也算是给公司立住了信誉吧。

其实回看这一段开发 QT 的过程，有几个点，我觉得有几个点是我做得还不错的，这个过程中，心态也有了很大的转变。我是真的没有想到我可以完成。

说是开发 QT，在交接的时候，也是抓住重点，更多改的是接口字段。

第一阶段，那在同事离职之前，先列下来，最常改的接口在哪，要怎么加字段，如何生成新的接口(wsdl 需要)，如何打包。在一开始的时候，还是可以的，应付了一段。

第二阶段，新字段在 UI 上体现，那就只好去看里面的代码怎么实现的，照着写。因为这个阶段改的比较多，所以就列了一个类似 SOP。如果要加一个字段，去某几个文件，按照顺序，添加下来那就没问题了。就这样，也撑过了第二个阶段。

到第三个阶段，wsdl 要改成 http json 传参。那只好查资料，全改，慢慢改，慢慢测试。

最后需要加新的弹窗，这个不是改一点了，也是照着里面有实现的代码仿照着写。

虽然真个过程也去问了前同事，基本上是实在想不到的时候才去，不过大多数都是我自己弄出来的。

单纯说写代码，这么一看其实最主要的就是 3 点：抓重点，多总结，会模仿。如果在一开始，就把自己再束缚在要学 QT，那可能一开始就很难，而我是抓住重点，先就可能会改的地方，先熟悉。然后到了后面，如果有类似的功能已经实现的，我可以很快的地找到源码，并且去模仿它实现。在这过程中，我多做总结，把范式的提炼出来，一是加快我的开发速度，二是减少 bug 的出现，因为字段很多，加的地方也很多。会看源码，会去模仿，应该是让我能够顺利开发完的基础。

最后说说转变。最大的改变就是从我不行，到我可以。刚开始在接的时候，可能更多的是说我不行，甚至在别的任务碰到难的，没接触过的，大多数人会先说或者先想我不行。其实很重要的一点是，在说我不行的时候，是否先分析，评估过？然后工作不可能都是自己喜欢的，工作其实也不都是来沉淀自己的硬实力的。再回到当初，我能说不接吗？答案应该也是不能的，当时我也算是团队里面能写一点的，无论从个人还是从公司层面，我都需要去承担这个责任。或许在那个时候我不能再已一个工程师的角度去看这个问题，而是得上升一个层次去看待了。我接下来的工作也不会都是我做过的，没有突破自己的舒适区，自己也不会有更多的成长不是吗？在每次完成一个阶段的开发，我都对我自己能够完成任务，刮目相看。

因此，经历过这么一段可以算是身心疲惫的开发历程，让自己的心态以及对自己的认识上，有了一个新的突破。正如文章前面提到的，你比你自己想的要强大。