本文主要是介绍浮躁过后的一点总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
从七月开始，心情慢慢地变得很浮躁，很想换一个环境。主要的原因是对目前工作的现状感到很失望，觉得再这样下去根本不是个头。先说说目前的工作现状吧：
本来我的工作岗位是助理开发工程师，虽说是开发工程师，但是自从入职的第一天开始就很少接到系统开发的任务，都是系统运维为的内容。第一次为公司的项目编写代码大概是在做了两个多月的业务测试和运维之后，当时有一个小需求是要对一个入参数值进行规范化限制，当时对正则表达式不了解，请教之后别人告诉我说用正则表达式，于是查询了一下还真找到了一个符合要求的正则表达式，然后就写在了报文验证的总入口处，效果异常地好。其实代码就几行，当时验证完毕之后完全没有问题，觉得很开心。但是到后来的几个月都没有开发的任务分配下来。每天都是运维，处理各种错单。
说到这个日常运维我就要好好的吐个槽。由于我们做的是电信行业的支撑系统，每天全国各地的订单都会汇集到这个系统中来，如果没有一个性能完善优良的支撑系统，每天的错单量会把人给折磨疯。之前的系统就不说了，自从全年九月份开始，我们接到电信的一个新项目。从九月份开始从之前各个组中抽调个人相关人员来开发这个新项目。我被抽调过去开发一个接口的开发。说的是新系统的开发，其实就是讲之前系统的代码原封不动的搬过来，然后在此基础上修修改改。我不知道这个系统所采用的框架是什么时候搭建的，反正我只知道已经很长时间了。。。。。。这个代码从最初创建开始，已经经历了很多人的添砖加瓦，估计只有最初创建的人才知道每个包，每个类的规划，后来的人都是在有新需求的时候找地方塞代码，只要功能能实现，且当时没问题就行了，根本没有大局观。而且很多代码都是业余人员写的，都是简单粗暴式的把代码堆在一起。
当时我们那个组分配了三个人，其中一个人担任组长（姑且叫A），A个人能力还是很不错的。我刚入职的时候负责人就是将我分配在现在A的手下。A这个人在我们组里面算得上是中流砥柱，只要是涉及到本组内的事情，基本上他都知道。他人很好相处，不耍心机，只要有什么问题问他，他只要知道都会告诉对方。平时为人也很大方。但是有时候我很不理解他做事的风格。他身为一个组长，但在平时的开发任务中，他都是把事情揽在自己手上，不向下面的人分发。之前在开发新系统的时候，每次没给我的都是些很简单的任务，基本上写两三行代码就能解决，但是他给我的时间却很宽泛，每次我完成了告诉他的时候，他都会口头赞赏我两句。那时候我看到他很忙，就跟他说有什么我可以分担的可以分配给我，但是每次都是一下简单的事情。后来我总结，A是一个很会工作的人，但不擅长管理和分配，只要是自己能完成的就绝不麻烦他人。
当时我觉得我是刚入职新手，三个人中应该就我最弱。但是过了一段时间之后，我发现另一个人（简称B）完全没有开发能力，甚至连基本的代码都看不懂。我们用的开发工具也是我手把手教会的。分配给他的开发任务开始基本上都是我手把手教他完成的，后来我实在是不想教了，就找了个理由没有再教了。没成想，这位老兄在项目组的人缘不错，愣是在其他组找了个外援来手把手的教他写业务逻辑。后来通过平时的聊天才知道，原来B之前根本没有学过开发，也没有做过开发，我甚至不知道他是怎么被招进来的，也不知道B在项目组的工作职责是什么，平时都在做些什么。接触时间长了发下B大部分时间都是在聊天逛网站。（在项目组待的时间长了之后才知道，原来大部分人日常的工作内容都是这样）
整个项目的开发持续了半年多。在刚刚开发了大约一个月左右吧，我发现系统暴露出很多问题。结合上一个系统的运维经验，我发现我们组所做的接口这块因为主要是对外开放的，所以对外围验证的第一层就在我们组的模块。我们是边开发边跟外围联调测试，测试的过程中暴露出我们接口的很多bug，在修复bug的过程中会不断有新的问题出现，最主要的就是我们接口对异常的处理非常糟糕，很多异常采用同样的捕捉方法。这样就导致每次外围系统看到报错信息根本不知道是什么类型的原因。他们把异常信息发给我们开发人员，可笑的是我们大部分人员也不知道原因具体出现在哪个地方，每次有错误信息抛出来，几乎每个开发人员都采用同样的处理方式——debug一遍代码。结合之前的运维经验，我意识到这种情况会给将来的运维工作带来巨大的困难，和繁重的工作量（因为将来的运维工作也是我们这些人来做）。有一天，我忍不住提了一个自认为非常有建设性的意见：我们的开发人员在做每一个接口的时候一定要自定义异常编码，异常信息，以及对异常的处理方式，提别是要描述清楚具体的错误信息，以及出现错误的场景。万万没想到的是，我的想法提出来之后不但没有得到组长A和开发成员B的认可，反倒被他们斥责了一顿。当时我想力争一下，但是我这个新人实在是在气势上压不过他们，最后只要妥协了。他们给出的理由任务重，时间紧。组长A这样持这样的观点我还是可以理解的，毕竟开发的大任务在他手上；但是成员B持这个观点我就想不通了。首先，分给他的都是很简单的任务，再者，他的开发基本上都不是他自己的做的，他对我的建议有什么发言权。后来想想觉得，负责人都不上心这个问题，我操什么心！举一个B平时工作的例子吧：有一次有多个人在群里面讨论问题，B也在里面跟另外一个人说问题，我当时觉得这么多人在一个群里面你一句我一句的说，很乱，而且期间很容易获取到错误信息，我就问B为什么不单聊，B的回答是：单聊怎么体现工作量。当时听到这句话之后，我对B的认识发生了极大的转变。
回到目前的运维话题上吧。运维的事情做的时间长了之后，慢慢地就感到很烦躁。每天都是处理类似的问题。错单量小还好，有时候都是大批量的错单，而且错误的类型都是反复出现的。也没有谁说定位一下问题的原因，对程序进行修改。天天被别人催着处理错单，真是烦透了。终于有一天忍不住了在网上更新了简历。没过多久就有其他公司的面试邀请。上个月中上旬，我参加了一个同行业公司的面试，当时觉得面试可能不会通过（周一面试的，到周四还没有消息）。但是到了周五，该公司给我发了offer，薪资待遇跟我之前要求的基本一致。但是经过一个周末的思考，我拒绝了这家公司的邀请。因为经过一个星期的思想沉淀，浮躁的心情慢慢冷却了。经过一番思考之后觉得，目前还不是最好的跳槽时机，原因有以下几点：薪资待遇方面和现在所在的公司相比没有提升；工作的环境可能没有现在的安逸；刚参加工作一年多，这么快就跳槽显得忠诚度不够。作出这个决定让我失去了一个可能会得到更好锻炼的机会，毕竟我还是一个职场新手，从事IT行业最需要的就是开发经验的积累，而在目前的环境中几乎没有实战锻炼的机会，只能靠平时自己的自觉学习。
其实我很早就行写这篇总结性的文章了，但是由于自己的惰性习惯，一致没有实际的行动。触发我今天写这篇总结的是前天晚上加班期间在importNew上看到的一篇文章。那篇文章写得是一个开发工程师在github如何坚持连击177天——坚持177天不间断地在github上提交更新。他的行动激发了我的一个想法：在csdn上连击——坚持每天在csdn上写一篇文章，文章的内容不做具体的限制，可以是学习心得，可以是工作总结，唯一的要求是文章的内容不能是为了不让连击断掉而复制粘贴的内容或者是毫无意义的内容。看看这个行动能够坚持多长时间。所以今天是我实施这个行动的第一天，这篇文章也是我这个行动的开篇。
这篇关于浮躁过后的一点总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
