闲鱼在年便引入了Flutter，是国内第一个引进Flutter的团队。
当时的Flutter还远未成熟，行业内也没有把Flutter放入已有工程体系进行开发的先例。
这两年，Flutter也逐渐在其他企业里落地，但同时也不断有质疑的声音发出。甚至有传言表示“闲鱼的新业务已经放弃Flutter”、“相信闲鱼遇到了很大的难题”......
那么，作为Flutter先驱和探路者，闲鱼在过去几年的摸索过程中遇到过什么阻力？踩过什么“坑”？对于相关技术开源的态度是怎样的？对于以上的一些传言又是怎么看待的呢？
针对这些疑问，闲鱼代表团队分享了一些开发者背后不为人知的小故事。希望能让大家从背后人的维度去看闲鱼团队，理解他们的初心，以及这个过程中遇到的挑战、挣扎、付出的努力、得到的教训。
1.在新技术落地过程中，遇到过什么阻力，有什么避免“踩坑”的经验？
闲鱼从年开始接触Flutter，最初是一个自上而下的尝试。
一方面，从创新团队的角度来看，需要以战养战，为团队储备更多的人才；另一方面，希望切实解决当时团队人难招、产能低的问题。
在前期的调研过程中，最初是希望将Flutter作为闲鱼国际化版本的主要技术选型；由于后续业务上的决策，导致该项目夭折，因此希望将Flutter引入主App中进行探索。
在尝试之初，从组织、配套工具，到架构侧都没有准备得特别好，项目落地面临很多困难。在团队抽调的突击小组中，有大量的研发人员非常不看好这项技术，大部分研发人员并不认同Flutter，没人知道这件事情该怎么做。
当然，从年开始，闲鱼在多个技术方向都进行了类似的尝试，实践证明，创新的确比想象难得多。
时间来到年，回首过去尝试的多个方向，目前只有Flutter得到了阶段性的胜利，并作为闲鱼的技术品牌为大家广泛熟知。这里面所经历的艰难险阻只有当时参与过从0到1过程的研发人员才能体会。
由于Flutter落地过程的艰辛，其间也有不少同事离开了闲鱼，幸好后续有更多希望这件事情成功的研发人员加入，大家一起努力至今，才有了今天看到的成果。我们也非常感谢在此过程中付出过努力的每一位同事，不管今天他们是否还在闲鱼，是每一位同事的努力让美好终于发生。
从Flutter落地的过程中总结出以下观点，供大家参考。
从布道者的角度来看，需解决以下两方面的问题：向上，需要得到更多决策者的支持；向下，需要减少开发者进入的成本。
关于决策者链路，Flutter在闲鱼落地的过程中没有上层的阻力，因为开始是一个自上而下的决策，但在后续的推广和落地过程中，从更大的组织视角去看，比如构建AliFlutter组织、构建FlutterChina组织，这些是一个自下而上的行为。
在这个过程中，闲鱼选择的是“农村包围城市”的理念。先从社区出发，发现同路人，找到不同公司、不同业务的价值，再回归内部，影响决策者。前期不管是构建集团Flutter的兴趣小组，还是正式有了AliFlutter的虚拟组织，都是找到同路人，探讨和争论其技术价值的过程，这个过程可以请各团队的关键决策者躬身入局。通过讨论又能帮助团队进行更深入的思考，并为Flutter提供一个阶段性的明确定位——面向研发效能提升，构建新的研发模式，快速支持小前台业务落地。将该目标与阿里巴巴集团大的研发效能目标进行连接和推动，即可顺利地推进该项目。
关于开发者成本，首先是自己团队的开发者成本。在任何新技术落地的前期，都有一定的成本，需要度过这个阶段才能得到收益。因此，在开始阶段，必须尽量降低落地成本。
在项目之初，最好以小规模团队的形式进行尝试，同时新技术在前期架构落地中需要重点考虑过渡阶段的效率问题，不要断崖式地迁移。闲鱼在初期没有充分考虑这个问题，导致工程侧开始的架构并不合理。后来，闲鱼重点围绕混合架构，以Flutter开发小组与原生开发小组的协作模式进行设计和落地后，该问题得到了有效解决。
例如，前期闲鱼就重点解决了原生项目无法独立打包的问题，极大地解决了当时研发效率的阻塞问题。混合栈（FlutterBoost）的重新设计，也解决了当时由于Flutter和原生生命周期不一致带来的一系列复杂问题，保证了开发调试的稳定性。如果团队仍有余力，可以考虑对开源社区进行一些力所能及的输出。闲鱼先通过发布文章，再通过部分开源项目以及内部开源的形式，给Flutter社区和阿里巴巴集团提供了一些帮助。闲鱼相信“日拱一卒，功不唐捐”，虽然依然还有很多问题需要解决，但是随着更多开发者的进入，大量的问题终究会被解决。
2.闲鱼对开源项目的态度是什么？未来会把大量文章中提到的技术开源出来吗？
闲鱼在年完成Flutter主链路的部分改造后，发现在落地过程中有很多问题，而且Flutter社区并没有给出很好的解决方案。
从帮助Flutter社区其他开发者的角度出发，闲鱼内部开始讨论开源事宜，这是闲鱼第一次尝试开源，所有人都没有经验。大家开开心心地希望能将自己做的一些事情同社区进行交流。
当然，作为第一次开源，很多事情做得也非常糟糕，糟糕的文档、糟糕的Demo、没有测试用例、问题维护不及时、没有好的社区共建方式，于是引发了社区开发者的大量抱怨。
从自己真实的感受来说，要维护好社区项目，需要付出大量的精力和时间，这些甚至需要不少同事全职去做，这对一个业务团队来说有些勉为其难。
对开源的反思是要敬畏开源，敬畏社区，在反馈中不断地成长，完善自身项目。例如，FlutterBoost前期的设计在兼容性上侵入性太强，导致后续的升级成本较高。在未来的3.0版本中，闲鱼会主动解决这一问题，减少关键的几个类的继承和重写，简化概念，降低接入成本。
目前，这个阶段会重点
推荐文章
热点文章
