如果给你一个Pair面试的机会，你准备怎么应对？

[heaton]

Pair面试一般1个半小时，分为三个阶段（我觉得这是公开的信息，如果不是，我删）：

1. 解释你的代码，你怎么让别人在非常短的时间内通过你的讲解了解你写的代码？
2. 重构你的代码，如果你自己找不出可以重构的代码，那么考官会找些他们觉得难以读懂的代码来让你重构
3. 完成新的需求，看你能多块的理解需求，并修改代码，同时保持代码的可读性

TW重视的不仅仅是写代码的能力，还包括理解业务的能力，合作能力（包括表达、沟通交流、同理心），简化问题的能力，反应力，压力承受能力，同时还有解决问题时思维的广度和深度。

[leecjson]

您好，首先感谢您的回复。

但您发起的讨论不是我内心所期待的。我期待贵公司重新给出更有说服力的理由来打回我的作业，要知道，这只是面试流程中的第一个环节，我们还没有见面，只有代码，贵方要基于这个前提给出理由。

[leecjson]

@heaton 接下来的讨论可否仅限于code

[heaton]

我已经不再是TW的人了，所以也不代表TW在这里写字。我只是在代码里还是看到你的亮点的，一来确实很认真，二来用了策略模式，如果是我我会愿意想知道你写代码的时候是怎么想的。可惜看代码不是我，所以对这结果也无能为力。

[heaton]

这个世界上有些人很有潜力，只是缺了一个好的导师，或者缺了一个机会去看到更好的世界。

[wszgxa]

@leecjson

法律上面，是在最开始拿作业的时候，就说明了，不能把作业发布到网上。其实和你吐槽反馈作业结果，没得啥子关系。你如果因为这个然后来刚一波，其实你不占理也不占法的。

TW 是个很开放的公司，我们内部也讨论了作业反馈的。都是一致的批评"给出反馈过于简单"。这个事情HR团队是会进行retro，进行流程上的改善。不过对于看作业的人给出的反馈，其实你可以自己思考一下，你的代码有没得优化空间。就拿你在readme里面提的函数式，函数式的代码写出来不是这个样子的。

[tcz001]

关于你的代码，我这里有几个建设性的意见
lexer 写的不错，基本上都在线
但是vm 内的抽象其实就出现问题了，
可能你对于编译原理有些执着，但是实际上用编译原理在这道题中暂时还不会touch 到vm 的层面，我大概揣测了一下你其实是在写一个interpreter ，那么这就很明显是个命名上的误导，大部分语言的vm 更侧重于指令抽象与内存管理，而你的vm 则是一个解释器和一些语法糖(严格来说都算不上语法糖，最多算DSL 定义的高级过程)。

另外关于vm 的内部实现，我发现有很多亮点，比如你写了不少端到端的测试，这部分是值得肯定的。但是不知道是不是我没有仔细看，你刚刚删除了的代码中关于逻辑的拆分并没有进行刻意的分类，你写的大部分“函数式”代码，没有很好的体现函数式从底层抽象到上层过程的思维，而更类似一种“全局函数”模式，这些怪味道我觉得你可以下来思考回顾一下，平时的js 代码是如何抽象和封装接口的，至少对于vm(或者我理解的解释器) 所需要暴露的函数，可以有一个重新的设计，当然这也可能是因为时间不足导致的。

最后我个人还是建议HR 部门能邀请你来pair 面试一下，并提安排一个熟悉工程化js代码 的面试官给你，虽然这会增加我们的招聘成本，而且风险依然很大，但是我觉得你的作业态度值得这个投入。

[leecjson]

@wszgxa 您的问题我不予回复，code问题请重新发起一个讨论。

[tcz001]

发现代码又回来了，一会儿找时间在代码上加comments

[leecjson]

@tcz001 感谢您的回复。

首先vm并不一定是非要解释指令的，可以参考一些直接解释AST运行的语言（比如Ruby），另外为什么起名为vm，以我个人的偏见是为了体现上下文环境，也就是说它是一个上文接下文的连续执行环境。

另外'函数式'的概念我只是在Readme中提到，并不是指在我的代码中用到，但conv.js中罗马转阿拉伯数字中的递归确实体现了'函数式'编程的一个应用，当然了，把它展开为循环也是可行的。

再者就是您提到的设计上的问题，vm.js中其实并没有完全把逻辑拆分出去，一是因为我已经实现了需求，二是并没有新的需求触发我去重构，如果出现了需要添加if条件分支或者循环控制语句，则需要对vm.js中的代码重新规划，因为目前的一系列Match函数还不是真递归下降，因为设计的语法过于简单还没有下降的必要。

[trotyl]

@tcz001 理想状态下 Parser 和 Evaluator 是应该完全分离没有问题，但结果上会导致需要设计 AST，使得开发成本整体上升，对作业未必适用。另外在只有全局作用域和 Primitive 的情况下，可以认为概念上不存在内存管理的需求。

[leecjson]

@trotyl /大拇指

[tcz001]

@trotyl 对于这个分离是不是没有必要持保留意见，既然分离了lexer ，AST 和evaluator 的抽象确实没有不分离的道理，另外ruby vm 和 YARV 的两种设计在业界怕不是个梗，拿它当模式来follow 可能不太合适哦

[tcz001]

不过总体来说，我觉得还是瑕不掩瑜吧，关于这块的讨论可以打住了，我看群里有人说input stream 的处理也有些问题，比如一次要求全部输入的可能性很低，嘛，这些都是小问题，其他作业通常还没有到这个程度的问题

[heaton]

我本来说想说用编译器处理这个题目不是一个合理的解决方案，100行能搞定的问题结果洋洋洒洒写了1000行，如果编译器本身不是一个好解决方案，那么这个作业也不能成为一个好的场景来讨论怎么写编译器更好，从而在这里讨论编译器应该怎么写更好也就没有什么实际价值了。这种从技术和解决方案出发，而不是从问题出发的思维方式是需要改进的点。当然如果作者致力于要写编译器，那么TW也不是一个合适的地方，所以在这里更多讨论编译器怎么写也没有什么价值。你应该找IntelliJ，Apple，Google这种公司，给你机会接触像kotlin，swift这种语言是怎么诞生的。
不过这楼的嘉宾们还是很值得敬佩的，用自己的时间来读了不怎么好读的代码，相较于直接用高级语言写的简短代码，这代码更远离业务逻辑的表达，也更长，更难读。
对了，虽然公开作业这个操作确实不合理也不合法，不过我相信TW的人不会对这个代码本身有任何的顾虑。因为它第一，没有公开扩展题目的内容；第二，代码本身帮不了任何的候选人答题。

[leecjson]

@heaton 是的，愿意阅读我代码的朋友也值得我尊敬。为什么要用文法处理的方式来写作业，主要是对TW之前印象不错，希望认真对待这次面试。把问题给复杂化了，确实会复杂化，但如果您把这道题看成是真正的用户需求，您就会发现我的解决方式还不错。

另外再多说一句，如果我们讲法说法，就要有法可依，不只是随便说说而已。有没有道理这件事，只看站在谁的立场去说话了。我公开作业的目的之一也是为了展示，曾经有一个问题，我是如何解决的。以后可以在我的求职过程中用到，如果可能的话，可以尽量避免写其它公司给的作业。我也并没有站在道德制高点去批判，我也并非道德圣人，我也有我需要自私的地方。这个事情的讨论到这就可以了，还是讨论code方面的事情吧。