有两个月没写总结了，不管原因如何，总要把欠了的补上。这个周末抽出时间，好好整理一下前两个月的工作内容以及感想，内容涉及：
具体技术点，已写在文章中：??自动化的Github Workflow
自做开源组件以来，文档、预览、构建、发布这几个环节，一直都是很繁琐，手工操作多，易出错，十分不得要领。
于是参考vue/nuxt/element,?一点一点地摸索，反复地尝试，终于找到了适合我们的github wokflow。
于是我们就对所有组件进行升级改造，相关脑图如下：
滴雀APP(意为滴普语雀)下载地址
这个星期，我们由Flutter开发的APP终于登录App?Store了。这是我们第一款由Flutter开发的应用，我也经历了第一次从0到1完整的上架的过程。
我在语雀官方论坛上发布相关信息，也获得了官方人员的认可。
我感触比较深的是两点：
年初的时候，与某团队进行技术交流，听说他们不但做了小程序，还做了APP，甚至他们已经完成了从RN到Flutter的转型。我们当时只涉及H5，并没有过APP方面的积累，因此虽然表面不动声色，其实心里大吃一惊，不免有些没底气。
时至今日，我们开发的APP已被当初那个团队的人使用着，我心里已不虚。
如今很多社区、论坛、公众号，都在报道Flutter的相关信息，各种比较Flutter与其他技术的优缺点; 身边很多人也早就跃跃欲试，却一直说没时间而停滞不前，或因为做不出最佳选择而犹豫不决。
而我们已经在实践，并且上生产了。要想真正了解一件事，唯有通过亲身实践。所以，如果真的想尝试，赶紧行动起来吧，不用再犹豫了，也不需要把没时间当借口。
通过实践，我认为做产品有两点很重要：
第1点也就是mvp，但这点理论上说起来简单，做起来却难。
首先，用户的声音不一定能听到，就算听到了，也可能因为沟通表达的问题，理解有偏差。
其次，很多时候产品规划都是很宏大的，功能都是很齐全的，从0到1的过程中，很容易在这种规划中迷失。
同时，优先解决核心问题，先实现最小功能闭环，思路是没错，但这样的产物可能过于简陋，因此有人可能会觉得这不像是产品，而持否定意见。
所以，第2点就很重要。自己做的产品，自己用起来，也即“吃自己的狗粮”。
自己去动手前，想一想，这个东西做出来自己会不会用？如果答案是否定的，那就先别动手，重新再想一想。
自己作为用户，才能真正地培养用户意识。
最后还要注意的是，产品越早投入使用越好，这样可以根据用户反馈，快速调整与完善。
对于技术，我新增了以下方面来观察与思考：
全局意味着要有整体思维，从团队、从整条生产链路来思考。
现在市面上很多媒体，过分强调个人或单个环节，导致人们普遍过分关注局部，而忽略了整体。
比如有很多开发技术方面的“练级攻略”，给人一种错觉，似乎掌握了这些技术，就能横扫江湖，走向巅峰。但其实开发只是软件工程的一个环节罢了，如果不能掌握整体，在局部再登峰造极，也会有捉襟见肘的时候。
再比如某些教程，说是“教你从0到1开发一个APP”，但其实也只是聚焦在开发领域，也只是能在自己的机器上构建一个APP，安装在自己手机里而已。真正要上线到生产，让别人也能安装使用，同时保持后续的更新迭代，前前后后还有很多内容要涉及，并不是学了教程，开发好了，就完事了。
使用全局的思维来看待这些事情，这样才能看得更清楚、更透彻。
其实很多技术是可以用金钱来买的。这个交易的本质是：用金钱来买时间。
下面举些例子：
上面的例子都是常见的待决策的情况，前者都是自己亲力亲为，花费的是时间;?后者则是做资源整合，付出的是金钱。值得一提的是，时间也是金钱，也是成本，因为员工是要发工资的，这一点千万不要忽略了。
遇到上述情况如何决策，需要具体情况具体分析。
只不过，在筛选简历时，每每遇到一些人描述自己“全栈工程师”，但其实只是泛泛而谈时，我都在想，我为何不直接招一个专职的前端、一个专职的后端？这对于企业而言，一个月增加的成本，微不足道。这种类似的思想，池建强在《Flutter 要全平台制霸？我看悬》一文也提到了。
产品上线后，就会收到用户的反馈。有可能产品的第一个界面，就让用户困惑了。此时技术人员常见的反应是：这都不懂，真笨！
请尽早把用户愚蠢的想法抛弃掉。用户遇到了任何问题，首先应该想想，是不是产品有需要优化的地方。技术是用来解决问题，提升效率的，不是用来彰显自己高端、与众不同的，做技术的千万不能曲高和寡。
很多时候技术人员评估的事情的优先级，是按照技术难易程度、有趣程度而排列的，但其实上线后，最重要的，是倾向用户的声音，根据反馈进行开发调整。
也许你觉得做个炫酷的动画是很有挑战性、很有趣的事情，但用户也许更关心产品首页的错别字。这种情况下，请优先改正错别字。
总有一些技术团队在讲自己是设计这个系统的，怎么实现的，讲了一大堆，即没有附上代码地址，说什么与内部业务联系太紧密，不方便开源。
我也写过一些文章，所以我清楚，很多时候文字并不能完整地表达意图，更别说一个大型系统的设计。也许文章作者觉得自己写出关键点了，但读者的知识背景参差不齐，难保文章没写出来的，才是读者更需要的。因此，软件设计没有附上相关的可执行产物，我认为做的就是不到位。
很多时候，大家重复造轮子，就是因为资源不共享，前人的成果没法复用。
vue、k8s都开源了，把我们的实践成果开个源，其实也什么大不了的。如果涉及商业机密，把相关内容替换成demo就好了。说到底，分享的意愿不够罢了。
如果我们实践了想分享，一定会开源，不搞虚的。
去年，我的团队理念是，基于团队现有成员，把每个人打造出我想象中的样子。
当时，我看人主要还是看技术能力;?对于一些技术能力并不符合预期，但态度好的人，我也愿意招聘进来，因为可以培养。
今年，我更强调的是适者生存，也即，团队是有淘汰的，跟不上步伐的人，只能离开。
我现在招聘更愿意招已经技术能力过关，不太需要进行技术培养的人，也即宁缺勿滥，纵然这样很可能一个月也招不到一个人。
另外，我还会注重对软实力的考察，比如热情、目标规划、自我定位、思维方式等，我希望团队成员是自我驱动的，最终能成为自己想要的样子。
一句话总结：去年我想让团队的所有人变得合适;?现在我只想要合适的人留在团队里。
在去年北京的项目实战之后，我隐约觉得，我已经获得了足够的外界认可。
回来广州的大半年，我愈发确定，接下来我寻求的，是自我认可。
这是一套自己给自己的评判标准以及打分机制：
最后，来点鸡汤：愿你不受外界环境摆布，坚定自己的意志，坚持做你最初想做的事。
原文：https://www.cnblogs.com/levy9527/p/11110961.html