创业公司创业团队钟节点前言大家好，我是Scott。2016年9月25日，我在杭州大搜车总部举办的杭州节点派对上分享了一个话题-《创业公司撸 Node》。分享完后，我又以文字的形式记录下来，分享给没有到会的朋友。也方便大家通过搜索引擎和一些技术社区平台阅读本文。写在前面，谢谢太郎和大搜车给我这个机会认识大搜车的大家。说实话，出道以来，这真的是我第一次正式公开演戏。尤其是在这么多大牌面前装逼。有一天，当你进入创业团队，今天我想跟大家分享的话题是现阶段Nodejs工程师在创业团队中的认可度，以及如果有一天你进入创业团队，应该用什么标准什么时候做技术选型？判断，是否使用Nodejs开发，如何跟进技术演进。特意加了前端反击的副标题，在本站做一个小调查。过去和现在做过前端开发的请举手。让我们看看有多少人从事过前端工作，现在从事Node.js工作。.现场举手的人超过一半，前端这个职业真的牛逼。我的职业过渡还可以。首先，让我自我介绍一下。和其他人一样，我曾经是一名前端工程师。从2010年开始，我在阿里妈妈的前端工作了四年。后来做了很多跟广告相关的前端页面。后台创意投放管理系统对接，广告效果模板的制作优化等，如果你去优酷、微博、各种影视、小说新闻媒体网站，应该都有见过这样满屏的印象在豆腐块的淘宝广告上打滚。哈哈，不好意思，2014年之前，你在网上看到的豆腐广告，几乎70%都是我做的。你在淘宝上搜索鲜花、内衣、硬盘、种子。当我访问其他网站时，我可以在豆腐块中看到类似的产品。我当时的工作就是开发这些模板的样式，优化这些模板的特效，测试在各种终端设备上的兼容性。数据需要与各种算法进行比较。引擎团队就各种异步数据格式达成一致。在业务上，需要考虑复杂的参数加解密、二跳透传、cookie读取定向等，实现不同推广场景下的异步交互方案。最后，根据各种广告系统的访问和到目标站点。所以一开始我还是一个很纯的前端工程师，后来为什么开始折腾Nodejs呢？我们可以看上图右上角的轮播图。它由两部分组成，顶部和底部是轮播产品。列表图，下面是推广的产品关键词，是两个独立的数据接口，大概属于两个完全不同的数据引擎团队，从前端开发的角度来说，我需要发送两个请求来获取和控制展示这两个数据接口分开。从后台开发的角度来看，这两个接口应该是相对独立的，互不影响。因此，虽然我们前端工程师希望将两个界面合并为一个界面，但是很难推动后端工程师团队像我们这样针对某个模板开发一个界面。这个接口会统一获取两个接口的数据并合并，然后交给前端展示。因此，我们很难从起码请求数量的层面入手，优化这则广告的展示速度和完整度。有时图片先出来，有时关键词先出来。如果同时等待，某个接口挂了怎么办？然后等待超时，进入Get基本界面或者类似的界面，用户已经离开了。但是这样的模板在全网每天都给阿里带来巨大的收益，而且它的生命周期可能只有2周，2个月后就会被下架换成其他模板，所以从维护的角度来说，是后端工程师确实很难及时跟上前端和产品层面的频繁变化。在收益方面，需要和后端工程师进行艰苦的沟通和解释，非常费力，协作成本居高不下。但是现在有了Nodejs，我们试想一下，如果用Node作为接口层，它会决定调用哪些接口，合并哪些接口，哪些接口使用哪些后台数据。是这样吗？已经解决了，这个我就不讨论了，可能涉及到公司的保密协议，因为我后来离开阿里创业了。创业后，我开始了职业转型。这3年，我一直在创业公司用Nodejs开发产品，逐渐从一个标准的前端开发工程师转变为一个会用Nodejs的开发工程师。下了不少功夫，想知道我的技术成长之路，可以看看之前的文章——4年前端狗，2年CTO，进入一个新领域，作为一个新人，要踩很多陷阱，有的是必须的，有的是必要的没必要踩，我把自己的一些经验整理成视频放在MOOC网站上。看这里的地址：http://www.imooc.com/u/108492/courses?sort=publish刚入行的可以去看看。里面的知识点可能有点陈旧，讲解可能不是很严谨。您可以选择了解过程和项目想法。所以现在，我是CampusRoom网站的技术总监。您可能没有听说过CampusRoom。没关系。估计有同学听说过Moveha。这几年不管是CampusRoom、Moveha，还是微信服务号，包括其他一些大大小小的项目都是用Nodejs搭建的。整个创业团队也充分体验到了使用Nodejs搭建网站或启动项目所带来的敏捷性。效率高，其中之一就是小case。近年来，一些欧美国家不太安全。为了让学生和家长对当地的生活环境有一个安全的了解，我们用Nodejs快速搭建了一个小型爬虫系统，对部分州市的警局犯罪数据进行爬取，经过合理分类后给出数据可视化效果和评级。这个功能的产品价值可能非常大，但是实现成本非常非常小，效果如下图：Nodejs对公司的影响，但整个行业对Nodejs的态度是什么？验收情况如何？我们再举一个例子。您可能已经在CNode论坛上看到过此招聘信息。你喜欢的和大搜车上的我都截图了。最后一张是我发的，是Moveha的。招聘，哦，我就说Moveha是CampusRoom的前身，CampusRoom是从Moveha孵出来的。阅读量最高的帖子现在有超过40,000次浏览和400多条评论。这个帖子给我带来了100多份简历。现在我公司所有的工程师都是从这个岗位招聘的。这篇帖子前后——2014年秋天，在论坛或者社区里，很多公司对Nodejs工程师的认知，包括他们的价值定位，还不够清晰。从招聘氛围就可以看出。在我发了这个帖子以后，很多公司在CNode上发帖的态度都很高，一副你来我往的样子，而且他们公司团队文化的介绍也模棱两可，薪资区间也从来不敢。自从发了这个帖子之后，论坛上的招聘帖也渐渐接地气了，也开始诚恳了。工资不到20K的公司连发帖都不好意思。从这件事情上，也能体现出工程师群体的结果导向的本性，根本行不通。如此一来，良好的市场认可度自然容易被人们所接受。CNode上的大量招聘也从侧面证明了这一点。在过去的三四年里，Nodejs工程师得到了越来越多的认可和重视。一份工作很值钱吗？高，其实不是你说了算，也不是我说了算，而是市场。让我们来看看indeed上统计的职位需求变化趋势。第一张图展示了对Nodejs的需求变化，第二张图展示了对Fullstack的需求变化：这两个工作，即使在今天，依然处于井喷式的暴涨阶段，整个市场对于Nodejs工程师已经有了足够的认可，所以大家的事业黄金期真的到了。两三年后，Nodejs工程师真的会遍布各个公司的大街小巷。现在正是跟上这股潮流的最佳时机。那为什么那么多公司这么认可Nodejs工程师，尤其是中小团队，尤其是创业团队，为什么可以选择PHP，同样敏捷的Ruby，还有更成熟、更容易招到程序员的Java？Python，却要努力招紧缺的Nodejs工程师，尤其是具备前端工程师能力的Nodejs工程师？答案很简单，因为使用Nodejs开发一个新项目会非常高效和敏捷。无论是从最终的用户体验，还是上线后的产品迭代节奏，使用Nodejs都具有巨大的成本优势。对于初创公司来说，成本是一个非常敏感的问题。市场上有成千上万的初创公司在等待被喂养。很多CEO也希望有好的用户体验，更短的研发周期，更快的迭代节奏。说白了，只有通过这种快速迭代、小步快跑，才能在与同类产品的大公司竞争中获得时间差优势，获得最快的用户反馈和市场响应，最终才能在市场上杀出一条血路。竞争和夹缝中。说句流血话，现实确实就是这么残酷。快速推出产品，熬过最困难的阶段，找准产品的盈利点，抓住目标用户群，桌面上有各种数据，在融资上自然有优势，然后改进就够了优化技术堆栈甚至更改开发语言的缓冲空间。所以我们Nodejs工程师的核心价值，尤其是对于初创公司来说，就是能够快速生产，迭代更快，前后端通吃，为初创公司节省巨大的人力成本.这就是Nodejs在市场上如此受欢迎的原因。之所以火爆，是因为创业公司选择我们，不仅是因为它能最快满足创业团队的场景，也是因为Javascript也是唯一可以跨越前后端的选择。以一种语言实现产品。关于Nodejs的适用场景，它的优缺点，它的开发和维护成本，相信做了这么久大家也有自己的看法，就不赘述了，大家往下看吧。什么样的创业项目更适合Nodejs？也就是说，Nodejs被认为是创业团队立项时的技术选型。它有适用的边界吗？如果有，界限在哪里，衡量的标准是什么。如果我们在创业公司，我们要确定用Nodejs来启动一个项目，那么应该用什么标准，或者说用什么标准来衡量，Nodejs怎么用，框架怎么选，框架怎么跟上版本？太多的问号在脑海中回荡。我个人认为可以将它们简化为以下三个问题，可以解决从决策到执行的过程：1、是否先使用Nodejs？什么样的创业项目适合使用？Nodejs，哪些不适合用，我们从这三个因素来衡量：1.预期的迭代节奏任何产品，在立项之初，都有其特殊的业务背景和业务目标。在这样的背景和目标下，会对它给予一些期待，希望它以什么样的形式，开发上线需要多长时间，上线后需要多长时间更新迭代版本。这些都很容易理解。如果是展示类的，就不用吐了。怎么增加功能，不需要经常修改升级，所以没必要用Nodejs，PHP、Ruby都行。2.团队工程师的能力我们知道，和这个世界上的大多数事物一样，工程师的能力大致符合正态分布。除了弱的，比如3年前的我，除了强的，大部分工程师其实都在这个中间地带，就像现在的我，可能对Nodejs和周边生态的把握比较好，但不是特别好，而Nodejs是一个新的职业方向，没有足够的时间在火爆的市场中沉淀下来，所以大部分的创业团队都没有足够的经验丰富的Nodejs工程师，这意味着我们在快速发展的过程中往往会面临更高的业务风险。商业遭受灾难性打击。这一点其实很多企业都忽略了。目前和未来六个月整个团队的规模，团队成员的技术背景，自主学习的能力，以及对新技术升级的接受程度，如果不能很好的驾驭Nodejs，具备自学能力如果弱，则需要慎重考虑。3、与产品的匹配程度其实，创业的产品往往很少做规模大、难度大，所以适合的种类很多。与其认为那些可以用Nodejs开发，倒不如反过来看。非常适合用Nodejs开发。排除了这些场景之后，你就可以评估剩下的是否可以使用Nodejs了。我在这里列出了几个。其实如果往这个方向走，可能不会只有这4点：极高的并发，密集的CPU运算，高安全，高可靠，内存精准控制和并发的释放是Nodejs的强项，高吞吐量，但是如果你上来应对爆炸性的井喷场景，当你需要堆机器的时候，很明显这些非Nodejs领域的软实力会消耗工程师太多的时间和成本。来限制业务的发展。如果一定要给一个数字，可以用10万作为一个衡量点。如果并发数大于10万，就要慎重评估。对于大循环的数据结构，需要长时间的计算，对CPU依赖性强，导致时间片释放慢，尽量不要用Nodejs来做。你可以把它交给Scala、Go，甚至Java。和C++来做到这一点。举个例子，比如出行路线的实时计算，用户出行路线的推荐需要在多个维度上根据不同权重的因素进行算法推演，考虑到用户的性别、偏好、预算、预期出行等模式、天气、当地景区分布、目的地是否有类似G20的会议等因素，都可能要靠一些大数据做支撑。这时候，用户不能等待太久，而是希望能马上得到路由报告。在这些场景下，我们这些能力值接近中档的工程师，还是不要胆大妄为，避免使用Nodejs。安全性和可靠性也是如此。在一些支付或者银行对接的场景下，服务的稳定性非常高。不能有任何可能因为异常导致的进程挂起，导致数据不一致。如果其他语言已经有很好的在线解决方案的话，那么Nodejs也只能做自己擅长的事情，把这些交给其他更专业的技术去实现。Nodejs只需要调用接口即可。项目做大后，代码中的隐患或风险就会增加，一个疏忽就可能导致内存泄漏。如果业务层面对内存非常敏感，会因为内存使用不精准导致对外服务质量不稳定。这些对于业务来说是不可接受的，因此应仔细权衡此类场景。其实考虑到创业团队的具体起步方式、工程师能力的不平衡、产品迭代的节奏，只要是稍微苛刻的场景，就应该多想想使用Nodejs除了效率之外，是否能带来高价值.如果答案是否定的，我们必须谨慎使用Nodejs。我们始终需要在工程师的能力、Nodejs与业务的契合度和匹配度、公司的产品节奏之间找到一个平衡点，而这个平衡点会随着业务的扩大和团队的壮大而不断变化。在变化中，我们需要不断地评估和反思。那么让我们回到产品本身。一旦我们排除了这些场景，我们就可以大胆的使用Nodejs了。换句话说，不是我们，而是更多的先行者和执行者在Nodejs阵营中投入了巨资，比如下图：全球太多的大公司已经在使用Nodejs了。即便是微软这样一个相对封闭、刻板的软件帝国，在Nodejs上的投入也很大，对开源的包容度也很高。Nodejs有很多有用的工具和服务，甚至fork一个Nodejs来启动一个新的引擎。更另类的是，发起太空任务的美国国家航空航天局，使用Nodejs开发一些应用程序或运行一些系统。即使在2016年Github评选出的最受欢迎的项目中，也有将近一半是Nodejs相关的项目，或者使用Nodejs做一些构建工作。一言以蔽之，Nodejs已经上天了，前前后后，它的火爆只是我们看到的一个现象。其背后是其使用门槛低、协作成本小、开发体验好、性能好。表现。2.丢掉历史包袱。虽然有那么多我们乐见其成的方面，但作为工程师，我们还是需要谨慎。当我们决定使用Nodejs时，如何选择版本或者语法层面的一些编程习惯。毕竟JS编程总是太复杂了。灵活，有很多人纠结多年的问题，而JS的快速进化带来了更多的编程方向。站在这个十字路口，向前一步未必是大海，向后退一步未必是断崖，但向前总比向后退要更接近未来。举个简单的例子，让很多工程师头疼多年的就是Callback。这是一个老式的问题。不同的团队、不同的项目历史背景、不同的技术风格，显然对Callback有着不同的态度和选择。比如太郎哥对大搜车的Callback就比较宽容了，因为几十万行的历史代码老老实实交由我维护，不敢乱来。那么我个人的看法，Callback明显是不讨人喜欢的反人类的。我的观点是，如果创业团队没有历史包袱或者历史包袱不大，就应该果断舍弃，可以直接上Promise，因为只要把包袱背上了身体只会越来越重，越来越不敢扔掉。如果你比较激进，可以混合使用Promise和GeneratorFunction；如果你比较激进，可以结合Babel使用async/await；我们来看一个例子，通过这个搜索框，输入一个学校或者城市，就可以搜索到学校周围或者城市周围的房子。我这里对搜索的实现路径做了最大的简化。只有两种类型。未来持续升级的产品形态会更加复杂，比如精确查询和模糊查询，以及城市和学校以外的经纬度直接查询。标题查询、邮编查询等，他们的搜索显然是异步的。所以这个简化的例子，第一种方式，进入学校，搜索学校，拿到学校后搜索周边房源。第二种方法是搜索城市。搜索城市后，搜索城市的大学，然后搜索城市的房源。由于我们不知道用户输入的是学校类型还是城市类型，所以我们需要同时检查，学校的结果是主要的。如果采用Callback的方式开发，很容易写出这样的代码，通过嵌套强行锁定搜索优先级和并发与非并发的顺序。当然，每次异步查询都要处理一个post-postederrorobject判断，这些error不能合并，要分别处理5次，有的会打断这个过程，有的可能不会。另外，如果使用eslint，这里的err需要单独命名，名字不能重复。从维护的角度来看，如果以后要在这里调整搜索优先级，那就很头疼了。我相信每个人都遇到过这些事情。我们来看第二段代码。在本段中，我们使用Promise和GeneratorFunction结合后的升级版本。显然，这次升级直接解决了Callback的几个痛点。首先，可以实现逻辑分离，升级维护更方便。如果你先搜索城市作为第一优先，你可以直接把整个代码扔到下面，另外还可以结合错误捕获，当然也可以做更细粒度的控制。同时，比如搜索城市大学和城市房源可以并行化，我们可以使用Promise和Generator自然而然的去做这件事情，当然也可以使用callback来集成eventproxy或者asyncforprocess控制，但会进一步引入代码复杂度。其实只要解决了Callback的问题，我们就向前迈进了一大步，因为我们引入了Promise，GeneratorFunction，甚至进阶到await和async，也就是说底层的Nodejs版本也会有更大的升级，带来更多编程思路的改变。3.Nodejs的跟进和升级那么说到Nodejs的版本，我的观点是要跟上Nodejs的大版本，因为2016年站在这个节点上，Nodejs其实经历了一个七年之痒。我比前几年快乐多了。我可以根据自己的经验这样说：我在2013年开始兼职业务，从事我们公司的项目。当时Nodejs版本是0.8，一直在用，2014年7月才从0.8升级到0.10，然后一直用到2015年春节，义无反顾，从0.10升级到0.12，并且一直用到2016年1月，再次升级到4.x，还停留在4.x的版本状态，这几个大版本周期我都经历过，感觉是这样的。从0.10到0.12是一个比较大的提升，从0.12到4.x是一个巨大的提升，从4.x到6.x也会是一个巨大的提升，当然Nodejs有它特殊的历史过程，比如在0.10版本，存在重大安全漏洞，不升级将无法使用。在4.x发布之前，Nodejs社区也分裂成io.js阵营，长期与之抗争，后来又合并。规范化，只要出正式的LTS版本，在第一个LTS版本之后，可以观望一个月左右，再考虑升级。当然至少在LTS版本升级前一个月，我们本地的开发环境应该已经切换到这个大版本了，我们就在本地开发测试。升级到6.x后，我们都将面临6.x版本甚至即将到来的7.x版本。官方还列出了一些重大变化。下面说一下我认为需要注意的几点。1、从V8到5.0.x的每一次版本升级都不例外。它将优化和改进整体性能，包括安全增强、文档改进和测试用例覆盖，但没有重大引擎升级。牛逼，Nodejs作为Javascript运行环境，代码解释依赖ChromeV8引擎，所以ChromeV8的能力基本限制了Nodejs的能力，所以这次对比4.x，6.x的底层引擎v8升级到5.0.x，这意味着整个6.x的性能将与4.x有很大的不同，因为底层v8本身的许多缺陷和bug已经通过重大升级得到修复。2.覆盖93%的ES6特性6.x覆盖了93%的ES6特性，也就是说我们可以大胆的使用es6几乎所有的特性，比如解构，剩余参数，类，super关键字，我们知道，很多时候我们在使用的时候一个库或者框架，甚至是一门语言，经常会用到50%、60%、70%的API，完全可以满足我们的业务需求，所以ES6的覆盖率这么高，我们确实可以大开眼界，拥抱ES6.3。模块加载比4.x快4倍。模块加载比4.x快4倍。如果你是项目负责人或者技术组长，那么这对你来说绝对是有意义的，可以说我们在线申请启动或者重启的时间会更短，这样我们在线服务的切换对用户来说会更顺畅，重启造成的波动也会被感知到更小。但是，除了从语法层面避免历史的复杂性，我们更需要关注Nodejs版本本身带来的巨大差异和变化。查看Nodejs表。从现在到2018年，我们自己的技能在不断的增长是的，同时我们对ES6的使用和理解也会越来越深入，所以我们应该选择一个未来的版本来切入技能栈。老实说，未来两年我们会继续做6.x版本，如果我们运行我们的项目，那么接下来的几个月是升级线上版本的缓冲期。像搭积木一样搭建Nodejs应用当我们把上面的问题考虑清楚后，剩下的就变得容易多了。到了2016年，我们已经不像2014年之前的大跃进时代了，太多的变化造成了太多的不稳定，现在社区的生态环境已经相当完备了。从静态资源、web框架、模板输出、数据库中间件到第三方通信、消息推送、各种SDK和CDN内容分发，优秀的类库太多了，我们可以做一些适当的定制化和改造，将它们大胆地用在该项目。然而，当我们将魔爪伸向后端，使用Nodejs构建企业级应用时，我们收获的不仅仅是更多的价值，也收获了更多的责任和信任。后端底层甚至团队规范需要我们花更多的时间去了解对接的方式和接入的阶段。我们不需要精通，但我们需要基于备份的常识。这些软技能是我们成为一名优秀的Nodejs工程师必不可少的要素。最后简单总结一下Nodejs在创业公司的使用。我们把运维、集群管理、性能调优等处理得当，传统语言已经做得很好很成熟了。公司可以由前端团队带动，使用Nodejs来接管数据访问层和渲染层。公司做规模以后，可以靠更多的资深工程师和原有团队的积累来做日志，监控系统，分布式服务接入这些东西，Nodejs的实现需要前端工程师，Nodejs工程师，以及强大的运维锤，了解更多JS以外的技能，比如数据库，系统设计，接口服务，比如团队标准化协作流程等等。在大公司，你可以朝一个方向去挖掘，但在小公司，你需要放眼世界，为未来做准备。不管是哪一种技术背景，如果有一天你进入了一家创业公司，你可以在项目开始的时候做一个大胆的假设或者推论，假设你把赌注押在Nodejs上，你会得到更快的吗？更好的结果，如果是，请毫不犹豫地选择Nodejs。
