北京
9月3日，作者发布了Vesper——一款面向Android和iOS的跨平台基督教祷告应用，也是他参加RevenueCat 2026 Shipaton的参赛作品。这不是为了参赛而临时拼凑的简单应用：作者花了数月时间打磨功能和设计，目标是把它做成真正的生产级应用，用来启动一门生意。这个系列的技术文章，就是作者对这段开发历程的回顾。
从想法到上线
作者在5月初萌生了这个想法，并开始开发Vesper。Shipaton恰好与他原本计划好的发布节奏重合，于是他决定多等几周，把细节打磨到位，同时把一路上的技术决策记录下来，分享给Kotlin社区。这些文章都是事后写的——不是边开发边记录，而是回顾自己做了什么，解释每个决策背后的"为什么"。
Vesper的设计重度依赖Ballast——一个作者维护多年的Kotlin Multiplatform状态管理库。Ballast主要是作者个人偏好的工程结构，用来组织每个屏幕的UI状态和应用导航。写这个系列的部分动机，就是想展示Ballast在真实生产级应用中的样子。
不依赖Ballast也能用的经验
但作者强调，构建Vesper过程中学到的东西，适用于任何想构建真实生产级应用的人——不管用不用Ballast。虽然这些文章会用Vesper的实际代码来讲解Ballast的用法，但那些关于如何构建能处理生产负载的软件的通用知识和思考方式，并不绑定于Ballast。
这是一个进阶系列。作者不会从头教你怎么搭Ktor项目，也不会解释什么是协程。他聚焦的是更高层的架构决策和随之而来的权衡——那种构建一个你真正打算长期维护的软件时才会有的思考方式。
不是玩具项目，是公司的地基
Vesper不是那种做完就扔的练手项目。它是作者希望未来能变成一家真正公司的地基。这个定位影响了代码库里的每一个决策。
不过作者对读者群体也很坦诚：这个系列里描述的大部分内容，对一个简单的side project来说几乎肯定是过度设计了；而对一个拥有正经工程团队和基础设施预算的成熟公司来说，又很可能不够用。他实际面对的约束，是早期pre-launch创业公司特有的那种——需要生产级稳定的代码，却付不起生产级服务的钱。
很多本可以花钱买现成服务的东西（邮件营销、功能开关、推送通知、任务队列），作者都选择自己造。原因不只是暂时买不起，更关键的是——那些服务提供的很多高级功能，他现在根本用不上。这个背景，是理解整个系列的前提。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
