程序员初入职场七个月小结 | 程序员有话说

作者 | 我没有三颗心脏

本文经授权转载自我没有三颗心脏（ID：wmyskxz）

前言：不知不觉已经工作了快 7 个月了，去年这个时候还跻身在考研的大军中，不禁有些感慨… 结合这 7 个月发生的一些事情，简单做一下总结吧…

那时候刚入职

不同于其他同学忙于毕设的 4 月，提早安排趁寒假已经完成毕设的我，已经开始扑在了「找工作」这件事上，有了去年「秋招」打下的基础，复习起来快了很多，没过多久就开始投简历面试了，面试也总体比较顺利，刚面没几家就迅速和一家自己看好的初创公司签下了。

公司使用的技术栈区别于自己熟悉的 Java/ MySQL 这一套，而是主要使用的 Rails/ MongoDB，所以刚入职的一段时间，基本上都是在自己熟悉技术栈，也趁着闲暇的时间，把自己入门时候的一些学习心得写成了文章发表：

• MongoDB【快速入门】：
  http://www.wmyskxz.com/2019/04/25/mongodb-kuai-su-ru-men/
• Java转Ruby【快速入门】：
  http://www.wmyskxz.com/2019/04/26/java-zhuan-ruby-kuai-su-ru-men/

对于职场小白来说，所谓「职场」还是显得有些陌生，刚来的时候，虽然跟周围的同事都稀松平常地打了一圈儿招呼，坐下之后，随着他们又埋头噼里啪啦敲打键盘工作的深入，又顿觉周围一片陌生，还挺奇妙的，在第一周完的周报里面我写道：

刚来公司有些迷茫，只是看着CheckList对照着熟悉一些技术，也不了解自己应该要熟悉到哪种程度，就希望自己能再主动些，不管是技术问题还是其他问题多请教，然后尽快跟其他成员熟悉起来。

刚开始上手的时候也有好多问题不懂，我都习惯性的选择自己研究一阵儿，因为自己有写博客的一些经历，被问过好多一搜索 or 自己一尝试就能解决的问题，所以比较克制，但是后来「入职 1v1」沟通的时候被说到有问题别自己死磕，半个小时没解决尽量就找一下旁边的同事。摁？我一下子就把我的「主动性」发挥了出来。

不过好记性也不如烂笔头，找了一些工具记录把这些「问题的答案」都记录了下来，方便之后再查找，当时对于 Git 都不是很熟悉，也记录了很多常用的命令在里面，还有一些问题的反馈，甚至知道了月会要自我介绍，也打了一遍草稿记录在了这里：（那段时间真的问了好多问题，周报里也手动感谢了坐我旁边的两位大佬..）

入职两周的时候，虽然已经开始上手做一些简单的埋点工作，但自己对于 Ruby 还是不是特别了解和熟悉，趁着某一个双休，抓着一本《Effetive-Ruby》啃了两天，也把自己的学习输出了一下：

• 《Effective-Ruby》读书笔记：

  http://www.wmyskxz.com/2019/05/12/effective-ruby-du-shu-bi-ji/

逐渐能够上手

就这样一边熟悉，一边开始接一些小需求，我记得我写下的第一个 BUG，就报出了 6K 条记录.. 慌慌张张在修复之后我不禁感叹：「不要太相信用户的任何数据」。（包括 equal 反写也是之后在错误之中学习到的..）

刚上手没有一段时间，就接到了一个新项目的需求，跟着一位大佬开发一个新功能，大佬负责搭建基础代码和设计，我负责完成其余的功能代码，没敢一丝懈怠，下班回家之后也对照着别人写的代码敲敲敲，时间和完成度上倒是没有一丝耽搁，只是现在回过头一想，当时没有什么单元测试的概念和意识，就自己在本地 Post-Man 测试完就完，所幸比较简单 + 自己测试得比较仔细，到现在也没有出现过什么问题。

工作对我这样的小白另一个好处就是：「见识和增加技术的广度」。公司所使用技术栈不论是广度还是深度，都是自己在大学本科的学习中不可企及的程度，Jekins？Docker？K8S？跳板机？一下子冒出来好多新鲜陌生的名词，怀着好奇心也尝试了解了一些：

• 了解【Docker】从这里开始：

  http://www.wmyskxz.com/2019/05/29/liao-jie-docker-cong-zhe-li-kai-shi/

• 「消息队列」看过来！：

  http://www.wmyskxz.com/2019/07/16/xiao-xi-dui-lie-kan-guo-lai/

• Kafka【入门】就这一篇！：

  http://www.wmyskxz.com/2019/07/17/kafka-ru-men-jiu-zhe-yi-pian/

也随着公司的逐渐壮大，各模块的耦合也越发严重，各条业务线之间的协作沟通成本越来越大，逐渐开始提出「微服务」这样的概念，具体怎么样理解就不作讨论了，总之就是期望通过梳理/ 重构/ 拆服务的方式来解决「协作」问题，所以期间也开始了解学习一些这方面的东西：

• 什么是微服务？：

  http://www.wmyskxz.com/2019/06/07/shi-me-shi-wei-fu-wu/

• 《重构：改善既有代码的设计》读书笔记：

  http://www.wmyskxz.com/2019/06/08/chong-gou-gai-shan-ji-you-dai-ma-de-she-ji-du-shu-bi-ji/

甚至期间还做了一些「微服务」的调研，我们选用什么样的姿势和技术栈更加合适，所以也输出了一些关于「Spring Cloud」的东西，但是最终驳回的原因是待我们整个容器化之后 k8s 平台自带了这么一套东西，业务同学只需要关心业务代码就行了，也就没有继续深入了：

• 你想了解的「Spring Cloud」都在这里：

  http://www.wmyskxz.com/2019/06/09/ni-xiang-liao-jie-de-springcloud-du-zai-zhe-li/

然后我们在拆解的过程中，也借鉴到一些「DDD」的思想，也尝试进行了一波学习：

• 【吐血推荐】领域驱动设计学习输出：

  http://www.wmyskxz.com/2019/06/13/tu-xie-tui-jian-ling-yu-qu-dong-she-ji-xue-xi-shu-chu/

总之，这一段时间我一边通过各种小需求，接触和了解了公司的系统的大半，一边学习和了解着各种不同的技术，增加了技术上的广度。

开始负责一些项目

为了加速服务化的推进工作和验证「DDD」的一些东西，部门老大把一个边界足够清晰，也足够小的一个模块单独交给我，期望我快速上线，不过最终交付已经逾期快大半个月了.. 虽然从最终的结果来看，顺利交付完成了拆解任务并从 MongoDB 数据库转变成了 MySQL.. 但期间也踩过好些坑，当然也学习到一些东西..

例如我真实地意识到「完美」这个词的理想化。就拿设计 API 来说吧.. 自己就基于 RESTful 风格设计了好几版.. 左想右想都觉得差一些，有一些接口觉得怎么设计都不优雅.. 后来纠结一阵子也就放弃了.. 再例如写代码这件事情吧，好的代码整洁的代码是一次一次迭代和重构中出来的，如果一开始就想着写出「完美」的代码，那么最终的结果可能就是写不出来代码。

另外一个小插曲是，在做数据迁移的时候，我差点把线上服务器搞挂了.. 我在测试环境验证了一把之后，就直接在线上进行操作了，因为当时对于数据库的操作管控还没有那么严格，加上自己对于线上环境的复杂程度认识不足，我就起了 50 个线程，去分批量地读取 MongoDB 的数据迁移到 MySQL，造成了线上库的性能报警，就赶紧停了.. 紧接着就被一群大佬抓进了一个会议室做事件的复盘..

说实话，我紧张坏了，第一次经历这样的算是「事故」的情况吧，差一点线上就被我搞挂啦，一时间不知所措… 让人感到温暖的是部门老大随即丢来的消息：

那天还有一些相关的同事都陪我写复盘邮件到了晚上 10：30，现在想来都十分感谢他们。后来回到家我还打电话给我妈，我说我在工作中犯错了，我做了xxxx这些动作，你觉得我做的怎么样呢，老妈的回复也让人安心，只是现在想来，一些后续的动作可以做得更好的…

因为「埋点」这件事涉及到系统的方方面面，我也借此了解了很多不同的模块，也是拜这一点所赐吧，后来我被派到各种各样的支援任务中，同样也因为对不同模块都还不算陌生，都还算完成得不错吧…

时间一晃，在公司就四个月过去了，也在这个过程中从各个大佬那儿都学到了一些东西，在 8 月底发的周报里面我写下了以下的总结：

之后也跟着大佬碰了一些公司的核心模块，期间也没有停止在工作中不断地做学习输出：

• Git 原理入门解析：

  http://www.wmyskxz.com/2019/08/16/git-yuan-li-ru-men-jian-xi/

• Java计时新姿势√：

  http://www.wmyskxz.com/2019/07/30/java-ji-shi-xin-zi-shi/

• Java8流操作-基本使用&性能测试：

  http://www.wmyskxz.com/2019/08/03/java8-liu-cao-zuo-ji-ben-shi-yong-xing-neng-ce-shi/

• 《代码整洁之道》读书笔记：

  http://www.wmyskxz.com/2019/09/14/dai-ma-zheng-ji-zhi-dao-du-shu-bi-ji/

• React 入门学习：

  http://www.wmyskxz.com/2019/10/15/react-ru-men-xue-xi/

• 谈一谈依赖倒置原则：

  http://www.wmyskxz.com/2019/11/18/tan-yi-tan-yi-lai-dao-zhi-yuan-ze/

回顾做的不好的部分

• 对代码还没有保持足够的敬畏之心。

特别是一开始上手的时候，有时候甚至是在线上环境搞测试，后来越来越注重 codereview 和单元测试好了很多。

• 沟通还不够深入/ 到位

有一次是临时接到一个需求，因为「通用语言」没有达成一致，导致最终交付的结果不符合产品的期望，最终我们所有相关人员在一起开了一个会，统一了「通用语言」，造成了额外的工作和负担，拿到需求就应该确认好相关事宜的，越底层越细节越好，这方面的能力我仍然欠缺，但我已经持续在注意当中。

另一次也是因为这一点，我需要帮助 A 系统拥有某一项功能，之前 A 系统已经介入了 B 系统完成了部分功能，我因为没有进一步地确认 B 系统的现状，就去接入了有完整功能的 C 系统，但其实 B 系统已经在上一周和开发 C 系统和 A 系统的同学对接好了，并完成了相关功能的接入，少了这一部分的沟通，就造成了不少额外的工作量.. 所以「沟通」还是非常重要的，也只能说持续进步吧…

• 缺少一些主动性

当我头上挂着一些事情的时候，还是能够保持着效率的，只是当我做完了，就时常缺乏一些主动地思考了，通常都是被动地去询问同小组的同事有什么事情是需要帮忙的.. 虽然也积极地参与到自己感兴趣的那些技术评审之类的事情之中，但似乎效果都不佳.. 也没有什么实际好的输出..

• 接了一些私活儿黑活儿（没有充分考虑团队之间的配合）

因为「埋点」会接触各个平台的童鞋，并且时常变化和有一些新的需求，有时候直接绕过了一些环节，直接找上我了，我心想直接自己弄弄改改就可以了，也就没多想… 但是现在想来，这样跨团队的事情，不能越过「顶头上司」私自进行，一方面经常我的 BOSS 不知道我接了活儿，另一方面这样的私自对接就会造成一些信息的流失，对于团队之内还是团队之间都会造成影响…

回顾做得好的部分

• 养成了阅读的习惯

公司买书是免费的，也有自己的图书馆，同事也不乏喜欢阅读学习的，所以跟着跟着就养成了阅读的习惯，期间也学习到了一些方法论的东西，贴一下入职以来读过的那些书吧：（技术类的就没有囊括了）

其实每天阅读的时间也不长，想我大学总共捧起的那么些课外书，不禁有些唏嘘…

• 早睡早起 + 晨间日记

早睡早起，从步入职场以来，就发现这样的习惯会带来一些额外的价值，例如一些阅读我会放在早上，后来还加入了「晨间日记」，用来「回顾前一天的事情」和提前部署「今天的任务」，这不禁让我多了一份清醒，也让现在不怎么锻炼的我每一天精力更加好一些：（目前正在从印象笔记往 Notion 逐步迁移的过程中）

• 学习撰写 Commit Message && 遵守一些 Git 规范

起初使用 Git 十分不规范，后来向大佬那儿学习到了如何标准地提交 Commit，包括 Commit Message 应该怎么写，我觉得这是一个很好的习惯，每一个 Commit 都有上下文，并且还带上了 JIRA 号，任务也很好跟踪，虽然公司并没有大范围地盛行起来，但我觉得这样好习惯应该坚持下来：

• 任务进度及时反馈给相关人员

自己比较注意这一点，因为不这样做会让别人感受不怎么好.. 光是自己心里清楚是不行的.. 要保持信息的通畅才行，及时反馈是很重要的一步..

• 自己先 review 一遍代码

犯过一些白痴错误之后，就有些担心，逐步养成了自己先 review 一遍代码的习惯..

小结 && 展望

总的来说，看着自己这样一步一步成长过来，没有很懈怠，自己就算比较满意了，在工作中学习了很多东西，不管是技术上的硬技能，还是沟通中的软技能，也认识到了很多厉害的大佬和有趣的小伙伴们..

感恩在路上相遇，有幸共同行走过一段已然算是幸运，突然翻看起自己的朋友圈有一句话说得好：「成长从来都不是告别过去，成长是更加坚定的看向未来！」

期待一路同行的大家，都能够 Be Better！

声明：本文为作者投稿，版权归作者个人所有。

 热 文 推 荐 ☞全球 43 亿 IPv4 地址宣告耗尽！

你点的每个“在看”，我都认真当成了喜欢