技术栈评价体系

现在越来越多的新技术栈出现，时不时要做调研，做评价，慢慢摸到了一些思路。

维度

常见的评价维度其实都集中在技术上，然而作为业务承载的根基，技术栈的评价维度完全不应该只有技术向评价，而且技术向评价根本不是重点。
目前看，应该有三个方向：产品向、技术向和开发向。

产品向

产品同学通常对技术栈本身其实没有特别的要求，但是落到他们的利益上，技术栈需要满足快速迭代这个核心需求。快速迭代主要是，写得快、发版快、收集反馈快。所以评价要关注：

• 动态化，最高需求其实是动态化。就是发板快，细微的改动不需要跟随发板。这个对于强数据驱动公司来说非常重要。
• 开发速度，包含两部分。一方面是不是能保证单端开发够快，一方面是能不能用跨端提高整体交付效率。
• 收集反馈，一般情况下是收埋点数据。这里最重要的是数据能双端对齐。

基于这些评判点，web其实很不错，然而web在移动端是半死掉的。

技术向

技术其实指的是技术leader，他们的关注点主要是：人力成本、技术控制的产品体验和技术管理成本。

• 学习成本，上手快。
• 招聘成本，会的人多还便宜。
• 使用意愿高，即使有人不会，但是不会拒绝学习/使用。

这几点形成了构建团队成本。
基础体验好，比如内存、包大小、fps这些。如果根上这些东西都很难做好，那技术也很难同意使用。这些点可能是web活的没那么好的原因。
最后是技术管理成本：

• 可维护性，技术栈其实决定了维护和迭代成本的下限
• 扩展性，从一个技术栈衍生出其他技术能力的可能性。比如node.js之于前端。

开发向

面向一线开发，通常技术调研会严重偏科到这里。

• 开发体验，包括打包、ide、语言、文档、约束、风格等。
• 开发效率，包括三方库、稳定性、系统API、自建基础设施等。