软件行业里做技术开发的都知道，我们经常会遇到技术选型的问题，特别是前端和App技术栈，隔三岔五地出现新的框架或库。公司也会要求技术经理基于现状重新对技术进行选型，以适应新项目发展。
本文以App技术栈选型为例谈谈对技术选型的看法。
关于技术选型我们主要搞清楚几个问题：为什么进行技术选型？谁来做技术选型？怎么做技术选型？
第一个问题，为什么要进行技术选型？
做任何事情都有背景或者目的，就是做这件事情的动机是什么？
就拿App技术选型来说，技术选型最常见的目的是公司或者部门初建，要做一个新的产品，需要选一个合适的技术栈来实现这个产品；
也可能是有新技术产生了，这种新技术有新的优势，不管你用不用，最起码需要去了解这门技术，然后能不能应用的现有的产品上，或应用在新的项目上，最后评估能不能给公司带来新的变化，这种变化包括提升开发效率、降低开发成本、产品的体验会不会更好等等。
还有就是新的产品功能有特殊的需求场景，我们需要重新选择合适的技术提供商，这也是技术选型的一种，不过这种技术选型比较简单，只需要明确我们的需求，然后通过“招标”方式最终确定。
技术栈的选型是个需要慎重的事情，一旦确定选型，后期想要切换是需要付出一定代价的。
第二个问题，谁来做技术选型？
一般情况下由技术经理给出技术选型的选择方案，最后由技术决策层通过讨论做出最终的选择。不同的公司或团队的技术决策层可能不一样，反正最后说了算的那拨人就是了。
如果开发投入不考虑成本，只要最好的技术，那技术团队决策层决策就可以了；而如果开发投入要考虑成本控制，特别是创业或中小型公司不得不考虑的因素，那可能还要拉上老板最终拍板也不一定。
第三个问题，怎么做技术选型？
当我们进行技术选型的过程中，我们要关注哪些影响技术选型的因素，这是技术选型中的核心工作。
我们常说最适合自己的技术才是最好的技术，这是真理。当行业中出现多项技术可以完成同样的一种工作时，这时候说明没有任何一项技术能够占据绝对的优势优于其它的技术，否则其它技术没有出现的必要，这是多么正确的废话。
比如完成iOS和Android平台上的App开发，我们可以用Object C / Java这些原生技术栈，也可以用Flutter+Dart技术栈或React Native技术栈，甚至可以用H5的技术栈，哪个好呢？你可能会说，那肯定是原生的技术栈好啊，官方出品各方面的优势最佳。真是这样吗？
用特定平台的原生技术栈写一套功能需要两套开发人力（人员+时间）；如果App大部分功能只是UI/UE+数据类的功能，那么用Flutter或React Native没什么区别，一个人还能干两个人活，效率提升100%，或者成本直接降低50%；如果是内容类的App，用H5也未尝不可，还方便远程动态更新。所以，具体的场景需要具体分析，下面我们来看看技术选型时需要重点关注哪些因素。
一般来说，一个软件技术栈，我们需要重点关注这个技术栈的框架、语言特点、平台支持情况、社区成熟度、技术生态、许可、性能以及技术栈的特性等等，下面来一一说明各个。
1、许可协议，影响程度：一星
技术栈的许可协议，如果是开源协议则各种协议类型差别不大，针对个别特别条款加以注意就好了，绝大部分人关心不上。
如果是商业协议，则可能涉及收费问题，如果可以商务合作，除了考虑商务因素外，还需要考虑技术栈后续是否有平替的可能，比如你的平台引入一个支持第三方入驻小程序的小程序SDK，意味着你App上的第三方开发者也依赖于这个SDK，后期是很难有平替可能的。
如果一个既有开源协议也有商业协议，则要注意了，免费的部分肯定有限制，免费的功能是否能满足所有的需求。
2、性能，影响程度：二星
性能重不重要？既重要也不重要。性能属于追求产品极致体验的附加值需求。大部分流行或商业化的技术栈其实都已经满足的基本的性能需求，如果一个会对内存、CPU造成挑战的有先天缺陷技术是不可能流行的。就比如Flutter性能比React Native好一点，但很重要吗？不见得。除非先天性能的差距影响了功能的使用，否则在技术选型时不建议过度关注。
3、框架，影响程度：三星
我们常说的框架包含了技术栈组织代码的规则、封装的基础组件库和基础Api、编译体系等。对于流行的框架来说，这个因素其实对技术的选型并不形成决定性的影响，因为对于开发人员来说不同的框架之间只有熟不熟悉的问题，而从入门到精通的时间不会相差太大，没有学不会的技术，只有不努力的开发人员。
比如Flutter和React Native这两个技术栈，框架的规范、组件的用法、怎么运行并编译，对开发人员从入门到精通并不会有多大的差距。
这个因素影响的因素主要是开发团队里有没有现成的开发人力，是否可以马上进入开发更短时间内输出成果，是否需要新的培养和招聘。
对于软件框架来说，可能要重点关注的是编译的类型，开发态是否支持JIT直接影响到开发效率、打包上线是否支持AOT直接影响运行性能和保护代码安全的等级。
当然，前面是基于流行或较成熟的框而言，如果对于不成熟的框架，你又不得不纳入考虑，这个因素应该是决定性因素之一。这种情况一般大厂才会考虑，中小厂用不成熟的框架那不是自讨苦吃么。
4、语言特点，影响程度：三星
这个因素其实和框架是差不多的，诸如Objective C这么别扭的语言，只要你熟悉了，开发的时候也是信手拈来。这个因素我认为重点要关注的是语言是否支持面向对象，并且语言是否需要开发人员处理指针这类对开发要求产生质的要求的特性。至于语法糖是否很灵活、很时髦不是最重要的，比如是用java还是用Kotlin，用Objective c还是用Swift，当然，能用Kotlin或Swift最好，毕竟新语言是趋势，但对技术选型也不是决定性因素。但如果对于Qt用的C++，你就得慎重考虑你的团队是否有能力把控得住指针的处理，否则会引起很多问题。
5、平台支持情况，影响程度：三星
产品是否需要支持更多的平台。首先，技术栈是否满足要求，这是决定性因素，关系到是否需要针对某些平台新启一套技术栈，比如React Native官方不支持桌面端，Flutter是支持的，这点Flutter更胜；其次，技术栈对各平台的支持成熟度怎么样？是否符合产品的要求，比如有些产品虽然支持跨端，但有所偏重，比如Flutter在移动端更优、Qt在桌面端和嵌入式设备更优。
这里说明一下，如果你不是大厂或有专业的基础技术开发团队，非不得已情况下，不建议在官方不支持的情况下选择社区的平台支持。
6、社区成熟度，影响程度：四星
这里说社区包括官方支持、开发者互动交流区、搜索引擎或Stackoverflow热度、如Github的官方库。社区是否成熟其实对普通的开发者影响非常大，大部分开发者可能终其一生的编程生涯都是一边学习、一边写代码、一边搜索解决方案的过程，绝大部分不可能存在一部书打遍下天的可能。所以好的技术栈一定有非常成熟的社区，官方对问题有快速的响应机制，或者有第三方提供良好的解决方案，不懂的问题一搜一个准，遇到的坑十之八九已经有趟坑者。
所以Github上的星数量，官方解决issue的数量，搜索引擎的热度等都是很有开发者先择时的重要参考。比如Flutter官方解决问题的百分比会比React Native高；另外，这两者的流行度又比Qt强。
7、技术生态，影响程度：五星
技术生态是指基于这个技术栈的第三方开发者，提供各种能力支持的情况。
这个因素可能对于大厂来说不是问题，家大业大，要什么功能自己开发就是了。
对于中小厂来说可不一样了，做什么都得看看有没有第三方好用的功能插件，如果都自己开发，这开发成本和效率够呛，比如你要用一个实名认证，你会自己开发而不用阿里这些提供好的么？相信理性的开发者都会做出正确的选择。
第三方技术生态是把双刃剑，拿来用的时候好用。一旦出现了问题，要么冒着隐藏的风险做二次开发，要么等第三方开发者升级。比如选择Flutter技术栈的开发者，而对华为的Harmony Next就有点措手不及，即希望Harmony Next支持Flutter，也希望第三方插件开发者能跟上。
技术生态好的技术往往决定了技术选型的选择，当然，如果是付费的商业合作的技术，找对方解决就是了，基本没这个问题。
8、特性，影响程度：五星
特性，就是本技术栈相对其它技术特有的能力，如果某个技术特性和你的需求相关，那这就是影响技术选型最直接的因素。比如React Navtive相对Flutter和Qt的动态更新能力。
以上说了这么多影响技术选型的因素其实是相对的，需要结合产品及开发团队的具体情况考虑。比如以下一个常见的很重要的自身因素：
开发团规模
如果现有和可预见的将来开发团队规模较小，不可能组织基础技术服务团队做技术支撑，那么入门简单、开发效率是最重要的考量之一，比如App开发跨端技术是优选，脚本特性强的语言（如javascript/swift/kotlin）是优选。
其实技术选型最难的是你要对技术本身了解，这点其实大部分人或团队都做不到，大部分开发团队或个人只能熟知一或二个相关技术，所以也就无法从根本上了解各项目技术是否真的适合自己，网上的资料要么是基于理论的说明，要么是从作者本身实际情况做的说明，不信你看看大厂的对比文档往往把性能放在重要位置。所以，技术选型只是开发重要的开始，后期的磨合才是长期准备面对的事情。
最后，技术选型是开发过程中不是频次很高的环节，但很重要，就像万吨巨轮选择了航道，接下来的才能勇往直接。
网友评论