算法
验证二叉搜索树
给定一个二叉树，判断其是否是一个有效的二叉搜索树。
假设一个二叉搜索树具有如下特征：
节点的左子树只包含小于当前节点的数。 节点的右子树只包含大于当前节点的数。 所有左子树和右子树自身必须也是二叉搜索树。
var isValidBST = function(root) {
if(!root) return true
var arr = [];
inOrder(root, arr);
for(let i=0; i<arr.length - 1; i++){
if(arr[i] >= arr[i+1]){
return false
}
}
return true;
};
const inOrder = (root, arr) => {
if(root === null){
return ;
}
inOrder(root.left, arr);
arr.push(root.val);
inOrder(root.right, arr);
}
业务
作为一个前端，是否应该深入了解业务？我接触过绝大部分前端同学基本都是按照需求和设计稿做前端业务。对前端业务不愿意了解，更多是专注在技术方案层面。在我看来，技术更多的是为业务服务，不是搞了一套牛逼的架构，然后把业务往里面套，应该是先看业务场景，然后根据当前的业务场景和未来业务的发展来做适应的架构。
前端是沟通业务与用户之间的展示和交互，前端是最贴近的用户的工程师，所以前端有一部分职能是提供交互建议，建议怎么提出来，不是单纯的看这个功能应该是什么交互，应该从整体业务的流程上看，这个层面应该提供什么样的交互，前端工程师应该在深入了解业务之后，提供交互建议改进产品，共同推进业务。
如何分析业务
我认为看待业务应该从竞对开始，分析竞对的切入点在哪儿，竞对如何做的，竞对为什么做不起来，为什么我们能做起来，我们业务的核心竞争力是什么，切入点是什么，如何做的，未来的计划是什么，我们的弱点是什么
业务理解
竞对分析
我们目前的竞对大致有ALJK、PAHYS、WY、HDF、DXY等。这三者分别做的是三类的业务。
ALJK 切入点是做医院的 HIS 系统，想从最底层切入医疗，但是他们很难做起来，医院间的 HIS 相对独立，每个医院擅长和诊疗流程是不同的所以 HIS 很难用一套统一的 HIS 流程来替代，另外有三方面导致 HIS 很难做起来：
- 一、十多年的医疗流程沉淀，让 HIS 系统不难，但是会很复杂。
- 二、HIS 背后的提供商都是大的国企，大的几家医院都是被这些国企垄断，背后的利益很复杂，很难切入。
- 三、医院相对来说还是比较传统守旧，没有动力去接受一套统一化的方案切入。
PAHYS在线上诊疗但是他们没法做服务承接，因为医疗这个服务还是更像 O2O 的业务模型，还是需要线下服务的承接，没法将他们的服务直接引向医院。
其他几个大产品都在做医生、内容这方面，这方面深层的业务是想做数据沉淀和内容沉淀，但是医疗的大数据需要来源于医疗，最后又需要服务于医疗。实际上我认为这类产品是很难做到商业化的突破口。
我们的核心竞争力在于我们有政府的资源背景，上述不能完成的事情我们能做。我们为政府解决就医难的问题，我们的切入点是挂号。
业务架构
为了解决就医难，我们切入点是挂号，对接医院我们并没有去切入 HIS，而是将几十家医院当做供应商，我们和医院之间用 OTA 的业务架构去构建，我们作为平台层， 库存、报价、下单这些都通过接口的方式互相调用互相同步。这样能最小化的对 HIS 进行侵入和改造，即使这样改造 HIS 的成本也是相当高的。
面向用户我们采用 O2O 的业务模型，线上预约挂号，线下就医就诊，一定程度上解决了就医难的问题，至少让原来多次跑医院的次数减小。但是做完挂号发现就医难的问题依旧没有解决，通过总结分析我们认为就医难的问题分为两大类：就医流程合理性的问题、就医流程低效。
业务拓展
针对就医流程低效我们通过将原有一些传统的就医流程搬到线上，提升效率。比如挂号取号、诊间过程的缴费、排队叫号、报告打印，线上查询报告、发票打印等。这些流程都搬到线上，将原有同步的流程变成异步，提升并行处理的效率。
就医流程不合理我们主要认为是病人的病情和医生的能力不匹配，小病看专家，专家看不到大病，专科类型的病症挤满擅长该类科室的医院，眼睛有问题不一定非得去同仁看。
这里我们引入了在线咨询，线上对病人做一个分级诊疗的划分，小病在线叫你回去多喝热水，一般的病症将你推荐到就近的医院，并推送一个号源链接，直接进行挂号，引导到线下服务。如果是重要病症推荐到各个医院组成的专家团队中，专家团队是对应病症的专家带一些小医生，一开始去小医生那儿看，解决不了再往上升级到专家那儿看。这样让整个就医合理化，让合适的病能看上合适的医生。
我们也综合我们所有的服务承接的医院，做一个号源推荐的功能，如果你想去同仁看眼科，号没了会给推送一些其他医院的号源，绝大部分情况是综合型医院都能看好的一些病症，从而让整体就医流程合理化。
我们也为医生建立品牌形象，也做内容沉淀，这些数据沉淀下来都是医疗大数据，但是真正的医疗数据更多的是来自于医院，比如高血压的病一般会到哪些科室去看，去这些科室去看用户的画像是什么样的，不同用户画像的病人一般是开哪些药。这些数据还不能做到完全指导医生看病，但是能一定程度的辅助医生做出诊断意见。类似这样的数据沉淀还有很多，更多的是看应用场景。
我们还做关于患者的个人医疗档案，以前不同医院之间病历很难共用，但是一旦电子化之后，特别是对于慢性病或者既往病史，这些个人医疗的数据将会更全面的辅助医疗决策。
未来计划
整体医疗这块我们将分为商业化服务和非商业化服务。上述的业务都是我们的非商业化服务，这块之后将会更多的在现有医疗流程的高效性和合理化上的探索，比如如何切入住院流程。更多的精力也会考虑医疗数据如何沉淀，如何使用。
商业化这块更多是探索，医疗商业化的价值很大，但是市场、政府、医院信息匹配度不够，所以导致很多商业化产品很难开发到市场，我们去做的大部分属于尝试，告诉市场哪些可以做，但是我们的体量和能力有限，很多商业化服务都需要一些大公司来扩展承接，比如医疗保险、体检服务等。我们作为平台来做很多探索给市场信心，服务方来接入我们做分成。
像类似共享轮椅、共享储物柜这些低成本低运营的业务，我们也在自己进行维护扩展。
缺点
我们整体业务中，大部分与政府和医院沟通，成本非常高，很多功能都是开发完成之后对接时间周期特别长。
前面也说我们没有切入 HIS，做的一层平台层，这层便于我们快速开展业务，但是一旦有背景更强的其他公司得到政府支持想要介入进来。开发同样的接口，作为平台层太统一业务壁垒就很低，替换成本就很低。
总结
深入了解业务之后更能落实技术为业务服务，我们的目标是为了更好的推进业务，一切以推进业务为前提，深入了解业务能构建更适应当前业务的技术架构，并且了解业务未来的发展计划，更能在技术层面预留出技术未来的规划，最终达到高效高质量推进业务的目标