算法
第一个错误的版本
你是产品经理，目前正在带领一个团队开发新的产品。不幸的是，你的产品的最新版本没有通过质量检测。由于每个版本都是基于之前的版本开发的，所以错误的版本之后的所有版本都是错的。
假设你有 n 个版本 [1, 2, …, n]，你想找出导致之后所有版本出错的第一个错误的版本。
你可以通过调用 bool isBadVersion(version) 接口来判断版本号 version 是否在单元测试中出错。实现一个函数来查找第一个错误的版本。你应该尽量减少对调用 API 的次数。
示例:
给定 n = 5，并且 version = 4 是第一个错误的版本。
调用 isBadVersion(3) -> false
调用 isBadVersion(5) -> true
调用 isBadVersion(4) -> true
所以，4 是第一个错误的版本。
我的解法：
var solution = function(isBadVersion) {
/**
* @param {integer} n Total versions
* @return {integer} The first bad version
*/
return function(n) {
var left = 1;
var right = n;
while(left <= right){
var mid = left + parseInt((right - left)/2, 10);
if(isBadVersion(mid)){
right = mid - 1
}else{
left = mid + 1
}
}
return left
};
};
最优解法，在判断right 时多判断一下，mid - 1 是不是正巧是第一个错误的版本；
var solution = function(isBadVersion) {
/**
* @param {integer} n Total versions
* @return {integer} The first bad version
*/
return function(n) {
var left = 1;
var right = n;
while(left <= right){
var mid = left + parseInt((right - left)/2, 10);
if(isBadVersion(mid)){
if (!isBadVersion(mid - 1)) {
return mid;
} else {
right = mid - 1
}
}else{
left = mid + 1
}
}
return left
};
};
weex-eros
选型
项目在做技术选型的时候，目标是要开发我们公司的 APP，那个时候已经成熟的技术方案有 webView 嵌套，hybrid 应用，RN/Weex 的混生，原生应用，现在还出现了 flutter、WebAssembly。当时团队内部的情况是客户端同学只有两个，而前端同学有八个，业务的量级是一百多个页面，开发周期是一到两个月的时间，首先是开发成本和效率的问题，完全依赖原生开发同学，或者立马招人风险都不太可控，那我们可能需要考虑的是前三种方案，尽管这会牺牲一部分用户体验，而在当时的环境下，RN/Weex 是用户体验最优的，那我们就会考虑优先选用这种方案，当时 RN 从技术成熟度、社区、文档各方面都要优于 Weex，但是我们之前所有的技术栈都是基于 Vue 建立的，所以我还是优先考虑了学习成本和接入成本的问题，也为了完善整体的前端技术架构。
然后很快的了解了一些 Weex 的优缺点，那个时候并没有对源码进行过多的了解，只是从应用层面上看，是否能完成我们的目标，学习成本，接入成本，开发体验，性能监控和容错等问题，了解之后发现并没有多大问题，我很快的尝试了搭建一个 demo，在 demo 跑起来的过程中并没有遇到阻断性问题，通过周末的时间 demo 就跑起来了，然后分别让团队的核心成员完成一个稍微复杂的页面和团队能力较弱的成员完成一个简单页面，大约一个多工作日，两个页面基本都出来了，加上那个时候 Weex 说他们抗过了双十一，至少让我们觉得 weex 是可行的。
定位
Eros 是根据我们业务 APP 解决方案孵化出来的开源项目，基于 Weex，但是 Weex 更像是一个技术方案，提供基础的机制和功能，而我们的解决方案定位是一个业务开发的解决方案，落地到真实开发环境中。
完善功能
框架上设计了 weex 如何在不需要用户做任何改动的情况下直接写业务代码，并且最终打包上线。
扩展了 weex 的开发能力，配合常规业务需求扩展了 Component 和 Module，扩展了本身 weex 的能力。重新设计了插件化，设计第三方插件接入的方式，让开发者向我们贡献了很多插件，丰富了本身 Eros 的社区，提升 Eros 的业务能力
服务支持上，设计了热更新方案并配备了服务端方案，能支持直接部署，客户端的监控数据接口暴露，使用方能直接接入使用者的监控系统。
梳理了开发规范，重新设计的了配套的脚手架，完善了 weex 文档上的一些不足。
开源收获
混合应用的技术方案核心在于稳定的壳，壳足够稳定就可以减少发布提高业务推进效率，为了稳定壳所以我们开源，作为小公司开源可能和大公司不一样，大公司开源更多的是自己踩了坑之后，将方案开源展示技术实力，树立行业影响力，吸引更好的人员。而我们开源希望吸取到三方面的知识。
一：让社区的开发者来帮我们测试我们底层的壳 bug 以及方案设计是否符合大家的预期，收集外界的需求，我们看我们的业务未来发展是否需要，符合我们未来的业务发展，我们也会提前开发，待有业务需求的时候直接能上线，这方面主要是从技术层面稳定壳。
二：weex 的方案由于多方面的问题一直被社区或者大家诟病，我们期望通过我们的方案让开发者跳过 weex 本身的诸多问题，让更多的开发者通过我们的方案去使用 weex，从而壮大 weex 的社区，推动 weex 本身的发展，从而让我们壳依赖的 weex sdk 更加稳定。
三：通过开源的方案让社区来检验我们的方案设计能力和开发人员的技术能力，通过提升大家的技术能力，同事让社区来检验，并且我们也期望逐渐具备一些行业影响力，并且通过行业影响力吸引更多优秀的人加入。
实际收益
我们的开源方案成了 weex 社区最大的业务性解决方案，壳稳定到业务需求几乎不需要动客户端。开发效率和稳定性都有了很大的提升。开发者上千人，star 上千，上线几十个 APP，有公司将我们的方案纳入招聘 JD，也有很多社区里的同学来我们公司应聘。