Tag: Coding
-
如何搞定纸上代码环节？
很多重视技术的互联网公司在工程师招聘的技术面环节都会要求候选人在纸上写代码（后文用 “纸上代码” 代称），面试官想通过这种方式考察哪些点？候选人该注意哪些点？本文基于美团早几年常用的一道区分度比较高的面试题来做详细讲解，这道题我现在还在用，面过的人很多，但是纸上代码环节能答到满分的少之又少。 为什么要纸上代码？ 纸上代码（也有可能在白板上写）的做法乍看起来不够人性，但如果你是团队的 Leader，什么样的人能更好的融入团队？如果你是老板，你愿意掏钱养什么样的员工？纸上代码的基本目的就是考察候选人是否具备出活的能力，附带考察候选人是否思路灵活、知识面广。 纸上代码环节怎么考察出活的能力？首先是出活的速度，没有编码基本功的人快速出活的概率是极低的，100% 依赖百度或者 IDE 自动完成才能完成基本任务的工程师算不上合格的工程师；其次是出活的质量，通过编码过程可以了解候选人通过学习和训练积累下来的编码风格、思考方法等；此外，通过纸上代码也可以了解候选人接受和完成任务的主动性，是不是愿意接受任何团队需要完成的任务。 某种程度上说，纸上代码过程就是今后工作的缩影，既然如此，面试时排练下不是挺好的么？ 纸上代码该怎么做？ 通常来说，纸上代码都不会问特别复杂的问题，很可能只是完成非常通用的需求，解决实际遇到的业务问题，或者用某种语言实现某种算法。在提出实际业务问题的代码题之前，面试官会通过部分前置问题了解候选人对解决业务问题所需知识的掌握程度，并在必要的情况下给出知识补充。 比如，前文提到的那道美团的代码题是：不借助第三方库的条件下，用 JS 编写函数从下面的 URL 串中解析出所有的参数： 期望的返回结果格式如下： 对于使用过 Node.js 中的 querystring 或者社区中的 qs、uri.js 模块的同学对这个可能再熟悉不过了，而那些不熟 HTTP GET 请求参数携带方式的候选人也不用着急，因为这种情况下面试官会解释 URL 参数的构造规则，至于对网络知识的掌握程度，是另外的关注点了。实际操作中，在我拿出这个问题之前，已经跟候选人聊了比较多的 HTTP 话题了。 1. 开始动手前 相当比例的候选人拿到问题，会立即提笔开始写代码，这是面试官最不愿看到的，和学校考试的填空题不同，纸上代码作为综合素质环节，面试官希望看到全面的你，如果工作中也是这样拿到需求不分青红皂白就开搞，最终的结果可能常常是事倍功半。 谋定而后动，动手前一定要搞清楚问题。怎样才算是把问题搞清楚了？要清楚输入的特征，是否会出现各种奇怪的输入（脑子里面有这根弦的人通常不会差，但是面试官会小心求证，看看你能想到哪些）；要清楚对解决办法的其他约束条件，比如时间复杂度，空间复杂度。而搞清楚问题的方法就是追问面试官，比如，针对上面的代码，可以追问的问题： 就如同在实际工作中接需求的时候，需要知道需求的边界，各种可能的特殊情况，合作方对于排期的期望，需求中各个要点优先级界定，从决策论的角度来看，掌握更充分的信息，才能让你对技术复杂度、需求排期有更合理的预估，避免在做到一半或做完的时候发现与实际需求不符。 搞清楚问题之后，相信你心中已经有了基本思路，不过动手的时机还没到，你应该把思路介绍给面试官，确认自己是否自己是否忽略了某些要点，这也是展示沟通能力的好机会，知道什么是有效沟通的同学应该能明白接收信息后向信源确认的重要性。 需要注意的是，质疑精神强烈的同学在动手前会提很多问题，看起来是好事情，但如果只是停留在质疑层面，不愿意动手，留给面试官的印象就会是你是个挑活的人。在我的招聘经历中就曾遇到过因为觉得代码题要解决的问题没有任何意义而拒绝写代码的人，我没办法只能客气的把他送走。因为，对不认同事物的宽容程度很低的人很容易给团队带来坏味道。 确定了问题边界和解决问题的思路，接下来你可以开始动手编码。 2. 编码过程中 解决 QueryString 参数解析问题的思路有好多种，比如字符串线性遍历法、字符串分割法、正则表达式方法，在我面过的人中，用字符串分割法的人最多，下面的讨论我们就围绕这种方法展开。线性遍历法的实现可以参考 Node.js 内置的 querystring 模块。 编码过程中需要考虑哪些要素呢？下面用具体的例子来分析，比如我经常拿到这样的结果代码： 看到这样的代码，相信你也已经皱起了眉头，这段代码在表层、逻辑严谨性、健壮性都存在问题，更严重的是没有满足数值型参数的需求，透过这段代码也可以推断候选人大概率是个不善于学习的人。 表层问题 表层问题主要指代码可读性，评价标准是：是否看起来简洁？是否看一眼就能理解它在做什么？上面的结果有哪些具体的表层问题呢？ 做了表层改进的参考代码如下： 逻辑问题 逻辑不严谨的代码在不同输入情况下的结果是不稳定的，具体表现为： 解决掉逻辑问题的参考代码如下： 健壮问题…
-
阅读优秀源码是提升技能的绝佳途径
见识比常识更重要 不少程序员几乎不重构自己的代码，他们觉得代码只要能运行起来就可以了，即使他们的代码写得一团糟，耦合性高，缺乏必要的注释，命名不规范，过了一周连自己都不知道写的是什么东西。这种编码习惯，就算有十年的工作经验，也只是一个底层的码农而已。 编码如同写作，要成就优秀的作品，必须阅读足够多的优秀作品。试想一下：一个只读了小学六年级的人，所看的书只局限于语文课文，有可能创作出优秀的文学作品吗？很显然这是不可能的，即便他天赋异禀，也很难用优秀的文字将心中的想法所表达出来，写一篇优秀的作文是没问题的，但要创作浩瀚的文学作品是不可能的。同理，一个只学了基本语法，只看官方文档的程序员，写一个小程序是没问题，但要写出优秀的项目也是不可能的。一个只会盖茅草屋的人，从来没看过别人是如何建大楼的，只在影视作品中看到摩天大厦，给他所有建筑材料和工程队，他也绝对不可能构建起大楼。 如果你没有读过优秀的源代码，没有认真地研究这些优秀项目是如何设计的，只是重复着自己拙劣的代码，即使你重复了一千遍，一万遍，也只是在原地打转。没见过优秀源码的人，只会坐井观天地重复自己拙劣的代码。从这方面来讲：见识比常识更重要！ 如何阅读优秀源码 那么现在问题来了，如何阅读优秀的源码呢？ 以 PHP 为例，PHP 有很多优秀的开源框架，这些开源框架的文件动辄上千个，数十万行代码，对于初级程序员来说，要读懂这些代码太难了，就如同叫一个普通人读一本晦涩的数学专著一样（每个字都认识，就是不知道讲的是什么）在此分享我的一些读源码的方法：（以ＴhinkPHP 为例） １. 先将框架搭建运行起来，大致阅读一遍文档，对该框架的架构，目录文件的摆放，运行的流程有个整体的大概了解 ２. 根据文档的说明做一个小项目，如一个留言板的功能，此阶段主要是为了熟悉框架封装好的方法，感受框架的设计理念 ３. 从框架的入口文件开始阅读源码，一边阅读一边用 xmind 作笔记，读到哪些不懂的就进行调试，或在源码处进行注释，以便再次阅读时加深理解。第一遍读源码时，不必追求每一句都读懂，也不可能达到这种程度，第一遍主要是熟悉框架的代码风格，了解其运行流程，最好自己画一张草图，将程序的运行流程记录下来。并一边想：为什么要这样设计？如果是我来设计框架，我会怎么做，怎样兼顾安全与效率，如何让开发人员更加容易使用？ ４. 模块化读源码，框架中最重要的是其核心代码，将核心代码按功能模块切割，如切割成：配置模块、缓存模块、日志模块、公用函数、模型类、控制器类、视图类等。然后精读每个模块。务必将这些模块的代码都读懂，最好是边读边跟着写。以我的经验：有些代码总是看不懂，但跟着写，通常就能懂得其原理了。因为在写的时候，我们的精力会更加集中，更容易得到思维上的突破。 ５. 将读源码的总结记录成文字，这点特别重要！即使你以为自己真的懂了，但是如果你没能做到将你所理解的知识表达，你就不是真正地理解了，而是只有粗浅的认识，很快就会遗忘。整理思绪，书写记录，是另一种思考，在这过程中，你将脑中的相关知识点进行联系，在碰撞中会产生更多的想法。而且发表出来的资料可能会得到他人的反馈评价，修正自己的某些错误。