写在2023年初

Retrospective at the beginning of 2023

回顾2019-2020

这个tech blog始于2019年底,当时应该刚刚入职C公司,还没有太多的工作。后来12月中旬入职G公司就开始忙碌, 也是第一次真正使用Agile和Scrum,属于适应与寻找平衡的阶段。从2019到2020,一共写了5篇博客。

2021-2022

2021年中下旬我入职了H公司,之后就很少碰自己的电脑了。公司电脑是相对封闭的环境,外部网站是白名单机制,而且进出流量 都有监控审核,外加身兼多职,更难寻找平衡。

不过回顾过去这两年,也确实学到了不少新的知识与技术,未来在逐渐找到平衡的时候就可以继续在业余时间跟随自己的路线。

Unit Testing

与以前的工作经历相比,测试方式可能是区别最大的。以前的任何一份工作,都有专职或兼职的测试工程师,程序员只需要保证自己的 代码可以编译通过,可以运行起来就可以丢给测试工程师去测试了。而现在再也不会有测试工程师了,也许有些功能还可以做一些简单 的手工测试,但大部分情况下你修改的功能可能手工测试既费时费力又覆盖不全,比如从一个数据库迁移到另一个数据库这种情况。这 种情况下似乎通过代码的形式写单元测试、集成测试、回归测试是程序员为数不多的主要选择。

写单元测试看起来很简单,常用的测试框架就那几种,测试语句无非就是各种Assert,但真正开始写单元测试往往会遇到各种问 题。比如如何准备测试数据?如何设计/重构代码让代码变得可测试?这些也需要经验与学习。最后测试用例也可以起到说明文档的作 用,比如这个被测试的方法的正常输入与输出示例,异常输入与预期错误类型等。

CI/CD与DevOps

另一个非常大的不同体现在H公司所在团队的CI/CD与DevOps的应用。记得在G公司时,我与另一位同事还在摸索和搭建 CI/CD这套流程。当时我们有Gitlab和Jenkins服务,对部分项目搭建了编译的Pipeline,我用 Docker部署了Nexus,用来存储编译产生的部署包。

直到我来到H公司才了解到CI/CD与DevOps的更多应用。首先在Jenkins中进行编译只是第一步,在编译任务完成后 可以进一步执行所有的单元测试用例,生成测试报告,然后请求代码扫描,检查代码中的漏洞,通过之前的测试结果与Sonar集成 等,最后自动推送部署包、测试报告等结果到Nexus仓库,触发自动部署任务,自动部署到开发或测试环境。同时在 Jenkins上还有定时或自动触发的自动集成测试,可以将部分执行时间较久的测试或依赖外部环境的测试在CI Pipeline执行,异常执行结果自动发邮件通知开发团队。

并且由于开发团队同时兼任运维团队,在开发与设计系统时开发团队会同时考虑运维这个方面。比如日志和运维数据与ELK集成、 通过ELK中的数据生成各种Grafana仪表盘、通过Grafana仪表盘设置各种运维异常状态预警通知等。

在以上方面H公司有太多可以学习和借鉴的地方。

MongoDB

将现有系统从Oracle迁移到MongoDB是我在H公司以来接手的周期最长的一个项目,在这个过程中我有时间进一步学习和 了解MongoDB。记得之前在G公司就接触过MongoDB,做了一些比较简单的开发任务,但现在回忆起来,其实当时的用法 并不是适合MongoDB的。

MongoDB其实已经诞生并投入实际项目运用很久了,10gen公司(MongoDB Inc的前身)从2007年就开始开 发MongoDB,并且在2009年推出了第一个版本。不过相对于传统关系型数据库,MongoDB在各行各业的IT系统中的 应用时间并不算久,很多程序员(包括我自己)也都是在一边学习一边应用的过程中,所以对于什么情况相对适合使用MongoDB 什么情况不那么适合,使用MongoDB做数据库时设计上有哪些不同与注意事项,大家可能也会比较模糊。

根据当前的项目经验,个人觉得以下一些情况更适合应用MongoDB:

  1. 项目团队中有成员具备一定的经验,或者能负担一定的学习成本的时间。MongoDB虽然上手比较简单,但是并不适合完全 以关系型数据库的开发方式来进行开发。MongoDB对多表查询和子查询仍然是一项短板。
  2. 项目需求不够成熟,有较大机率频繁修改数据模型。MongoDB的轻量级Schema能够给开发带来更多灵活性,不同类 型的数据可以存在同一个Collection中。
  3. 项目需要频繁查询与存储结构化数据,在关系型数据库中,结构化数据通常被拆分成很多张表,或者直接保存为XML字符串的 clob,然后通过增加索引列来冗余XML中的值实现查询的方式(我接手的项目就是这种情况)。在MongoDB中,结 构化数据可以直接由多层级嵌套文档来表达,并且每个子文档中的数值都是可查询的。
  4. 项目需要更高的高可用性。MongoDB的集群与投票机制可以提供更方便的高可用性方案。
  5. 项目需要处理一台服务器的磁盘空间不足以存储的数据量或需要将不同区域的数据存放在对应地区的服务器上时, MongoDB的sharding机制可以用来处理这种需求。

Chat-GPT

Chat-GPT是通过同事的分享接触到的,与以往的各种AI助手不同,Chat-GPT对用户提出的问题的准确理解以及连贯 的上下文机制足以让人惊艳。同时基于这种连贯的上下文,用户可以通过对话的方式让Chat-GPT做很多事情,比如让它来写一 段代码,通过连续提出更明确的要求最终得到符合要求的代码。

Chat-GPT一出,很多人都开始感觉到自己被取代的危机。也许程序员不会那么快被取代,但是以Chat-GPT现有的水平 来看,至少做程序员的门槛会降低,未来写代码的能力可能会没有现在那么重要,而怎么通过运用技术来实现业务、创造价值会更加重 要。

规划与展望

最近几年从工作中学到的这些新的技术和工具都是值得独立开发者拥有的,尤其是基于Jenkins的CI/CD的一整套工具。对 与运维工具,如果需要运维个人的云服务或者App,也是可以考虑引入的。

今年对我个人来说,最重要的事情就是完成Oracle到MongoDB的迁移项目,同时也拿到MongoDB的开发者认证证书, 然后再逐渐搭建属于自己的CI/CD工具链。同时也需要继续追求工作与生活的平衡。希望今年能有更多时间来写一些日志博客。