老兵的十年职场之路(二)

最新推荐文章于 2022-09-07 15:33:44 发布

A_F_O

最新推荐文章于 2022-09-07 15:33:44 发布

阅读量10

点赞数

本文链接：https://blog.csdn.net/zhy_Learn/article/details/133078276

版权

在上一篇文章老兵的十年职场之路(一) 里头，讲述了我在初入职场时的一些经历，从自己个人的感受来说并不是特别的美好，既没有职位上的屌丝逆袭、也没有令人兴奋的意外成长，但也许这也是很多人所经历过的，毕竟我们都是"平凡"的人，一旦平凡就只能是"抱着不平凡的梦中度过这平凡的一生"...

那么，在接下来的这段职业中，我又经历了什么？相比第一段经历，会有什么样的波澜起伏？下面让我一一道来...

第二家公司，是慕名而去的，之所以这么说，主要还是平时里头同事聊天时听来的。

那时候的微博、微信都还在襁褓之中，我们所能获取信息的手段其实很有限，除了百度和上目标企业的官网上看看介绍之外，更多的就是街头巷闻。

当然，这家企业在移动互联网领域的扩张非常快，连我原来公司的老板都会拿来给我们当做学习的榜样...
真是不错，直到后面离职时我也毫不避讳的告知了他我的选择，然后是除了祝福的话之外，恍惚中仿佛看到了一丝黯淡。

别具一格的面试

记得是在清明节过两天之后，我第一次去到新公司面试，除了前台MM很热情之外，还有就是对那办公室布满的公仔和亮堂的灯光令我印象深刻。

相比之前所在的死气沉沉的写字楼，感官上的差异非常的大。

面试我的是一个穿着沙滩花裤的"年轻人“，一上来也没有问我什么，更多的是唠一些工作经历。

中间我觉得无趣，多问了一句：听说这里牛人很多，是真的吗？

他笑了笑，故作镇静的说道：我们都是"普通"人而已...

冷场十秒钟后，又唠了一些兴趣爱好，然后是聊到陈奕迅的歌，我随兴唱了一小段之后，大家都满意的结束了面试。

之后，我一直觉得比较忐忑，这样的面试是不是不大合适？但最终反正是通过了(花裤男是那部门的老大)，后来给我的体会就是有些事情不能老按常理去揣测。

新气象

入职之后，自然是很多新气象，有许多东西都是第一次接触，由于我的求知欲盖过了压力，所以那段时光只是一味感觉到轻松且愉快的。

成长期的互联网公司充满了开放和创新的气氛，这话不假。也就是到了这里才知道原来除了Java 和 ssh 三大框架之外，还有那么多人在使用其他的编程技术比如 Php 的 Lamp，Python 等等，数据库除了Oracle 之外，还有那么多人在用 MySQL.Memcache 这些开源的数据库中间件，而之前还曾天真的认为数据库是 Oracle 等商业数据库的天下，MySQL 只是学生才用的玩意，真觉得自己像个井底之蛙。

所有的这些现象大概已经告示了公司的技术流派：拥抱开源！

没错，一切都是用的开源技术，这也包括了部门在使用的各种协同系统，基本上都是免费的开源系统搭建出来的，所以长的千奇百怪的不足为奇。

但是开源协同系统的弊端也很明显，除了长的丑之外，bug 也很多，要修复就得吃透整个项目的源码，后来管事的觉得这样下去不是办法，于是启动了一个的内部协同系统项目(基于Java开发)，希望把这些千奇百怪的开源系统给替换了。

这里为什么会提到新协同系统？因为当时我一开始是参与了这个项目的，但只是由于项目比较乏味，基本上就是用的 ssh 那一套，于是我很快就申请转岗去干了别的…

编程语言之争

前面提到编程语言的多样性，的确，互联网项目习惯于野蛮式的生长，基本上也都是用自己最熟悉的。于是在项目变多了以后这却成了一件棘手的事情，比如：

人力资源难以调动，比如让做 php 的去写c++不合适
代码质量参差不齐，一种语言就需要一套规范，而有些语言也很难找到规范
新人培养上成本太高，甚至很多人并不是很想尝试太多新的东西

于是乎，就有了各种关于编程语言的讨论，到底要采用哪个作为主流的技术，当时在内部社群也争论的很激烈，貌似最后也是没什么结果(编程语言之争一直就没停歇过)，到后来从项目技术的覆盖面上看，Java 是占了绝大优势的。

我一开始所在的小组大多是 Java 技术老鸟，老丁是队里的老专家，在每次代码评审后也总会这么说：

"这点代码怎么会写不好阿，Java 简单阿，无非就是些增删改查嘛！"

从当时的项目看也的确如此，对于协同系统更多的就是理解好业务流程，定义好实体类，然后一通增删改查…然后是过了一年后，我从内心里就完全推翻了这个想法。

修罗战场

因为对手头上工作没有半点兴趣，没过多久后我就申请到了一个新部门，主要做社区类的平台产品，而后者是就是所谓的自负盈亏部门，这里除了程序员之外，还有产品经理，运营妹子，运维大汉…传说中的鄙视链现象也时不时在这里出现，只是程序员和产品的关系似乎没那么糟糕，这可能跟产品团队都是妹子有极大关系，现在想想当时的人力资源团队还是很有智慧的。

在新项目中，我遇到了许多未曾遇到的挑战，也就是在这里个人的技术视野和能力都快速的提升了。所谓屁股决定脑袋不是没有道理的，当你做的事情让你感到自己像个小白时，你才能拥有巨大的提升空间。

项目的挑战

社区平台是一套的 Php 代码实现的，一开始呢功能很简单，但经过一年半的演进已经变得臃肿不堪。而随着运营同学的努力，用户量也达到了几千万，整个系统开发维护效率极为低下，很容易动一发则牵动全身。另外一旦到了业务高峰期总会时不时的出现一些性能问题。

好了，这是系统的背景，接下来的事情就是重构！把一个庞然大物变成许多只小飞象！

这里听着有点像是服务拆分的意思，但那会没有微服务的概念，就是做成分布式系统，一些原则和理念跟现在的微服务理念也基本是一样的，诸如服务发现隔离，业务降级，关注性能...

当时技术选型方面用的是Java ，Web 通信框架则是由开源项目改造而来的，底层是封装了Netty 用来实现 NIO高性能吞吐，然后是基于业务的特性实现了一套应用层的分库分表框架，这主要是用来支持 MySQL 的水平扩展。除此之外，为进一步提高性能，框架也集成了开箱即用的缓存能力(对接Redis集群)，这样的配合基本上已经做到极致了，于是后来这套技术组合也逐渐统一了大大小小的项目。

由于Java 掌握能力上的优势以及自身的求知欲，我很快就把这套框架的源码给摸透了，当然这些实现并没有包括之前用的 ssh 框架，这是一个非常轻量级的开发栈，风格上更像是Ruby on rails。里面抛弃了许多 J2EE 的东西，对 Restful 的支持非常好，而且在当时Restful也是许多大平台的首选，比如新浪微博开放接口...总之用起来是非常清爽的。

然后说因为对技术框架比较熟练，于是会经常帮同事解决一些问题，慢慢的就成了项目骨干。再后来就是陆陆续续负责一些核心业务的开发，重大问题攻关以及做一些框架规范化管理类的东西。

这里说到规范，不得不提关于代码注释的事情，团队在注释的要求上是非常严格的。大家基本上都认同的一点是：

"自解释代码根本不存在！所以不要因为觉得代码写的好就可以不写注释！"

超哥是同事里的老专家，写了十多年代码仍然能坚持把注释做到极致的清晰，足见对于工作严谨的态度。

影响深刻的事情

在一段快速成长的经历里面，必然会有那么几个时刻，让人始终记忆犹新。

A. 怎么样都写不好的文档

有一次主管让我为一个自动化框架编写一个用户手册，我不以，花了一上午加一个小时给整好了。发到工作群里后被一阵痛批：

“这是给别人看到还是你自己看的？“

“Api请求头说明到哪去啦？“

“把全部错误码放到一个表格不好吗？“

...

也就是从那件事之后，我开始认真对待我的每一篇文档博客，直到有一天，某位大师跟我讲：

“嘿，我觉得你小伙子不错！”

“为啥？“

“因为我看过你的文章！“

B. 突如其来的救火

有一次系统上线了一个紧急补丁，结果由于并发性能问题直接导致系统局部宕机，我在快速攻关后定位到了根因。在问题重现到代码修复足足花费了两个小时。这时已经超过了维护时间窗口，如果再进行测试时间将导致问题出现一再延迟，更严重单事情就是用户流失。

记得那会大家都非常焦急的时候，一直很平静的主管突然对我吼了一句："能不能保证质量！"他的音量很大以至于周围的人都惊诧了，然后是我硬着头皮说 "能..."(当时也只好这么说...)于是在没有测试的情况下有惊无险的上线了新补丁。“工作就是打仗，互联网行业里用户为王，用户就是上帝”这是我所得到的体会。

C. 群猿的通宵夜

一次平台的重大升级变更中，我们团队和运维的大汉兄弟们进行了紧密的协作。因为版本变更太大属于架构级别的变化，所以大家都是不敢懈怠的，运维和开发的两两配对，每一步的操作都要另一个人二次确认。尽管如此，期间还是问题不断，比如脏缓存问题，dns出错等等，整个变更和保障花了整48小时，吃睡也都在小黑屋..可以想象当时空气中弥漫的那种宿醉的异味。当然这些异味不是重点，而是，在完成升级之后的凌晨，产品经理和运营经理都来找我们质问，"为什么系统中断了半个小时，不是说好平滑的吗..."你所认为的很值得骄傲的事情，在别人看来可能不屑一提，因为大家的想要的东西并不一样。