微软资深软件设计工程师Eric Lippert此前就讲过，读代码远比写代码困难，不仅是因为理解上的问题，还有阅读工具选择的问题。目前在线阅读代码的工具种类杂多，但是要做到用户体验满意的在线工具，实属不易。最近采访了Coding.net全栈工程师杜万，听他讲讲Coding即将发布的在线阅读代码工具CodeInsight有哪些功能。
杜万 Coding.net全栈工程师。从事了近10年以Java语言为主的软件开发工作，热衷于整合框架和开发工具，关注交互设计，Linux拥趸者，喜欢写技术博客。近期开始学习和关注Elixir函数语言。目前负责Coding WebIDE项目的架构和研发。
InfoQ： 请介绍一下自己，包括之前的工作经历以及现在所从事的主要工作。
InfoQ： 有人说，如果一个公司不太懂全栈工程师的价值，那么全栈工程师的地位将会很尴尬，那么一个全栈工程师如何才能做到“一专多能”？
杜万： 对于一个刚入行的工程师来说，专心干好本职工作比较重要，表现出色才会有更多的机会。程序员大多有自学习惯，上班写代码，下班逛论坛，看博客，读些技术书籍。本人更倾向于花大块的时间系统的阅读，扫除知识盲点。看的书和学的技术最好和当下的工作相关，几周以后会用到的。这样学习和实践就能紧密结合在一起。
只有出色的工作才能赢得信任，这样会有更自由的空间，在某些小的技术点上有些决策权。对于这样的机会，一般倾向于选择采用技术上更创新或者契合的方式，而不是“省事的”的解决方案，即使会因为“麻烦一点”而牺牲一些业余时间。高手出于刻意训练，总的来说个人成长的方式是：努力干活，制造问题和解决问题。
InfoQ： 您是Linux的坚定拥护者，之前也做过开源平台bsdn.org，那么您现在工作中经常使用Linux工具吗？您对开源软件有怎样的深刻理解和心得？
杜万： 从大学开始就接触Linux，工作中部署环境基本都是Linux，也曾经在Ubuntu的桌面环境下工作了一年多。
喜欢Linux是从感受到它强大好用的命令行开始的。bash，awk，sed，vim等一系列字符界面的工具串起来可以干很多事情。特别对于本人这种靠Java语言启蒙的程序员，分外觉得方便。另外，Linux很多发行版都内置了包管理器，一行命令就可以安装好想要的软件，这使得大家都很依赖这样的便捷。在Mac OS桌面下，Homebrew也是很受人钟爱的工具。
至于开源软件，个人认为对于行业最大的益处是知识更高效率的重新利用。对开发者来说，帮助最大的三个网站是：Google、Github和Stackoverflow。通常遇到问题，都是从Google链接到Stackoverflow，再链接到Github。Github上有大量的开源源代码组成的知识仓库，这样才会有大量Stackoverflow宝贵问题的答案积累，进而让程序员遇到坑时更有效率的找到解决方案。
InfoQ： 据悉Coding最近将会推出一款云端代码阅读工具——CodeInsight公测版，目前它所具备的主要功能有哪些？
杜万： CodeInsight是一个在线代码阅读工具，该工具对版本库中的代码进行语法着色，引用分析，并以文件树的方式向用户展现完整的项目源码。借助该工具用户可以方便地浏览代码，定位变量定义以及理清引用关系。对于一些深奥晦涩的部分可以添加评论，与其他用户共同探讨和推敲。
InfoQ： CodeInsight除了支持PHP项目之外，还支持哪些别的语言？能不能跨平台阅读托管在Coding平台以外的代码？此次推出的CodeInsight公开版本，分析了哪些热门的开源项目？
杜万： Coding新开发的CodeInsight公开版是基于Google的开源源码分析引擎Kythe而实现的。Kythe默认支持C++和Java代码的分析。后面会考虑在Kythe的基础上扩展对其他语言的支持。从Java入手，初期打算分析Maven仓库里最热门的100个项目。
InfoQ： CodeInsight和WebIDE是相辅相成的工具，可否具体讲一讲两者之间的关联性？
杜万： WebIDE非常好理解，就是一个浏览器版本的代码编写工具。IDE是集成开发环境（Integrated Development Environment）的缩写。一般来说现代的IDE会集成，编辑、档案（版本管理）、编译、调试、执行等开发过程需要的一系列功能，以提高程序员的生产力。Coding的WebIDE已经具备编辑、版本管理功能，而编译，调试，执行等功能我们通过Web Terminal先简单地替代了一下。关于代码编辑方面，IDE还是有很多好用的功能。比如，语法着色，交叉引用，自动补全，快速定位，错误提示等。而这些功能依赖于对代码的词法和语法分析，这些分析器有些需要自己实现，有些可以依赖于现成的编译工具。但是无论怎么样都是很大的一块功能，需要长期深入的研究。
CodeInsight是一个主打代码阅读的工具，一份高度可读的代码，除了代码内容本身具备良好的编写风格，比如符合范式、命名规范、有良好的注释以外。如果具备一些辅助工具，比如语法着色，交叉引用，快速定位，可以让阅读和理解变得更容易。而这些好用的功能也依赖于后端的分析引擎。词法和语法分析引擎是WebIDE和CodeInsight共同的基础，或者说就核心技术而言，CodeInsight只是WebIDE的一个功能子集。所以我们先去研发CodeInsight，以期待在漫长的道路上有一个阶段性的成果可以服务于Coding用户。
InfoQ： 可否详细谈谈Coding WebIDE项目的架构和研发过程？WebIDE有哪些核心功能，可以完成哪些工作？
杜万： Coding WebIDE采用了前后端分离的架构，前后端之间通过Restful API进行交互。前端做了两版。第一版是基于BackboneJS做的，第二版是基于ReactJS做的。后端主要是用Java和Go语言实现的。Java采用了Spring framework/MVC/Security/Data全套框架。Java部分主要是提供Restful的API，权限认证和数据库相关的操作。Go部分主要负责和操作系统相关的工作，如工作空间管理。
参与研发的同事身处各地，本人当时在上海，有同事在南京读书，有同事在深圳总部，有同事在湛江老家，大家通过Coding平台的代码仓库和任务系统进行远程协作。研发过程中团队特别推崇两件事：Peer Review（同行评审）和Unit Test（单元测试）。这两件事情是为了让WebIDE得以快速迭代。团队一直在微调架构，除了直面问题的勇气，同事间的代码审查和绿色的bar是大家最大的信心。
WebIDE的核心功能包括代码编辑，版本库集成，全功能的Terminal，开发环境分享等等。目前WebIDE方便做一些轻量级的动态语言项目；有的时候，即使电脑不在身边也可以通过WebIDE的功能修改代码。
InfoQ： Coding WebIDE和同类产品之间有哪些区别和优势？同类产品中又有哪些方面值得Coding WebIDE借鉴？
杜万： Coding的WebIDE和同类产品比，最大的优势是速度快。市面上的其他IDE产品多是采用VM作为后端，而Coding WebIDE是建立在Docker之上，所以启动和打开速度要快不少。也正因为WebIDE是在新兴的Docker之上，所以不能像其他IDE产品一样随时hibernate，完美的保持状态。
Coding的IDE功能还有点弱，代码分析还没有完善，自动补全也不够好，缺少对Debug的支持，这些都是我们需要学习和借鉴的。
InfoQ： 《Docker在Coding WebIDE项目中的运用》一文中，您提到WebIDE在架构初期，考虑全面Dockerize的方案，最后因为“Nginx是否也要放进Container里”存在不同的声音，而放弃了全面Dockerize。根据您的经验，如果实施全面Dockerize方案的话，能带来哪些效果？
杜万： 做WebIDE的时候最早是把所有的服务都放进了Container。统一的封装方式很适合管理，但是上线的时候运维不同意，他们说，物理机上了MySQL已经有自动的备份功能，Container里的服务需要重新做。已有的Nginx里加一行配置就可以，所以没必要封装成独立的。其实他们说得有道理，所以最后就同意了。
另外，Container中的服务也是存在一些问题的，被迫拿出来。有个服务依赖动态mount的目录，而由于mount namespace的隔离，一个已经启动的Container是无法感知到宿主机的mount变化。
InfoQ： 目前，WebIDE还是存在部分不足之处的，例如：不支持debug断点调试功能、不能像Web开发者那样直接运行查看、菜单不支持中文、还无法承担大型应用的开发等，对于这些，Coding在接下来会做哪些技术上的改进？在未来还有哪些目标需要突破？
杜万： 中文菜单已经有了，其实早就有了，只是当初开发人员用惯了英文的IDE菜单，感觉中文的菜单太别扭，就去掉的。
为了适应这个快速变化的互联网时代，最初的IDE基本是弄出一个雏形就匆匆上线了。对于资源的限制，比如CPU和磁盘的限制，这些都是后半年慢慢加上的。在Docker技术上搞这些限制，都是些新兴的课题，团队做了许多试验，也踩了些坑，最终短板还是补上了。目前整个团队致力于研究在线协作，希望能像国外同类产品一样，实现多人的同时编辑、远程结对编程。
其次就是，回放操作历史在教学方面的需求很强烈，Coding团队也在做这方面的技术储备和研究。
InfoQ： 作为一位资深的全栈工程师，您在开发过程中都遇到过哪些典型的坑，又是如何克服的？可否为其他全栈工程师分享一些引以为鉴的案例。
杜万： 一个手指不离键盘的码农，一路踏坑而来。
最近遇到过一个比较严重的案例。为了挂载支持动态扩展的镜像问题，研发团队选用了KVM内置的NBD模块。前期调研发现很好用，本地实现没有异常，staging上没有问题。生产机上线以后，隔三差五地出现进程内核态CPU100％，这是一个非常头痛的问题，进程在内核态是无法被kill的，而且占满了CPU资源，每每出现这种情况，就只能无奈的重启服务器。这对于云计算是很难接受的。Google查询了很久，多次升级内核，无果。最终改了方案，放弃了不稳定的NBD。引入新技术解决问题，都是程序员乐于去做的。但是每引入一种新技术，都同时增加了不稳地的风险。
对于创业公司来说，最关注的应该是业务，解决用户的痛点。所以，有时候技术栈纯粹一点是明智的选择。
InfoQ： 您现在关注Elixir函数语言，且有十多年的软件开发经验，可否分享一下这些年的垒码心得、学习感悟，以激励后者！
杜万： 语言大战经常是技术人热爱的战场，有人说PHP是最好的语言，有人接受不了Golang的变量声明格式，一些同事鄙视三个等号的语言，还有讽刺Lisp括号太多的。
刚开始学C系语言的时候，觉得语言都差不多，编程思想很重要，应该精通设计模式。后来接触了Ruby，被DSL的魅力深深吸引，灵活动态的语法让设计模式变得不是那么重要。再后来学习了Prolog和Clojure才意识到同像性（Homoiconicity）才是真正地让人着迷的原因所在。
最开始听说Elixir，是来自于同事在Coding发的一条消息：“不要咖啡，不要大象，不要蟒蛇，不要红宝石，只要万金油”，我们知道咖啡表示Java，大象表示PHP，蟒蛇表示Python，红宝石表示Ruby，那万金油是什么。Google一下，才知道万金油是Erlang虚拟机上的一门语言。相当于Scala之于Java虚拟机。英文名字叫Elixir。Elixir是函数式语言，支持元编程，先天的分布式支持，借助于OPT框架可以替换代码。也就是可以不停机，升级业务代码。类似于nginx -s reload，但是这是应用级别的特性，无需架构支持，简直太棒了。
感觉发现了新大陆了，赶紧吆喝大家一起来开荒吧。但是没有中文版的资料呀。于是和同事一起联系出版社合作翻译了《Programming Elixir》，目前已经交稿了，估计不时就能出版了。当大家在编程语言的选用上发起争执的时候，建议大家多学几门语言，慢慢你就会发现，每种语言都有擅长的问题领域，用得好才能站在鄙视链的上端。
>>>> 写在最后 正如杜万所说，虽然CodeInsight和WebIDE目前还有很多地方需要改进优化，但是只要了解用户需求，提升用户体验，不断的增加实用功能，那这款产品成为成熟产品也就不远了。
