好久没有碎碎念了，在家闭关两礼拜了，终于有点时间来思考思考了。
最近的计划
最近正在着手做一些Flutter相关的工作，顺便整理了一套「Flutter兵法」，看完保证让你在产品面前横着走。
做这些东西的目的，实际上是自己在学习的过程中，对技术方案和架构的思考，同时，学习现有的方案，从而归纳出一套最佳实践，不仅对我是一个提高，也对他人在实践过程中，可以起到很好的指导作用，如果能有实践的反馈，也会让我得到反哺。
这一系列，可以在公众号菜单中找到，希望能对大家有所帮助。
UI组件库
我虽然写了很多Android、Flutter的UI上的一些文章，但我基本上不会去做一些开源的所谓的「UI组件库」。
因为对于在公司的开发者来说，没有哪家公司的UI库可以完美的用在另一家公司上（当然，除了一些小的初创公司，不在意UI风格，只是功能实现），为什么呢，因为一个App的设计风格，往往是跟公司挂钩的，从配色、组件、交互上，大公司都形成了一套自己的风格体系，所以，如果要做一套开源的组件库，那么势必需要增加茫茫多的配置、各种颜色、形状、阴影等等等，这些东西一旦形成配置，就会无限制的增加组件的复杂度，即使这些东西，在一个公司内，可能是一次性的设置，但是要做成通用的UI组件库，那就需要增加很多无聊的配置。
所以，我对于「UI组件库」的看法就是——在公司内部设计风格统一的基础上，实现一个「公司级别的UI组件库」，这样一来，其实组件的风格基本就固定了，也不用太多的配置，也便于维护，更重要的是，它不冗余，没有那些花里胡哨的配置，也没有无用的功能。
而对于这样一套「UI组件库」，也就没有开源的必要了，我做的事情，便是授之以渔，学会了组件库的设计方法，实现一套公司级别的组件库，并不是什么难事。
救火队员
曾经有一个段子：
魏文侯问扁鹊：“你兄弟三人，哪个软件开发水平最高？”扁鹊说：“大哥最好，二哥其次，我最差。” 文侯甚为不解。扁鹊解释道：“我大哥在设计阶段已经考虑周全，无bug存在空间，所以默默无闻。二哥在Bug出现时就顺手解决了，所以名声传不出技术部。我每天像打地鼠一般到处救火，有时解一个bug，引入新bug，KPI直线拉满，芳名远扬。
结局：大哥因为每天整点下班而不是熬夜加班，而且上班时看着也不忙，领导认为他不认同企业文化，没全力为公司创造价值，颇受排挤。
段子总是段子，但也说明了技术人的难处，到底如何衡量一个开发的价值呢？
一个团队，肯定少不了像「扁鹊」这样的救火队员，他们能在有火情的时候冲上第一线，找到问题并解决问题，但一个团队，肯定也少不了像「大哥、二哥」这样的开发，如果人人都能有像他们那样的开发质量，那么火情从何而来呢？
但愿世间人无病，何愁架上药生尘
上工治未病，但「上工」需要一个伯乐，他能抗下压力，也能发现谁是真的「上工」。
怪圈
最近发现一个很奇怪的问题，很多的移动开发者，对Flutter和Compose都非常抵触，这点从我最近发的十几篇Flutter文章就能看出来，Flutter的文章阅读量，连广告的一半都没有，而且「取关率」甚至高过广告。
可能他们很多人都还守着原生开发的一亩三分地，靠着用了几年的技术在继续混日子，但事实很残酷，传统的原生开发，已经不能满足现在的开发需求了。
对于小公司来说，Flutter可以快速试错，在不输原生开发的性能下，更能成倍的提高效率，对于大公司来说，Flutter在实现某些特殊UI的需求时，有着比原生更丰富和简便的实现，同时，申明式的设计模式，已经逐渐成为后几年开发的主流，不管你是用Flutter还是Compose，这都是必须要迈过去的坎。
所以，没必要纠结Flutter到底写了多少个「{ }」，也没有纠结Flutter为什么选了「Dart」这么「二逼」的语言，更不要纠结Flutter做不了热更新，如果你还没理解这些问题，那么请你尝试着放低姿态，先试着理解下Flutter的设计原理，再来审视你提出的问题。
就目前而言，在众多跨平台技术中，Flutter是我唯一能看得见希望的方向。
这些新技术、总是有人喜之如蜜糖、有人厌之如砒霜。没必要试着让别人都信服你的观点，时间会证明一切。
业务代码的标准化
业务代码究竟难不难写，这真的是一个问题。
我认为，业务代码不难写，但难的是如何把业务代码写的稳如死狗。
当你在一家公司待的时间够长了之后，你甚至可以获得一个能力——根据代码风格来猜测这是谁的代码。
没错，不同的程序员，在编码时，都有自己的风格，可能是命名风格，也可能是代码风格，甚至是注释风格，久而久之，你就可以「看码识人」了，那么不同的人，在实现业务需求时，也会有不同的做法，这么多不同的做法，孰优孰劣，如何评判呢？
大部分场景下，都是看「时间」了，谁在这公司时间越长，那么他的代码被其他人当作模板copy实现的几率就越大。
一个公司，还是需要有这样一个角色，来规范业务代码的标准化流程，例如一个信息列表展示界面，从loading到网络请求、从数据展示到分页，是用LiveData、ViewModel还是Flow，adapter和Activity如何交互，状态栏、黑夜模式的处理，下拉刷新、上拉加载，这些业务相关流程的代码具体如何写，一百个哈姆雷特，也必须统一一种写法。
有人会说，连写这些代码都要统一，那不是完全限制了开发的发挥了吗？
业务代码要的不是个人发挥，而是「稳定」、「稳定」，还是TMD「稳定」。
一旦业务流程标准化，就不会产生因为个人发挥而导致的问题，开发就成了流水线上打螺丝的工具人。你这TM不是限制了个人的发展吗？
其实不然，如果你是萌新，那么在熟练的打螺丝后，你可以很好的学习这套流程，这套经过时间检验，经过大家反复推敲的流程，一定可以让你学到很多东西。那么如果你是大佬，你可以更好的改善这个流程，引入Flow，替换RxJava的实现，引入VB，VM等等。
实现这套流程，就像是一场战役中的「战略布局」，一旦战略的核心方针确定，是打「锦州」还是打「沈阳」，就显得不是那么重要了，你可以在战略的基础上发挥你的优势。
但是，这套「战略」的拟定，是一个严谨的过程，不仅需要组内成员的参与，更需要大家针对方案进行一轮一轮的评审，最终形成一套全员认可的方案，这样在推进过程中，才能让大家统一战线。
业务代码的标准化，并不是让大家都变成工具人，而是让所有水平的开发，都能快而稳的做完业务需求，发挥自己的专长，做一些自己爱做的事。
向大家推荐下我的网站 xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问