在奥密克戎的蹂躏下，赶在 2022 尾巴记录几笔想法
AI
“AI-Powered” 生产力工具真的来了，这一年英语交流及写文字时深度使用 Grammarly 和 DeepL，写代码时约 50% 时间会开 GitHub Copilot；AI 已经渗透到表达思想及建造物件这些领域了，并且做得非常好。个人对 Copilot 的观点更是经历了大转弯，以至于现在很庆幸还有一个 free subscription；虽说 IntelliJ 的各种花式代码补全已快形成肌肉记忆了，但 Copilot 带来的提效是跳出工具层面的：IntelliJ 提供给开发者“非线性”的生产力提升，但 Copilot 某种意义上是在创造生产力，比如最近用一些不熟悉的 PL 来刷 Advent Of Code，靠着 Copilot 有学编程的感受。
最近 ChatGPT 持续霸屏，在开发者圈子也有不少让人眼前一亮的场景，比如这个推文、用 ChatGPT 协助解释代码报错、并对比 Google 文本搜索的效果的。很多程序员都熟悉技术问题排查这个场景：用 Google 搜错误堆栈，然后跳 StackOverflow 等内容站点、再尝试从噪声非常多的内容里提取结论信息。一些大公司的有内部特色的技术栈及代码资产，这种技术问题排查分析更是困难。同 Copilot 一样，ChatGPT 在这种特定问题域下的结构化分析能力，同样将会是颠覆式的。估计未来企业内部的很多支撑系统，都会结合类似 AI 赋能的指令式 Bot，各种散装的 Dashboard / Portal 套娃造轮子终于要到头了。
其他的开发者调戏 ChatGPT 的路数，比如这个文章 Building A Virtual Machine inside ChatGPT；有点细思恐极的感觉。
IDE
原本期待 JetBrains Fleet 能成为下一个扛旗的多语言通用编辑器（Polyglot Editor），目前看离 VS Code 距离尚远。Fleet 强调的几点竞争优势都还未打开局面，比如分布式架构（distributed IDE architecture）所期提供的远程开发及协同编辑能力、远没有成为开发者主流使用场景。插件体系和生态还处于起步阶段，Smart Mode 无法取代各 PL 对应的专业级 IDE，吸引用户的产品卖点估计还需打磨一阵。新的编程界面（a reimagined UI）带来的体验上的吸引力不足以让用户替换掉现有工具；不仅仅是 Fleet，IntelliJ-based IDEs 也在尝试革新 UI、这一过程有着非常漫长的用户牵引工作（见 Addressing the New UI Comments）
IntelliJ Platform 还在持续为 JetBrains 贡献价值，除了几个 IDE 现金牛产品，DataGrip / DataSpell 在数据领域的用户盘子越来越大；基于 IntelliJ Platform 孵化了 Qodana 及 Aqua 等新生代产品，一个是把 Code IntelliSense 沉淀为 CI 及 Cloud 能力，另一个是面向自动化测试领域开疆辟土。除了产品上新，也有产品下线的故事（见 AppCode），引发了用户在评论区的非常多不舍及不满。最后不得不提的是 JetBrains Gateway，2022 这一年从年初官宣跟 Gitpod 合作伊始，目前支持 Gateway 的 Cloud Vendor 基本上都到齐了。可见一个优秀的平台（Platform）不仅是企业创新时稳固的大后方，也能提供足够的试错机会（比如 JetBrains 基于 Projector / CWM / GW 的相继尝试）
Kubernetes
在搬砖电脑上跑了下这个 awk script 以查看一年来高频使用的命令，除了
git/ls/cd/vi这些，用得多的还有j(autojump) 和rg(ripgrep)，然后就是k(kubectl alias) 了；可见被 k8s 摩擦了不少
围绕 k8s 有很多漂亮的比喻，在技术布道上非常有煽动力；比如「云时代操作系统」这一表述、从 存储 / 计算 / 网络 角度同单机 OS 类比；希望灌输给开发者的观点即：云能很好满足弹性算力 / 容灾等工业级互联网应用的架构诉求，这些能力被「云」这个黑箱遮蔽、开发者聚焦业务逻辑即可。
当然业务应用的系统架构及部署运维等各方面也要做出适配（云原生化）；但相比之下、每次新的技术概念涌现，更多却是一场基础设施及平台支撑团队的狂欢，都在积极拥抱之以点缀门庭（或是甩掉债务缠身的老旧轮子）。k8s 在这点上也很好地提供了子弹——其来自于生态及社区背书的「既成事实的 PaaS 基座」定位、让大小厂的内部基建或多或少都在改造（没几个测试或生产 k8s 集群都不好意思出门）；对业务研发或工具支撑团队来讲，k8s 的确帮助实现了 “make infra boring”.
在研发效能领域的各种平台建设上，拥抱 k8s 基本能发挥其 “platform for platform” 的优势，加速很多散装轮子的快速投产。如以下很多研效系统的通用能力诉求：
- 应用模型：每做一个研效系统，起手式往往先对 项目
Project/ 应用App建模、接下来扩展代码服务域的属性（如 GitRepo）和各类 PaaS 系统的元数据（如部署单元 / 环境标）；k8s 生态内可参考 OAM 模型定义及一系列 IaC 解决方案 - 调度编排 & 资源创销：CI / 构建部署 / 测试平台 / Cloud IDE 等都要自研一套调度系统，然后逐步要支持复杂编排能力，比如亲和性 / 拓扑依赖指定等；这些是 k8s 已解决完美的命题
- 任务批处理：除资源利用率及吞吐率，比较关注的是任务执行的一致性，如制品构建 / 代码扫描 / 自动化测试 / 索引计算的稳定性；比如应用 A 依赖
Jre(11) + BuildTool(xyz)在没有镜像化时，解决不同任务间的环境状态问题非常困难；此外要考虑分组并发执行、缓存复用等问题 - 配置管理：开发 / 测试 / 生产等多环境下应用的配置管理、配置变更部署等
- 命令管道：有时候需要进入到 CI / Stable 环境实例里执行一些 ad-hoc command、或提供一个 Cloud Shell 给到用户对服务做一些原地变更或现场排查。这条 Tunnel 也是内部安全攻防时蓝军的最爱
以这一年全新起步的 Cloud IDE 底座建设上来举例，k8s 带来的价值点：
- 研发过程中的存储计算实体，以 k8s workload 形态存在，依赖 k8s 管控面实现成熟的编排调度能力；并且降低独占式的资源使用（如为每个用户分配一个高配虚拟机）带来的巨大浪费
- 研发环境代码化：将变（如用户的 Code / Index cache 等）同不变（如 Workspace spec）的部分分离，实现环境标准化、环境基线治理
- 资源隔离：如各种研发组件（如语言服务器、构建工具链）可分离在独立容器、确保更细粒度资源隔离，避免如 Build 活动阻塞 WebIDE 响应
这种可编排、声明式的云研发环境，一大特性是标准化且随用随抛；即用户同时创建多 Workspace 用于并行开发、而不用在切换工作焦点前做 git stash 一类的环境状态暂存的操作。这种 Ephemeral DevWorkspace 能给研发活动带来什么样价值？除了一些管控方向上被认可的收益（如降低基于工程师本地的代码存储及构建所带来的数据泄漏 / 软件供应链投毒等风险），对最终用户来讲、离替代本地研发环境还有差距。但回顾 VCS 系统的演进（如 Git vs. SVN），基于 Git 的轻量分支模型、在研发迭代模式上有了如 Gitflow 工作流等创新实践；很多场景价值是基础能力的副产品，对于云研发还有很长的路要走。
这一年也有一些外部对话，如 Coding 张海龙老师提到，很多共享组件是无法完全是 Ephemeral 形态的，最典型的例子是数据库；此外就是联调时的业务流量问题，一个密闭的独享环境是缺乏验证能力的（因此 Nocalhost 的解决思路是替换一个开发态的工作负载）
k8s 也带来了不少问题，最大的一个是问题排查链路过长，往往对依赖的 infra 没有足够权限（如使用共享集群时），问题解决只能靠拉群推动；故障面也比较发散，可能是资源水位紧张、或是内部管控链路的某跳系统异常、也可能是某些云产品故障，甚至碰到过集群凭证被删的情况。
另外 On-Premise 部署（如整套产品技术的对外输出，或为满足如合规场景下的独立建站需求），需要很大的改造和实施成本；行业竞品 Gitpod 的 installer 以及 OP 路线就切换了很多次，之前调研时总结的旧文 腾讯云上 Self host Gitpod 里的方案都已 Deprecated 了。