从入职 Bytebase 至今，已然过去一个多月，在这段时间里，感想很多，收获颇深，趁此机会用简单的文笔来简要地记录些许。
还记得报道入职当天的第一件事就是参加产品周会，由于有 3 位远程办公的小伙伴，Bytebase 的周会显得有些特殊，分为了线下场和线上场。在线下场里，7-8 位小伙伴聚在一间小会议室里，用着各自电脑加入同一个视频会议，每人会对上周和这周工作内容进行总结分享。当然，周会当天如果有新伙伴加入的话，第一件事是新人的自我介绍，其中也包含旧人的自我介绍，以此让大家再次熟悉并融入小家庭。开完周会后，就到了经典、美味且不重复的“新人入职聚餐”，那天吃的是附近一家很赞的上海菜馆，由于之前在苏州待了快 1 年，甜口系的上海菜还是轻松拿下。在之后的日子里，又让我体验到了小店氛围的日式鳗鱼饭、新疆菜、米其林星级的云南菜，以及 4 个人都吃不完的小份东北铁锅炖大鹅。（静安周围的美食可太多啦！）总之，过年回家了后，亲戚们都异口同声地说：这孩子又长“好”了！Bytebase 在入职前会为每个小伙伴画一张卡通头像，入职当天还会收到一个来自“文创”公司的新人大礼盒。特别一提的是，公司官网上有每个小伙伴的头像，并且会随机顺序的展示（这次又 roll 到我排第一个啦🤗）。
在工作里会使用到的工具和工作环境氛围一样重要，一个足够优秀且实用的产品会让用户愿意使用它，甚至想要深挖其中的实现细节。好的工具不仅能提高团队的协作效率，耳濡目染下也可以提高我们自身的产品能力。Bytebase 里所使用到的工具，都是在比较市面上主流热门产品后，再有意识地去挑选，最后形成了一个各有特色的工具集，这里拿出其中 2 个作为例子：Linear: The issue tracking tool you'll enjoy using
简约的现代化 UI，优秀的交互逻辑，功能实用性堪比 Jira，使用体验就与其 slogan 所述一致：“you'll enjoy using”。
Balsamiq Wireframes: Life's too short for bad software!
一款非常有特色的产品原型设计工具：原型就应该是原型图，而不是精美的细节设计稿。
首先很有必要地提一句：感谢小米的 MIUI 系统，让我主动地将系统语言切换到了 English。（MIUI 系统特色的内置广告只存在于系统语言为简体中文的情况下，切换至其它语言即可体验无广告系统！）在慢慢适应了手机上的英语环境后，我将电脑操作系统以及经常使用到的软件也换成了英语。在不断地与这些工具里面的专业词汇接触后，发现自己在阅读英文官方文档的能力得到了显著提升。这个技能在 Bytebase 的日常工作中很是实用，由于我们项目是托管在 GitHub 上，其中一些 PR、Issues 都需要用英语进行阅读以及描述，还有项目进度管理所用到的 Linear 也需要一定的英语读写能力。mentors 也会经常性地分享一些英文论坛帖子、技术文章以及新闻，经过长期的英语环境的适应后，阅读这些资料也变得越来越轻松 💪。
Bytebase 会在实习生入职前制定一个专属的实习项目计划，其中我的第一个热身项目是 star history（star-history.com）：一个用于显示 GitHub 项目历史关注星星数的卡通风格的折线图。当 mentor 给我讲解了一遍整个项目的使用背景以及后续功能需求时，由于项目本身是用前端三剑客（HTML、CSS 以及 JavaScript）写的，当时我第一个想法就是：“这得重构吧，不然开发起来有点难受”。最后和 mentors 确认是否需要重构以及使用的技术栈后，就开始了长达一周的重构之旅。入职即重构！在重构后的第一版中，我刻意优化了一些看上去有点“简陋”的样式，再按照自己的想法对页面排版进行了调整，最后因为和原站样式相差太大，被否了。那刻，我并没有立即去修改照搬样式，而是在原站上点来点去，尝试去了解为什么需要这些“简陋”的样式。最后通过 mentor 给的两个网址：https://balsamiq.cloud、https://www.monkeyuser.com 得知了有些产品的风格就是如此，刻意设计为一些复古样式，如果用“扁平化”、“R 角”等现代化设计去处理，反而会让用户造成困扰，适得其反。在还原了老版本的样式细节后，又新增了包括 Timeline 图、切换多个 repo 显示态等在内的多个 features [具体新增功能烦请通过文章 Introducing the new star-history.com（https://star-history.com/blog/introducing-the-new-star-history-com）进行查看] 。新的 star-history.com 也顺利上线 🎉，页面还是原来熟悉的风格，并且功能更加丰富且强大，貌似来自用户们的好评也变多了～
Code Review（CR，代码评审）是保证产品质量的重要手段。在 CR 流程里有两个最常用的术语：LGTM (Looks good to me)、PTAL (Please take another look)，前者对应的是评审人 (reviewer) 通过了评审，后者对应的则是作者 (author) 根据 reviewer 的意见进行完修改后，请求 reviewer 再进行评审。评审的过程就像一个踢皮球的过程，你来我往，直到最后迎来一句 LGTM。在国内，整体对于 Code Review 还不够重视，即使在大厂里，也只有极少的团队会认真地做 CR，也有能力做 CR。在加入 Bytebase 之前，我经常是处于一个人单打独斗地肝完了整个小项目的状态。其过程虽是很充实，但还是很希望有 2 个小要求能得到满足 1) 能和其它人一起开发，2) 也想要有人能对我的代码指指点点，进行一次真正的 Code Review。Bytebase 非常重视 CR，首先会在项目里先通过 code formatter 和 linter 对代码格式进行规范，在 git commit 阶段用 pre-commit 对本地 commit 进行格式校验处理，再通过 GitHub Actions 对整体代码用多个脚本进行质量校验，最后 Reviewer 才会对代码进行审阅，同时就算是代码的 comments，也会因为不合时宜被提出纠正修改。因此，我的两个小要求在 Bytebase 得到了充分且正确的满足。
Bytebase 提供了一个极其扁平、提倡自驱的氛围，除了每周一次的产品周会外，平时能接触到的另一个会议模式就是 “One on One”。每次和小伙伴 One on One 时（应该称为向大佬取经的机会），总能学到一些新的知识点：踩过的坑、方法论、设计原则以及前沿技术等等。其实在日常工作中，也存在着许多 One on One 的场景，比如 mentor 和我之间经常会说到的一句话 “我觉得这里应该 xxxx，原因是 xxxx，你认为呢？”。和 Code Review 类似，想法/意见也应该经过双方讨论，通过打乒乓球的方式，你来我往，进行碰撞，从中迸发一些灵感或思考，直到最后迎来双方的 LGTM。很高兴能够及时加入到 Bytebase 小家庭，也希望自己能够发挥出自己的创造力和想象力，为 Next Generation 的产品添砖加瓦。最后，再分享一个小伙伴给出的一个学习建议：“凡事多问问为什么”。
Bytebase.com 是一款聚焦在团队协作场景下的数据库结构变更和版本管理（database schema change and version control for teams）的开源工具，主要解决研发工程师和 DBA（数据库管理员）在变更数据库结构时的协同问题。