Threads for dto_rss_bot

    1. 1

      5 年+的 flutter 开发者 debuggerx 回复


      5 年+的 flutter 开发经验,也用 dart 开发过后端,我人为的 dart 的优点:

      1. 支持 AOT 编译,产物可以几乎无依赖的直接部署,这点可以对标 go 的部署方便,比 JS 、TS 、python 等需要运行时依赖的语言方便很多,比如我一个项目里 dart 后端只需要这样一个 Dockerfile: https://github.com/debuggerx01/dde_gesture_manager/blob/dev/api/Dockerfile 就可以得到一个 10 几 MB 的镜像,服务跑起来内存占用也才 50MB 不到,可以说非常方便了,资源消耗也够低

      2. 语法常规,可以说几乎没有非常特立独行的概念和语法,几乎所有语法特性都是在其他语言中经过验证的,结果就是 dart 学起来曲线平滑、写起来非常舒服、代码表达能力和组织能力也相当不错,尤其是在有其他语言如 Java 系列、js 系列、Python 、Swift 经验以后。举几个例子:

      • a. 语法级的异步支持,不像原始的 java 一样像做点啥都需要开线程,结果各种多线程 bug ,开发时的心智负担低很多,性能还不差
      • b. 单继承+mixin ,即提高了代码复用性和组织能力,又避免了多继承带来的各种问题
      • c. 强类型,尤其是全面转向健全空安全之后,类型系统可以说达到了一个相当均衡的状态,该有的特性基本都有(抽象类、泛型等,GO ?),正常使用情况下很少出现包括 NPE 在内的类型错误(JS ?),而且类型代码书写的成本也不高,很少需要复杂的类型处理(TS ?)
      1. 还算不错的工具链和 IDE 支持,pub 依赖管理比 npm 等好用不少,dart format 格式化可以避免多人合作风格不一导致的代码差异和冲突,dart compile 就可以很方便的将源码编译成 js/可执行二进制程序 /jit 快照 /aot 快照,jetbrains 全系和 vsc 都可以安装 dart 插件获得相当稳定的 IDE 支持( Swift/XCode ?),还有内置的基于 web 和 ws 的 DevTools ,分析程序的运行性能也很方便

      2. 几乎没有平台依赖,平台支持足够广泛,而且几乎都可以支持大部分功能,不像某些语言,号称跨平台,实际上是和某一平台和生态强绑定,其他平台只有“core”支持( C#、Swift ?),发展前景高下立判

      3. 生态已经足够繁荣。这点可能很多人会不认同,会去和 Java 和 js 比,但是就我而言,想做的东西几乎都可以用它做了,例如:

      • a. 前端,不用说,肯定就是 flutter ,这个方案可以覆盖除了小程序之外几乎所有的前端需求。可能有些人觉得 flutter 不行、不好用,我只能说可能是有些人和有些特定项目不适合 flutter 而已,或者是单纯的能力不足
      • b. 后端,简单的需求用 dart 内置的 io 库就能解决差不多,复杂的我个人推荐“Angel3”这个框架,总的来说比较接近 Express.js ,后端开发常见的功能也都支持了,只要花点时间看看源码(很简单)完全可以满足一般的后端开发需求
      • c. 工具脚本,这点得益于 dart 既可以解释执行也可以编译执行,就非常适合一些简单的工具开发。我在自己电脑上就会用 dart 写一些脚本,随时可以方便的修改使用;编译后可以直接放到手机的 Ternux 或者机顶盒路由器上运行,部署使用方便
      • d. 各种三方库,基本都可以在 pub.dev 中找到,很多时候并不需要像很多以为的需要造很多轮子。印象比较深刻的是在移植一个 python 的算法到 dart 时,科学计算和信号处理这种相对冷门的库都已经有实现: https://www.debuggerx.com/2021/02/18/qrs-detector-for-flutter-in-dart/
      1. 1

        一位前员工 (Jinnyu) 的回复


        Q: 技术难点有哪些?
        A:

        1. 全局性事务
        2. 流量压力
        3. 前置检查
        4. 车票区段售卖

        1. 全局性事务 现阶段最难的是全局性事务, 因为保密原因, 不能说太多, 一句话概述就是整个系统存在事务问题导致的性能低下
        2. 流量压力 众所周知
        3. 前置检查 你买一张票的前置检查多到你无法想象, 目前的做法是线性检查, 提过并行检查的意见, 被否了
        4. 车票区段售卖 其实车票不是 12306 卖的, 实际卖票的是 18 个铁路局, 12306 只是一个售卖平台. 12306 只是拿到票然后根据用户提交的席位来分配这些票.

        总体来说 12306 目前的复杂性都是因为技术债务导致的. 如果抛弃全部包袱, 重新开发需要 200 人的团队开发大概 3 年左右.