没有最好,只有最合适


一、陷入思考

最近一直没有更新公号,而是一直陷入思考「与其说是思考,不如说是总结」,我们都知道搞 IT 行业的要时刻不断的学习「技术总是在抛弃我们,但是我们决对不能停止追赶的脚步」,市面上技术更新太快,就拿前端来说刚学完 Jquery 又来一个 Angular,Angular 用的正熟练的时候又崩出一个 React ,学完 React 又听说一个 Vue 性能更高点,于是乎又学了 Vue,给人一种感觉就是出要什么新的技术就要学什么似的「很大一部分就喜欢这样去玩,曾今的我也是这样」

最近 flutter 发布了正式版又霸屏了,你学不学?明天又出一个 Blutter 你看不看?对技术敏感这是非常好的,第一时间了解也是值得学习的,但是一定针对自己公司实际项目和业务去选型和实践「当然当作业余兴趣爱好的另当别论」,一味的只是为了技术而技术,听别人说牛 B 而去学习,这样是会有问题的,这让我想起了学生时代的我,来一段小插曲

二、小插曲

这里插入一个小插曲,我本身大学学的就是计算机专业,刚上学那会先学 c 「据说学了 c 以后任何语言都不在话下」,学了一段时间 c「二级指针把我放倒了」,于是 vb 很牛叉「那个时候认知有限觉得 vb 可以写病毒,黑客的感觉真好」,就把 vb 学了,最后又听说 java 不错,我就开始看 java「入了个门」,又看到 php 是世界上最好的语言,而且比 java 还容易学,我就使用 php 做了个网站「php 也入门了」,后来觉得 php 只能搞电子商务「还是当时的认知决定的,口子太窄了」,转了一圈我感觉自己啥好像都会了,啥又都不会,于是乎我又重回 java 道路上「也是因为 java 可以搞 j2me ,j2se j2ee,那个时候根本没有 android ,而且 java gui 编程还有搞头」以后就业道路宽些,所以我决定就搞 java ,就这样我最终走了 java 的道路上「目前是做 android」

在以前上学的时候,基本上都听别人说,或是网上别人说,没有主动思考过到底应该成为什么样的人,觉得把啥都学会那才是真的牛 B ,可是理想是美好的,现实是残忍的,我一度一次性学习两三门语言,导致啥都没有学好,后面工作了我走上了 android 的开发道路,我深刻理解了一定要有一门吃饭的语言–在这个语言上多下功夫,有了编程思维,语言转那是非常好过度的

三、适合最重要

看过我公号的人都知道我在写的文章也比较杂,有 React 有 Vue 有 android 还有 RN ,python 等,我是在走以上学的道路吗?看见啥就学啥吗?当然不是,我学习的这些东西都是为业务或是使用场景准备的,我学 React 是为了学习 RN ,其目的是为了搞 hybird 开发「最早的时候趟过 phonegap/cordova 的坑」,学习 Vue 是因为团队中人员对 js html 等熟悉一些,对 jsx 不感冒,所以我们做的 webapp 就使用 vue ,学习 pyhton 当然我是为了做自动化测试,都是为了目的而学,不是为了学习而学习,所以说离开业务和使用场景谈技术都是扯淡,我不反对我对新技术很敏感,但是不代表每个技术都要学习「你根本不可能学完所有技术」,只有要最合适的情况下「或相对合适」选择适合的技术

说到这里不得不说这几天被 Airbnb 刷屏的文章—不再使用 RN 而是回归到原生开发,原文是于 6 月 20 日发布在 Medium 上的,部分截图如下

大概意思就是说由于技术和组织等方面的原因,我们将停止使用 RN ,并把我们所有为 RN 付出的所有努力都将转化成原生开发–也就是放弃 RN 转原生开发了

好多瓜众就开始宣传 RN 不好,还是原生是王道的舆论,其实存在就有必要,还是那句话离开使用场景和业务所谓的技术和技术选型都是耍流氓,对于 airbnb 而言,在过去它为 RN 的社区也做了不少的贡献,从原文的弃用计划我中我们可以明确的看到,aribnb 说的很清楚,使用 RN 无法实现他们的特定目标,他们知道 RN 不再”适合”它们,并且在 18 年继续支持 RN ,在年底计划将大多数高流量的页面转化成原生的,原文截图如下:

现在大多数 app 都采用 hybird 形式开发「不是 webview 嵌套一个 jsp 或是一个网站」,BTAJ 都在使用「技术使用看什么一般就是看一线公司」,包括支付宝的五福活动也是 webview 形式展现的,所以说使用场景最重要。

对技术要持有敬畏的心态,并且要和实际的工作相结合,不要别人说个什么就是什么,没有自己的思考和判断「恍如学生时代的我」,原生开发确实很吊很牛 B ,个人觉得对于常用的核心的业务还是非常有必要使用原生开发的「除非你们公司压根只关心进度,什么性能了,交互了等等统统的不管,又或是技术负责人最明确你必须要使用纯 H5 开发 APP」,但是对于复杂展示类界面或是非常用「临时性」的功能采用 H5 或是 RN 或 Weex 等都是一种很好的选择

四、谁给你重构的”底气”

对于不同的公司有不同的技术应对策略,对于像 aribnb 这样的公司来说,有专门的创新团队和技术研究团队,人家有时间和精力并且有能力重构自己的产品,可以达到令人发指的地步,不说 aribnb ,BATJ 都是有这种实力的,像阿里的钉钉就是来往团队最后搞出来的「有专门的团队搞这个事情」

但是对中小公司来说,就那么几个人,恨不得一个人当十个人来用,小公司想的第一件事情绝对不是公司所用的技术多么牛 B ,产品令人发指,首先要想的事情是如何让公司活下来,只有活下来才可能有未来,一般情况下这类公司往往看重的交付,时间对他们来说是最宝贵的「当然除了那些真正的技术型驱动型公司」,公司不可能给你太多的机会让你去搞技术「基本上都是拿来主意,有开源的直接拿来使用」

在这种背景下,如何去选择适合公司业务的技术呢?我觉得应该从以下几个方面来考虑:「这里以手机端开发为例,服务端类似」

  • 1、首先了解产品的特点,它是一个业务系统,还是一个单独的外卖 app 等

对于业务类系统来说,各种表单操作等比较多,展示类也居多「这种我们采用混合式开发」,但量对于像直播和一些炫酷的动画老老实实的用原生开发吧「最好不要尝试着走捷径」

  • 2、根据团队情况来考虑

    这里一定要根据团队的情况来考虑如何选择技术「而不是一个人玩个人 show,好多技术老大就受犯这个错误,总觉得自己决定的框架或是技术就是最好的,别人一定要按照这个来,这是有问题的」,以我们团队为例子来说,我给内部人员培训了 React,Vue,最后给的感觉是团队对 Vue 接受程度和反馈都高于 React–所以我们就选择 Vue 来开发我们的 webapp 「除非你的团队只有你一个人,那么随便你怎么玩,你想捅破天都可以」

  • 3、要尊重每个人员建议或是意见

    其实这和第 2 点是差不多,每个人的领域是不一样的,刚毕业的同学掌握的东西你四五年经验的人不一定掌握,所以每个人都有自己的长处,吸收团队成员的建议并且加以讨论就会得到想要的结果

  • 4、学会利用工具

我们要选择提升我们效率的工具,而不是被工具选择,能配置的就不写代码,能机器干的就不人工去干预

总之从大局上来说产品是先完成后完善,技术选择一定要快、准,特别是对于创业类型的公司、赚钱是第一要素「活着才可能会幸福」,所以早期的创业公司可能没什么架构、技术栈这也不足为奇

经常在网上看到,一些什么架构设计,项目重构,我是如何把产品拆分的?如何一步步做架构升级的,可是如果在一些小型公司或是创业公司,项目重构是一种奢侈,也没有人给你那个时间让你去重构「你说破嘴也没有用,你觉得项目越来越大,越来越不好扩展,不能友好的支持业务,于是你想重构,可是你 no time no person 你如何去搞呢,往往新的需求都改不完,于是乎只能在一堆烂代码继续添加烂代码」

在这里说一下我的体验和看到的一些选择重构场景:基本上来说分为两种

  • 1、确实目前的技术方案满足不了业务和需求了

有的公司由于没有架构「也就是写几个 base 类和若干个工具类」,都是采用混编的方式来东拼一块,西凑一块的方式来添加,最后越来越难添加,相同的功能都是把代码 copy 一份然后修改,最后开发人员变成了 cv 战士,于是乎技术负责人受不了想要重构「此时添加新功能产生的 bug 和种种效率来说是巨大的」,对于这种情况一定要说服你的领导或是老板必须得重构了「此时花一半个月,为以后省出时间是不可计算的,因为这些有时按指数级别算的」

  • 2、技术负责人换了,看不惯以前遗留的代码

这有一个很有趣的现象,一般情况下如果一个公司的技术负责人换了,基本上都会引入自己的框架和方案「并且还说的一套一套的」,不管三七二十一就是指责以前的代码怎么不好「看不懂不代表烂」,杂的杂不好,然后就鼓动发起项目重构

就按这个套路,一直”重构”,这样一样就把一套项目来回推倒 N 次,对于这类型的重构,我想说是谁给你重构的底气的

五、如何正确选择技术

1、小创公司

对于小创型公司,活着是首要任务「赚钱是第一要务」,对于产品和项目我们可以根据先完成后完善的理念去做,在技术选型上不建议去从底层架构到各个层代码全部自己开发「可是创造,能不重复造轮子就不要重复造轮子」,对于这一类型的公司个人感觉核心的业务自己去开发「并且选择一些成熟的开源框架去做基础」,对于服务类的「像什么推送了、直播了、统计了等,非核心类的东西直接使用第三方服务,以节省时间为主」,总之一句话–使用最少的时间和最低的成本开发出产品「如果啥都自己亲自去弄,并且把所有的问题都考虑进去,那产品开发出来,黄花菜都凉了,只有死路一条」,在这个类型的公司中基本上不给你重构和架构设计的时间「当然技术型驱动公司还是会很重视的」,所以一切以交付为主

网上常常出来,xxx 的架构演进,xxx 的架构升级,我认为在这一个阶段由于人员和时间的关系,你没有精力去做这些时间,老板也不会允许你去这样做的「这跟情怀没有关系,并定公司不赚钱,一切都是扯淡」

2、中大型公司

对于中型和大型公司来说,对产品我们有一些自己的沉淀,并且人员也相对来说足够充裕,我们就可以去做一些整理归纳「把产品规范和架构升级纳入迭代的进度当中」,大公司我们就不说了,人家不仅注重架构设计、开发分层「并且也非常乐意重复造轮子,并且这类公司常常有自己的研究小组和创新团队,专门去做这些事情」,对于中型公司来说,刚好是界于小型和大型之间的,我们可以自己造部分轮子,并结合业务去扩展相应的技术栈,对于花个五天能为以后节省十天时间的事情我们何乐而不为「所以一定要做一个评估,当然不仅仅是时间、性能等也是同等适用的」

最好有什么用,适合才是最重要的

六、拥抱变化

当然我们要拥抱新的技术「工作中不一定能用到,但是我们适当的了解一下,把握一个技术的前沿和趋势为我们以后做技术选型打一个基础」,对于新的技术我们要心存敬畏而不是一味的”鄙视”「更不要以手头的任务太重没有时间去看为理由来成为自己不学习的借口,刷抖音杂那么有时间的??」

作者: TigerChain 公号同名,订阅查看更多内容
本文出自 TigerChain 侃大山

阅读原文


交个朋友

如果觉得本篇对你有帮助,那么请你完成以下几件小事情

1、动动你的小手关注一下以下公众号「TigerChain」查看更多精彩分享

2、更多视频关注的我的 B站:https://space.bilibili.com/44242327/


文章作者: TigerChain
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 TigerChain !
评论
  目录