我的2025
Source: Dev.to
2024 – 证明我能构建、快速学习并交付
2024 年的目标是向自己证明，我能够 构建、快速学习，并且 持续交付项目。
- 我将代码部署到生产环境。
- 我面对真实的故障。
- 我做出了有后果的架构决策。
- 我学到了任何教程都教不到的经验。
这些经验不是通过阅读获得的，而是 通过实践 学到的。
2025 – 理解构建软件的真实含义
2025 年并不炫目。它没有围绕框架或流行词。它是混乱的、务实的，有时甚至让人不舒服。
个人里程碑
- 完成高中学业。
- 获得空闲时间，去探索屏幕之外的“真实”技术世界。
第一次技术节 – GDG Ranchi 主办的 DevFest
“纸面上可能看起来很小，但对我而言，这是一个转折点。”
看到开发者、演讲者和学生在同一个实体空间里，让我产生了线上学习从未带来的领悟。
- DevFest 之前： 技术感觉像是个人的追求——我、我的电脑和网络连接。
- DevFest 之后： 我看到了软件的人性面：人们分享失败，辩论决策，讨论他们在生产环境中真正破坏并修复的系统。
最大的惊喜不是活动的规模，而是意识到 我属于这里。我并不是“太早”或“准备不足”。我理解了正在讨论的问题，提出了更好的问题，并带着更明确的方向感离开。
“学习不仅通过代码发生；它也通过接触发生。”
与真正构建东西的人同处一室，促使我提升自己的标准，交付更好的软件，更负责任地思考，并停止把项目当作一次性实验。
Freelancing & the Reality of Production
Thanks to the habit of writing blogs, I secured my first clients as a freelance web developer and took my skills to the real world.
From “Shipping = Finish Line” to Production Discipline
- Old mindset: If the app worked locally, deployed successfully, and didn’t crash immediately, it was done.
- New reality: Real users, real bugs, and edge cases that manual testing missed forced me to confront production‑grade quality.
Key Takeaways
- Every decision carries weight.
- Logs, rollbacks, and downtime matter.
- Small changes feel heavier when real users depend on them.
In casual projects, mistakes are learning opportunities. In production, mistakes are responsibilities. A broken feature isn’t just “oops”; it interrupts workflows, jeopardizes deliveries, can affect data, and erodes trust.
Mindset Shift
- You think twice before deploying.
- You test flows you previously ignored.
- You plan for failure instead of assuming success.
The biggest change wasn’t technical—it was psychological. I stopped asking “Will this work?” and started asking “What happens when this breaks?” and “What other ways can a user break this?” These questions alone made me a better engineer.
安全——从事后思考到基线
2025 年最令人不安的教训之一是意识到即使是小型应用也可能暴露得如此严重。
- 我曾认为安全只有在拥有用户后才重要。
- 出现了重大漏洞，包括一个导致我的应用宕机的 CVE，尽管用户基数很小。
我不会忘记的硬性规则
- 永远不要在生产环境中以 root 身份运行应用——绝不。
- 假设每个服务都会被扫描、探测和测试。
- 安全不是“企业问题”；它是基本责任。
安全在 2025 年对我而言不再是抽象概念。它变得个人化，一旦如此，你再也不会以相同的方式构建。
迫使我面对复杂性的项目
2025 年不在于我构建了多少项目，而在于每个项目如何迫使我面对不同类型的复杂性。
1. 生鲜配送应用（灵感来源于 Blinkit）
- 表层: 用户、商品、购物车、订单。
- 现实: 时间敏感的工作流、状态转换、运营压力。
- 教训: 订单不仅是数据——它们是承诺。延迟更新、不一致的状态或缺失的边缘情况会立刻导致信任破裂。
Read more about this project here
2. 直播与视频处理
- 关注点: 转码流水线、编码格式、延迟、资源使用。
- 教训: 视频系统是 基础设施问题，而不仅仅是前端问题。这改变了我对性能和可扩展性的思考方式。
3. Finflow – 我的记账应用
最初是一个简单的网页应用，后来演变成一个拥有重大… content truncated in the original。
Source: …
收尾思考
2025 年让我明白 生产软件需要思维方式的转变：
- 部署前再三思考。
- 测试你以前忽视的流程。
- 为失败做好规划，而不是假设成功。
最大的变化是心理层面的：从“这能行吗？”转变为“它坏了会怎样？”
如果你正在阅读此文，感受到同样的兴奋与不适，请记住，你正走在正确的道路上。那些凌乱、令人不适的时刻才是实现真正成长的地方。 🚀
# 2025 – Lessons Learned
Updates and a Flutter mobile app that synced data with the web taught me that shared state is one of the hardest problems in software.
The UI is forgiving — data corruption is not.
When GitHub Actions were blocked for me, I didn’t wait. I built a simple CI/CD pipeline myself. It wasn’t fancy, but it worked — and, more importantly, it forced me to understand deployments at a lower level. When the tooling disappeared, the learning multiplied.
Payments were another major theme. I integrated multiple payment gateways, explored different verification patterns, callback flows, retries, and failure handling. Payments taught me that **correctness matters more than elegance**. You don’t optimize for beauty when money is involved — you optimize for certainty.
I briefly explored Flutter more deeply, but eventually realized my long‑term focus was better aligned with Expo and JavaScript‑based ecosystems. That detour wasn’t wasted — it clarified my direction.
By the end of the year I was building something bigger: a platform‑style app inspired by Hago and WePlay. Not just a game, but a system — users, sessions, state, and real‑time interaction.
Every project added a new layer to how I think. Not “how do I build this?” but **“what breaks first, and why?”**Vibe‑Coding 小项目
我编写了一个简单的应用，尝试在全球传播积极信息的 vibe‑coding。它是一个小而几乎带讽刺意味的项目，旨在点出 Hacktoberfest 中的“假参与”——那些只为拿 T 恤而不愿真正贡献的开发者。
这个应用并不复杂。它没有引入新的架构挑战，但它有自己的目的：我可以快速、直率且有主见地构建东西，而不必担心打磨或指标。这比我预想的更重要。
ReadmeHub
ReadmeHub 让我记起，构建仍然可以是有趣的，而且并非每个项目都必须成为产品。有些项目的存在只是为了表达某种想法、探索概念或满足好奇心。
在充满责任、生产压力和真实后果的一年里，这个小项目帮助我重新连接到最初为何开始构建的初心。你可以在以下地址查看它：
核心要点
- 软件是一种责任行为。 在生产环境中的错误不仅仅是一个错误；它是你必须承担的真实责任。
- 一旦某个东西进入生产，它就不再是“你的代码”，而成为其他人依赖的东西。这种转变会改变你的思考方式、测试方式、部署方式以及出现问题时的响应方式。
- 没有目标的快速会导致脆弱的系统。工程成熟往往表现为选择更简单、更安全的方案——即使你本可以构建更令人印象深刻的东西。
- 成长不在于你交付了多少，而在于你对交付内容后果的深刻理解程度。
这种思维方式改变了一切。
2026 – 目标与优先事项
如果2025年是关于通过经验学习的，那么2026年将是关于公开分享这些经验并构建更坚固的软件。
我的计划
- 创作更多内容——不是追逐潮流的教程，而是诚实的写作，记录哪些有效、哪些出错以及我会如何不同地做。
- 记录代码背后的决策，而不仅仅是代码本身。
我的2026优先事项
- 少做一些，但做得更好
- 把生产环境视为神圣
- 持续学习，但保持脚踏实地
- 分享过程，而不仅是结果
2025年让我认识到软件的脆弱性。2026年则是以更用心的方式构建软件，并帮助他人也如此。
我希望你的2025和我的一样精彩绝伦。展望未来，祝大家2026快乐！ 🎉