# 软技能
TIP
软技能
# 是否看过红宝书
注：文字小节
# 题目
是否看过红宝书？
# 分析
红宝书《Javascript 高级程序设计》是前端开发中最重要的一本书籍，面试官问这个问题，是观察你的学习能力和学习习惯。
此时你如果回答“没有看过”，那显然是不太符合面试官预期的。虽然不会因此而拒绝你，但如果之前已经累计了一些劣势，那这个问题有可能就是压倒骆驼的最后一根稻草。
# 如果你看过
建议你再重新回顾一下这本书，写一篇《学习笔记》文章，这样记忆更深刻。毕竟跟面试官说看过，得说出一些实际的内容和干货。
# 如果没看过
如果面试在即，实在没有时间去买来看，那就看一看这本书的目录，再去查一查别人写的读书笔记。大概了解一下这本书的内容。
然后你可以回复面试官：我没有详细看过，但我了解这本书的目录和主要内容 —— 这种答复也是可以接受的，如果你能说出一些实际内容。
# 扩展
日常学习的途径
- 看博客 - 关注技术动态，不求甚解
- 看书 - 平心静气，细致学习
- 看视频 - 快速了解，追求效率，少走弯路
最后记住一句话：浅层学习看输入，深入学习看输出。无论什么样的学习途径，最后都要输出，这样才能转化为你自己的知识。
# code review
# 题目
如何做 code review ？
# 分析
code review（简称 CR ）即代码走查。领导对下属的代码进行审查，或者同事之间相互审查。 CR 已经是现代软件研发流程中非常重要的一步，持续规范的执行 CR 可以保证代码质量，避免破窗效应。
# CR 检查什么
- 代码规范（eslint 能检查一部分，但不是全部，如：变量命名）
- 重复逻辑抽离、复用
- 单个函数过长，需要拆分
- 算法是否可优化?
- 是否有安全漏洞?
- 扩展性如何？
- 是否和现有的功能重复了？
- 是否有完善的单元测试
- 组件设计是否合理
# 何时 CR
提交 PR（或者 MR）时，看代码 diff 。给出评审意见，或者评审通过。可让领导评审，也可以同事之间相互评审。
评审人要负责，不可形式主义。万一这段代码出了问题，评审人也要承担责任。
例行，每周组织一次集体 CR ，拿出几个 PR 或者几段代码，大家一起评审。
可以借机来统一评审规则，也可以像新人来演示如何评审。
# 持续优化
评审的问题要汇总起来，整理一个代码规范和常见问题，持续积累。持续宣讲，并让新成员学习。
# 之前没做过 CR 怎么办
记住本节的内容，对 CR 有大概了解。至少面试时能讲出一点内容。
要如实回复面试官：我没做过 CR ，因为公司环境 xxx 。所以，我才想着去找个更大平台，开阔事业，多实践 —— 把它转换为你离职、要求进步的理由。
# 学习新语言
# 题目
如何学习一门新语言，需要考虑哪些方面？
# 分析
考察你的学习能力和习惯，有没有在学习中积累到经验和方法论。毕竟，前端需要学习的东西太多了。
# 答案
- 应用场景和优势 —— 存在的价值
- 语法（变量和常量，数据类型，运算符，函数等）
- 内置 API
- 第三方库和框架
- 开发环境和调试工具
- 线上环境和发布过程
# 你的不足
# 题目
你目前有何不足的地方？
# 分析
如果你被问到这个问题，那恭喜你面试快要通过了。一般在 3-4 面，或者 hr 面试时会问道这个问题。
无论是 hr 还是技术人员问，你都要从技术角度来回答这个问题，说自己技术上的不足。不要扯其他方面的，容易掉到坑里。
你不用担心 hr 听不懂技术，听不懂更好。
# 不足，不要乱说
要限定一个范围
- 技术方面的
- 非核心技术栈的，即有不足也无大碍
- 些容易弥补的，后面才能“翻身”
错误的示范
- 我爱睡懒觉、总是迟到 —— 非技术方面
- 我自学的 Vue ，但还没有实践过 —— 核心技术栈
- 我不懂 React —— 技术栈太大，不容易弥补
正确的示范
- 脚手架，我还在学习中，还不熟练
- nodejs 还需要继续深入学习
# 最后，要把话题反转回来
不能只说不足，就截止了。一定要通过不足，来突出自己的解决方案，以及未来的预期。
这样给人的印象是：正式了自己的不足 + 有学习的态度 —— 非常好！
# 答案
套这个模板
- 我觉得自己在 xxx 方面还存在不足
- 但我已经意识到并且开始学习 xxx
- 争取在 xxx 时候把这块补齐
