拒绝「技术栈」选择恐惧症
所谓最小化可行产品（Minimum Viable Product,MVP），就是将产品快速推向客户，从客户反馈中不断进行迭代。更重要的是，MVP 也是研发团队进一步完善产品的基础。
但是，在正式代码之前，你需要选择今后支撑产品的 技术栈，也就是要选择好整个产品每一层所要应用的技术语言、架构等。
技术栈的选择往往是创始人面临的艰难问题。无论是技术人员还是非技术人员，如果不具体了解每个语言和架构的特点，面对现在如此多元化的IT技术，简直能逼死纠结症患者。而且，如果选错了语言或者框架，很可能会导致较为严重的后果。
实际上，在选择时需要考虑的因素并不多。其实通过简单的分类，就可以将选择范围缩小到可控制的几个技术组合内，进而将每种技术与正确的应用范围相对应。
首先，你得了解「技术栈（tech stack）」的定义。
一.什么是技术栈？
技术栈是用于创建 Web 或移动应用的软件产品与编程语言的组合。应用通常包含两个软件组件：客户端与服务端，也称为前端与后端。
应用的每一层都建立在其下一层的功能基础上，整体构成了一个栈。上图显示了典型技术栈的主要区块，但是也可以包含其他支持组件。
二.后端技术栈
后端包含驱动应用运转的业务逻辑。用户永远都不会与后端直接交互，所有的信息都通过前端来传递。
最著名的后端技术栈要属 「LAMP 栈」（Linux, Apache, MySQL, PHP）。最近，该栈也出现一些变形：使用 Ruby 或 Python 取代 PHP 编程语言。
选择编程语言时得选定对应的 Web 框架。框架用处极大，能为开发者提供多种经过审查的常见 Web 功能，包括用户验证、数据存取等，是的开发无需从零开始。
常见的 Web 框架有：
| 框架 | 语言 |
|---|---|
| Ruby on Rails | Ruby |
| Django | Python |
| Node.js | Javascript |
| Laravel | PHP |
| .NET | C# |
三.前端技术栈
前端是应用与用户交互的图形化实现部分，并且是用户最直接的体验。交互可通过 Web 浏览器或移动 app 进行。在创建 Web 应用时，前端栈包含：
- HTML （标记语言）
- CSS（样式表语言）
- JavaScript（脚本语言）
前端框架的选择很多，我们的建议是：
- JS 框架需包含用于创建丰富且良好的交互 Web 体验的工具。
推荐使用: AngularJS, Backbone.js, ReactJS - 展示框架需提供标准化的格式，用于创建简洁又不失美感的响应页面。
推荐使用：Bootstrap
对于移动应用，iOS app 均用 Objective-C/SWIFT 创建，Android app 则使用 Java 创建。
四.我应该如何选择技术栈？
如果你是不懂技术的创始人，咨询开发者并听从他们的建议选择技术栈似乎是不错的选择。然而，开发者可能会对自己擅长的技术工具有所偏爱，或仅仅根据技术优缺点而非业务需求评价技术工具。
换个角度讲，遵从下面的三个步骤评价不同的技术选择可能更为客观。
1. 移动还是 Web？根据目标用户群进行设计！
现如今，超过 60% 的网站流量来自于移动设备，25% 的美国人只通过移动设备上网,这个趋势还将不断扩大;2015年是全面『无线化』的一年，在BAT（财报）几家公司都已经超过 50% 的流量来自移动端，这次 双11 更是占到了68.67% 无线交易。因此，推出移动版应用只是时间的问题，而不是要不要的问题。
然而，不要只依赖总体的统计数据，而应该想想你在设计 MVP 时必须的关键因素，以及这些因素在产品中的价值定位。用户是更可能在移动中通过手机使用你的产品？还是端坐在办公桌前使用它？
通常，你的 MVP 应该先快速发布于一种平台——移动或网页端，当产品获得认可之后，再根据反馈投资搭建新的平台并进行良好的维护才是理智的。
确定整体规划之后，用户的使用模式会指导你进入移动优先，仅保留移动端，或移动稍后的设计方案。
1）移动优先设计
「移动优先设计」意味着搭建一个 Web 响应应用，能适应所有尺寸的屏幕，但首先保证移动端屏幕的 UI 最为宜人。
Web 响应应用可通过谷歌搜索或共享链接快速发现，无需下载任何安装包即可使用。相比于本地应用，他们的开发成本更低，更易迭代，能快速验证产品的价值。
从 Web 响应应用入手，如果你的产品：
- 服务于桌面与移动端的广泛用户
- 包含可用于 SEO 的丰富材料
- 具有易于在手机浏览器使用的简洁 UI
例如：天猫, 爱奇艺, github
2）只开发移动端
在仅开发移动端的设计方法中，MVP 只是一个在应用商店下载的本地移动应用。移动端用户期待看到美观流畅的界面，当然良好的用户体验也是必不可少的。
通常的建议是先开发基于 iOS 的 MVP，之后再开发 Android 版本。尽管 Android 在美国的市场份额为52%，在全球更是高达80%，但支持数百种不同的设备需要投入更多的开发成本。如果试试为了验证产品价值的话，iOS 用户其实绰绰有余，而且他们相比于 Android 用户更为投入，花在手机上的时间是后者的四倍。并且同时发布两个版本的应用需要更多的营销时间，而且每次产品迭代都要投入双倍的工作。
从本地app入手，如果你的产品：
- 主要使用在移动端
- 需要使用相机、GPS 或加速度器等设备特征
- 会受益于消息推送、零星购买等实时交互
例如：Instagram, WhatsApp, Uber, Waze
3）移动端后设计
在某些情况下，MVP 应该是传统的 Web 应用，暂时无需考虑移动设计。比如，许多 SaaS 产品的目标客户是企业用户，这些用户主要通过台式机或个人电脑的浏览器与产品进行交互。附带的移动应用主要提供互补功能，可以稍后再开发。
从传统 Web 应用入手，如果你的产品：
- 主要通过台式机或个人电脑进行交互
- 需要复杂的用户界面
- 会接收电子表格或大图片文件的上传
例如: MailChimp, ZenDesk, Xero
2. 考虑业内的现有工具
打造成功的 MVP 的关键是减少市场推广的时间。利用现有的工具可以有效缩小工作范围，使产品推广更加简单。
在选择编程语言与其他后端技术时，首先考虑业内最好的开源工具，并以其技术栈为参考。
例如：如果你只想发布一个简单的本地移动应用，则应该使用 Parse 或 StackMob 之类的后端服务，而不是自己开发。
不要只关注市场份额，还应了解 Github 中的贡献者数量与 StackOverflow 中的问题数量，从而了解其近期发展情况。最好的工具背后应该有一个生机勃勃的开发者社区。
比如，在电子商务市场，Magento 的市场份额最大，达 25%，拥有 25 万安装基数。Spree 则是后起之秀，仅有 5 千安装基数。然而，后者拥有超过 500 个贡献者，是全球 50 大开源项目之一。如果你准备开始一个新的电子商务项目，Spree 或许是一个更好的选择，同事 Spree 是以 Ruby 语言写就的，这也会影响你的后端语言选择。
3.谁是项目的builder？
缺少开发能力是许多初创企业早期的一大挑战。因此，是否拥有高效的开发团队也是决定技术栈选择的一大因素。
不同的技术栈会吸引不同的研发人员，进而影响公司文化。许多有才的开发者热衷于使用最新的工具，而极力避免他们认为缺少创新的工具。比如，PHP 一直是开发 Web 应用最常见的语言，但其名声并不好，以致于一些公司会因为使用它而道歉（这是真的，并不是玩笑哦）。
在选择技术栈时，要确保业务领域内有足够的有才能的工程师。像 NodeJS 这样的新兴技术可能会引来你中意的文化契合，但也意味着招聘时面对的人才库相对有限。
开发人才的数量也与行业有关。比如，由于监管与合规性问题，金融技术平台一直以来都使用 Java 或 .NET 开发。即便这些语言常常被初创社区所看不起，如果你准备开发金融行业产品，选择它们还是有许多好处，可选的开发人员也会很多。
4.我的技术栈容易扩展么？
选定技术栈就好像做出承诺一样，无法轻易改变，因此关于未来形势，诸如扩展性、性能变化的考虑也很常见。然而，在 MVP 阶段就考虑这些问题显得有点操之过急了。
许多性能问题其实是应用设计缺陷，而非技术选择导致的，并且这些问题通过性能调优就可以解决。而且，随着产品的发展，惊醒性能优化的预算也会逐渐增加。
5.是否有必要选择强大的前端性能优化工具？
当然有必要！
且不说后端，先从前端页面来看，现在国内的主流前端包括：pc端、移动微信端、移动浏览器、移动应用的webview等多种场景，普通的性能优化工具根本无法同事支持兼容诸多使用场景，同时，很多工具只是简单的打个分数，根本无法定位问题！
那么，问题来了。。。
难道你能忍受只能针对一种使用场景的工具？
难道你能忍受像 yslow 这样的无法进行综合比对的一次性工具？
难道你能忍受只能评分却无法定位问题的工具？
从国内来看，Browser Insight 这个工具提供了统一的视图，全面涵盖 pc端、移动微信端、移动浏览器、移动应用的webview多个场景。针对不同的前端场景，都可以进行相应的监控与分析，甚至可以精确到代码级，让前端性能监控不再纠结。
简单的给大家看几个 Browser Insight 的功能界面。
目前，OneAPM 针对前端性能的优化产品，Browser Insight 已经免费提供给大家使用了。同时包括针对应用服务器性能优化 Application Insight 产品以及针对存储服务器性能优化 Cloud Insight产品也都提供了免费版产品，希望能够帮助用户不断优化，真正意义上做出 MVP 的产品！！！
原文链接：http://svsg.co/how-to-choose-your-tech-stack/ 作者：Gil Edelman，本文系 OneAPM 工程师编译整理。
