离职后的工作总结（2020-9-15）

我会带着你远行 2022-12-07 11:39 100阅读 0赞

2020年9月4日，我又离职了，工作才三个多月。算上这家，我已经待了三家公司了，但是离职原因都是相似的：觉得技术上没有提升以及想要更高的工资。这家公司也不例外，根据工作安排，我可能很长一段时间都要进行将MFC代码移植到Qt的工作，这无异是非常枯燥的事，于是我提出了辞职。也想过工作时间太短对下一次求职有影响，但我更不喜欢混日子，也许我脑子想问题就是这么简单（事实证明，确实有影响，虽然9月就拿到了offer，但是不满意，一直到11月初才找到个相对合适点的，这些公司基本都会介意频繁跳槽）。

虽然这份工作没做多久，但是也发现不少问题，才想要总结一下。

### 1.没有完全理解需求就开始写代码 ###

我这个习惯很不好，有些需求比较复杂，但我可能只理解了部分就开始动手写代码了，导致做一些无用功。特别是这次的迁移项目，在对项目没有整体认识的情况下，就自以为是的进行了部分所谓的优化，这时候如果原项目有什么改动，那改起来就很麻烦，还容易导致一些不必要的bug。

在今后进行开发时，尽量先对项目需求、业务逻辑有了一定的认识后再上手。

### 2.不对口头需求进行文档记录，以及不爱写注释 ###

这次这个移植项目有个很大的问题就是缺乏规范的文档和注释，只能问人和看代码，这也导致我需求理解不到位，走了不少弯路。诚然，有些项目需求变更很快，可能产品经理一句话的事你就得去改代码。但是一个项目组里至少应该有个人负责对需求文档进行整理，不然像我这种刚入职的根本就不好接手。

在注释方面，这个项目也是没人管的，这就导致很多地方注释都没有。如果一直是一个人开发还好，如果这个人离职或者其他原因需要别人来接手，只会增加别人的工作量。记得当时遇到一个问题，然后原来的负责人帮我找bug，找半天他自己也没找到问题所在，这就有点尴尬。

### 3.关于插件式开发 ###

该项目由于功能模块众多，而且针对不同的客户定制了部分独有的模块，所以将各个功能作为插件是不二的选择。在移植过程中，我也感受到了一些原设计不足的地方，比如内存的释放，存在A动态库创建B动态库释放的情况，如果是兼容还好，像VS2013和VS2017这种混合的就会出问题；比如公共库的设计，考虑到移植的话最好提供标准C/C++接口，而不是VC或Qt的，特别是原项目大量使用了窗口消息回调，想改成Qt信号槽就很费事；并且插件接口我觉得应该傻瓜式，而不是想查C还要先查A和B才能去查C，细粒度固然灵活，但是多人协作时应该提供便捷点的接口。

### 4.流程中包含多处重复的逻辑代码 ###

类似对指针参数判空这种我认为是可以多个步骤重复进行的，但是一个流程里对数据memcpy、clear操作三四次我就无法理解了，完全是降低效率的无用功。

### 5.喜欢用全局变量 ###

项目中不少配置相关的变量是以全部变量的形式存在的，而且没有set/get的接口，这导致一个问题，变量在什么时候修改的也不好控制和追踪。特别是原本的MFC项目还用了大量的定时器刷新和消息回调刷新，调试很不方便。

### 6.异常处理 ###

以前做的项目我都没考虑程序异常时生成dump文件，有些问题在开发机上又没法复现，以后正式的项目需要加上这个功能。

### 7.持续学习 ###

有同事直接在线程里操作UI上的变量，甚至认为DLL上的逻辑是在独立的线程跑的。这让我想起了以前有个同事说Qt的事件循环相当于开了个独立的线程，所以对话框里传文件不用开线程不会阻塞主线程。对我来说可能这些都是基础性的错误，但是很多别人会的基础我也不会，重要的是保持不断地学习。这还有一个问题，就是学习的方向，虽然平时我也爱学习相关知识，但总感觉方向不对。俗话说的好，选择比努力更重要。

### 8.其他 ###

（暂时没想到，等以后再补充）

最后，我想说良好的环境也是非常重要的，大家和睦相处，而不是添堵。这家公司环境不错，大家都很合得来，只是我不适合这份工作。虽然上面我说了一些不足的地方，只是为了警醒我自己以及和大家交流，和同事个体无关。