2021 年 10 月 30 日 17 时 42 分，我签下了交接证明和离职证明，为我在深圳市阿铺科技有限公司 690 天的工作画上了句号。
如今距离离职已经两月有余，今日为这段经历做一个注脚。
工作经历总结
入职阿铺的时候差不多处于技术的一个转折点，按照腾飞的开发人员Level体系，大约处于 L2 到 L3 的交界处，语言方面熟练 CRUD ，读过《CLR via C#》，做过一些 IL 方面和软件逆向的研究，有过一些比较业务层的开源代码贡献，熟悉各种常见的框架和工具的使用。
入职后领导对我颇为器重。
在技术方面，我在框架设计方面有了很大话语权，同时得益于领导对新技术的拥抱，得以主导引入各种开源框架和辅助工具，到我离职的时候，已经建成了代码规范明确、GitFlow清晰、DevOps便捷的整套开发体系。这期间我对 .NET Core 的源码有了一定的研究，DevOps 落地经验丰富，云原生方面的技术栈也有了一点实践，在这接近两年的时间，技术能力大约进阶到了L3和L4的交界处。
管理方面，2020 年 8 月被派遣驻扎在深圳主持深圳的招聘和项目开发工作，手下有六人的开发小团队，并于 2021 年 2 月 25日被任命为“增长项目组负责人”，统筹组织增长类项目的开发。
2021 年 10 月底因为各种原因，最终选择离开阿铺科技。这接近两年的时间，很感激公司和作哥的信任，让我在完成了公司各项任务的同时也获得了个人能力长足进步。
技术框架总结
现状
阿铺使用的后端框架采用的是一套吸取了部分 DDD 思想的精简架构模型，，包含代码规范、框架和各种工具等已经封装为基础库，开箱即用，同时采用了开源项目管理常用的主维护人员 commit 贡献者 PR 的方式来维护。
部署发布方面使用 GitLab 构建了一套颇为清真的、Git 驱动的 DevOps 体系，结合 GitFlow 管理，做到各个环境的自动化发布和部署。后期已经尝试在测试环境引入 Kubernetes ，完美整合到了之前一直使用的流程中。
待解决的问题
数据库版本管理
整套发布流程和 Git 整合到一起后，程序二进制文件可以方便的回到之前的某个提交版本，但是数据库版本却没有这种能力，而且介于数据的重要性，也很难信任自动化的操作，我的想法是倾向于严格审核 EFCore 的数据迁移操作的前提下，把数据库版本管理直接也和迁移代码的版本绑定在一起，通过迁移直接管理数据库版本。
Kubernetes
如何基于 Kubernetes 来发布程序其实早已实践成功，但是由于业务量不大，程序属于单体架构并未拆分微服务，基础设施需要的服务器暂时没办法满足等原因，一直没能将其运用到正式服务。
现状是正式服还是原始的 dotnet publish 发布加上 nginx 提供反向代理和负载均衡能力，测试服却已经精进到了直接发布到 Kubernetes。步子不适合一步迈得太大，考虑先把正式服上 Docker，然后再迁移到 Kubernetes。
灰度环境
待解决的问题首先就是一直在考虑增加的灰度环境，对于到底是基于数据脱敏构建的仿真灰度环境，还是基于 A/B 测试的功能灰度环境到最后也没能决定到底选用哪一个，前者就是相当于多了一个仿真环境，数据为正式服务数据的脱敏数据。后者则是在功能上直接对不同用户开放不同版本的功能。
代码风格统一问题
拟使用 EditorConfig 解决。
