大家好，我是老刘。
老刘的工作经验还算丰富，光Flutter就做了6年多了，大厂、外企、创业公司都干过。
今天想和大家聊一个特别有意思的话题------"为什么有些技术团队加班到秃头还做不好项目，而有些团队却能喝着咖啡轻松上线？"
答案可能就藏在那些看似平常却影响深远的"关键决策"里。
一个人一生中往往影响最大的是那寥寥几次的重要决策，比如：
- 高考考哪个学校，选哪个专业
- 大学毕业去哪个城市，从事什么工作
- 选择人生的伴侣
其实在软件开发的世界里也是一样，那些关键的决策决定了整个项目的前途，比如：
- 客户端开发，选择原生开发还是Flutter、RN、Uniapp
- 架构设计
- 开发流程TDD还是瀑布流
今天我们就来扒一扒，客户端开发的世界里那些"20%的选择如何决定80%的成败"。
一、技术选型：选对框架，少打十年工
原生开发 VS 跨平台框架（Flutter/RN/Uniapp）
原生开发就像自己盖房子：砖瓦水泥自己把控，但工期长、成本高。
跨平台框架更像是精装房：拎包入住快，但隔音差（性能问题）、装修风格受限（平台特性兼容）。
技术选型没有那个好那个坏的标准答案，更多的是根据需求、项目、团队等情况做出的权衡取舍。
比如团队已经积累大量原生组件库，这时候非要选一个跨平台框架可能反而事倍功半。
再比如项目需求是高度的多端一致性，这时候选择RN这样的中间层技术就不合时宜了，Flutter可能是更好的选择。
血泪教训：
"去年前端团队为了赶进度，并且本身熟悉js，选了Uniapp，结果遇到不少平台兼容性问题，需要在原生开发环境中定位，全员加班一个月------选型时省下的时间，全在填坑时还回去了。"
下次当你面对技术决策时，不妨先问自己：
这个选择三年后会不会让我后悔？
如果出问题了，有没有Plan B？
团队的知识储备hold得住吗？
二、架构设计：盖楼先打地基，写代码先画蓝图
这两年接了不少Flutter方面的外包和咨询类的项目，发现一个有意思的规律。
好的架构各有各的特色，混乱的架构都有一个共同的原因：项目初期的赶进度。
很多项目做到最后实在推进不下去的原因不是中后期的问题，而是在项目最开始的时候把力气用错了地方。
这些项目在刚刚开始的时候为了快速交付试错，开发流程异常奔放，找几个人分一下功能就开干。
不做任何的统一设计和规范，大家各玩各的，一个项目中用了多套不同的UI库和状态管理框架的我都见过。
刚开始的时候看起来是比较快，但是随着功能增加，项目推进的越来越慢。
到后期想加新需求就不得不把原先的代码推翻重写。
见过最骚的操作：某个团队为了赶618大促，在核心支付流程里写死参数。结果双十一流量翻三倍，系统直接崩溃------临时方案活不过三个月，否则就会变异成祖传代码。
其实好的架构设计能够把问答题变成填空题。
当你面对一个需求的时候，好的架构可以告诉你如何进行功能拆分，甚至生成框架代码。
开发者只需要在框架对应的部分填充需求具体的内容即可，例如在UI部分填充页面布局，在业务逻辑层填充服务端接口调用和数据解析。
所以在项目开始的时候别着急写代码，大家坐下来讨论一下架构如何设计，代码拆分如何规范。
有了一个好的地基，随着开发人员对项目的熟悉以及公共模块的补充，开发速度是越来越快的。
反之，技术债是会自己生长的，越底层的问题越会随着功能的增加而繁殖。
三、开发流程：用对方法论，加班少一半
你团队的晨会是不是这样？
开发："我在改昨天测试提的BUG"
测试："我在测开发刚改的BUG"
产品："我在写新的需求文档"
是不是觉得很正常，好像没啥问题？
但在晨会就有些不太合适了，因为晨会是用来对齐目标发现卡点的，而不是汇报工作的。
一个简单且合理的晨会大概是下面的流程：
而比晨会怎么开更重要的是你的团队是否需要晨会。
现在很多团队看到别人开晨会，自己也开。看到别人搞看板，自己也搞一个。
但其实晨会和看板等等工具都是敏捷开发的实践，都是为了解决具体问题发明的工具。
我们当然可以把这些工具单独拿来使用，但是一定要明白这些工具解决能帮我们解决什么问题。
比如晨会，在敏捷开发中，通常是把需求拆解为用户故事，然后再拆解为粒度更细的case，然后在晨会上核对一下今天需要完成哪些case。
看板也是为了快速轻便的计量用户故事和case的推进情况。
如果你用的不是敏捷流程，那么看板和晨会是否真的能帮助到你呢？
把一个拆解到两周的工作内容塞到看板里面是否是削足适履呢？
前面其实老刘想说的就是要选择和你们的流程相匹配的管理工具，而不是跟风。
那么接下来我们聊聊如何选择合适的开发流程。
熟悉老刘的朋友都知道我个人是比较推荐敏捷开发以及TDD的。
一开始我觉得这套方法论适用于大多数的团队及场景。
但是这两年随着咨询业务和敏捷教练方面的业务，接触的公司和团队多了，我发现未必是这样的情况。
首先敏捷开发或者更小范围一些的TDD确实是非常好的方法论，也确实能在大多数团队的场景中取得非常好的效果。
但是这一切的前提是团队有能力熬过刚刚开始转型的动荡。
任何流程的推行，其本质是要求团队成员特别是管理者清楚的知道每一个步骤的目标是什么，是要解决什么问题。
而在流程切换的过程中必然伴随着一定程度的混乱和问题。
如果你没有和你的老板沟通清楚后续的变化，贸然上马敏捷开发或者TDD，那么一旦出现问题比如bug增加，很可能会被问责以及停止回退。
最终结果就是你们吃力不讨好，搞了一个半成品或者折腾半天回到原点。
但是如果你做好了准备工作，不论是敏捷开发还是TDD，都会给你带来超出预期的回报。
你的团队能够以精准可控的节奏推进项目。
代码质量会维持在比较高的水平，综合bug率会大幅度降低。
项目是真的可以每天喝喝咖啡轻松上线的。
总结
其实让一个项目很好的推进下去只需要做好三件事。
"技术选型是方向，架构设计是骨架，开发流程是节奏------这三板斧砍对了，剩下的80%工作量都是水到渠成。"
最后送大家一句话：选择比努力更重要，但别忘记努力做选择 。
好了，以上是最近看到一些项目的感想，如果看到这里的同学对客户端开发或者Flutter开发感兴趣，都欢迎联系老刘，我们互相学习。
点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。
可以作为Flutter学习的知识地图。
覆盖90%开发场景的《Flutter开发手册》