善战者无赫赫之功

哈喽，我是老刘
老刘带着团队从Flutter 1.0时代开始一直用到现在。
可以说Flutter发展过程中大大小小的坑老刘踩过很多。
但是有些类型的坑我们几乎很少踩中，比如前两天这个客户的案例。

一、技术选型，制造bug于无形

这个客户是今年早些时候开始合作的，当时他们的Flutter项目已经有一定的规模，找到我们帮忙开发一些涉及到原生的功能模块。
也就是说他们的项目大约在年初左右开始开发的。
当时我看到他们用了Flutter 3.27 就觉得版本选择有点激进，但是因为不是自己的项目也不方便多说什么，只是在群里提了一句。
结果前几天他们的项目要上线了才测试发现Flutter 3.27的Impeller渲染问题。
具体情况就是在小米一些型号的手机上渲染会出现马赛克，禁用Impeller后恢复正常。

其实我当时知道使用Flutter 3.27的时候就隐约觉得不太稳妥，但是也没有意识到这个问题。
原因是我们很少做这种激进的选择，所以对这类问题并不敏感。

为啥说在年初的时候选择Flutter 3.27是激进的选择呢？
其实如果关注Flutter 每一次的发布版本就大概能理解。
Flutter作为一个还算是年轻的跨平台框架，还没有进入到非常稳定的阶段。
可以看到每个大版本都还有不少的新特性引入，比如Impeller、比如UI线程合并。
就连dart语言也在以比较快的速度进化，比如模式匹配，比如老刘最期待的宏。
只是我们在客户端开发的视角上看，基础的开发功能相对比较稳定了而已。
所以在底层功能可能有较大变化的场景下贸然选择非常新的版本其实是比较冒险的。

老刘自己通常会选择在一个经过广泛验证的版本上停留很久，然后在必要的情况下进入下一个经过广泛验证的版本。
其实我们对每个版本的新特性甚至是Impeller这样的重大改进都不是特别感冒。
因为对一个APP的大多数页面来说，Flutter 2.x甚至是1.x的用户体验已经非常好了。
所以为了这些新特性使用了最新版本，获得的收益很少，但是承担的风险却很多，往往不知不觉间就埋下了很多bug。

二、救火队员和管理缺陷

老刘自己一毕业就去了比较知名的大厂，然后就碰到了很多救火队员。
当时我天真的以为这些人很厉害。
后来去了外企、创业公司等不同类型的公司，见识到了不同的管理风格和策略，才知道能让项目不澜不惊平平稳稳的持续迭代下去才是真的高人。

为啥救火队员很容易被管理者看重呢？
其实这很符合直觉。
如果你的项目时不时出点问题，然后又有人总能把这些问题摆平，你会很容易觉得这个能摆平各种问题的人是核心骨干。
但是如果管理者只有这一个评估的视角那他肯定是不合格的。
作为管理者或者项目负责人，你更应该思考的是为啥总会出点问题？
是这个技术领域本身就问题重重，还是最开始的技术选型选择了坑多的？
是架构设计没有考虑周到，还是开发流程不够科学正规？

一个项目中的两个人分别开发各自的模块，一个没有什么特别精彩的表现，只是按时交付到点下班。
另一个时不时的加班解决一些关键bug，这些bug也不是他写出来的。
这样看似乎第二个人更优秀更应该升职加薪。
但是换个视角，第一个人架构设计简洁优雅，技术选型考虑周到。
所以他新开发的功能都可以快速高效很少有隐藏的bug，所以他不用加班，也没有特别出彩的表现。
第二个人看似努力优秀，但是很多问题根源上可能是因为架构不够好，是因为技术选型考虑到不够全面。
这时候出现的问题看似不是他写出来的，但你能说和他没有关系吗？

三、善战者无赫赫之功

老刘自己毕业去了以加班闻名的大厂，后来去了外企，然后又开始搞敏捷开发。
我做过普通开发，独立负责过关键模块，也做过架构师还带过团队。
我觉得自己特别幸运的是这些经历过的软件开发和管理策略，形成了非常鲜明的反差和对比。
回想起共同工作过的那些真正厉害的开发者和管理者，他们处事风格各有不同，但是共同的特点就是他们管理的项目或者团队波动更小。
表现在项目上就是开发推进的速度、项目质量、bug数量等等指标都不会有太大的起伏。

这种稳定性带来的缺点就是很多外部的观察者会感觉事情很简单，换谁来都行。
这两年频频出现的裁员裁到大动脉，很多国民级的应用和服务都出现低级错误，就是这种认知下导致的结果。

古人说：“善战者无赫赫之功”，又说“养寇自重”。
原来人性千百年来从未改变，只是之前读书少不懂。

好了，由一个bug联想起很多事情，没控制住表达欲写了一篇碎碎念。
如果看到这里的同学对客户端开发或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。
点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。
可以作为Flutter学习的知识地图。
覆盖90%开发场景的《Flutter开发手册》