从前端领域到敏捷开发

【慕客访谈】阿当技术漫谈之（一）：从前端领域到敏捷开发

 

      慕客访谈▪第九期

 

      本期人物：阿当 前端工程师

 

      ◎人物背景

 

      阿当，资深web技术专家，06年入行，曾在雅虎、淘宝、新浪、盛大等知名IT公司任职，主要关注web client端、http server端、socket server端、敏捷开发和游戏开发等领域的知识。关于技术，他个人更倾向于T型化的知识结构，在技术路线的发展方向上，比起深度，他更喜欢广度。

      最终成为IT圈儿里的“公众人物”则是因为在2010年时出版了《编写高质量代码——web前端开发修炼之道》一书，以至于在后来面试新人时，很多人表示是看着他的书入行的，这让阿当颇有成就感。

      ◎人物印象

 

      专业、深入，是阿当留给我们最深刻的印象，从前端领域的发展到游戏开发再到技术驱动产品创新，他绝对是个专业的多面手，每个问题都能够侃侃而谈，细致入微的深入分析，通俗易懂的专业解读。如果你对前端开发、html5游戏开发、敏捷开发……任意一个领域感兴趣，这篇文章都值得仔细品读，看看“大师”的精彩观点。

      ◎技术分享

 

      前端发展的三个时代

      1） web1.0时代

      2） 黄金时代

      3） 移动互联网时代

      平衡知识的深度与广度

 

      1） 2/8原则

      2） 编程技巧

      3）平衡法则

      敏捷开发解决速度问题

 

      1） 项管知识——尊重与诚实

      2） 编程技巧——迭代与高质量代码

 

      以下为访谈实录：

 

      前段领域发展的三个阶段

 

      慕课网：作为资深的前端开发者，能谈谈前端领域的变化以及对前端开发工作的感触吗？

      阿当：这个真的是变化很大。大学的时候老师说了一句评价IT行业的话，我印象很深刻——学我们这行就是上了贼船，半年不学习就落后了，两年不学习就找不到工作了。现在的确有了深刻体会。从06年入行以来，用我自己的亲身体会可以将前端领域的发展分为三个阶段：

      第一阶段：web1.0时代——混沌时期，分工不科学

 

      第一阶段在07年以前，是web1.0时代，前端技术基本只用照顾ie6,js框架类库之类的还没有特别形成气候，以手写原生代码为主。布局方面更是直接拉table，还流行一系列的hack技巧，比如1x1像素透明的gif图。前端需要掌握的技术比较杂，那时前端技术的代名词是“网页制作三剑客”，flash是前端工程师们必须掌握的技能。事实上，当时还没有“前端开发工程师”这样的职位，当时的称呼是“网页设计师”，需要掌握的技能包括了“设计”和“制作”两个截然不同的大方向。在不少公司里，“网页设计师”甚至需要掌握server端技术。现在想来，当时处于一个比较混沌的时期，很多分工是很不科学的。

      第二阶段：黄金时代——前端开发工程师的起跑线

 

      第二阶段大概在07年至10年，这几年间开始流行一些新概念，比如web2.0、js框架、css重构、用户体验、ued扥等。前端开发工程师这个职位也是在这个时期形成并清晰起来的。

      这是非常黄金的几年，发生了很多很美好的事情，比如大量优质的国外前端书籍被引入国内；前端技术的模块化、工程化；开发和调试工具起来越成熟；优秀的实践技巧被创造和总结起来。我想国内现在很活跃很厉害的前端工程师们，大部分都是在这个时期成长起来的。

      之所以说这个时期很美好，主要是因为在这个时期，绝大多数人差不多都在相同的起跑线，一个蛮荒的起跑线，无论国内还是国外。新概念、新技巧、新工具差不多是逐个慢慢出来的，工程师们不会一下子就面对大量的信息，学不过来，或者干脆不知道从哪儿开始学，这是一个非常适合学习的时期。另外这个时期flash的发展也非常快，推出了as3、flex、流媒体服务器、页游扥等，技术越来越复杂，于是自成一派和前端开发渐行渐远。

      第三阶段：移动互联网时代——移动web前端开发成新课题

 

      第三阶段开始于10年，这一年移动互联网开始热门起来，html5和移动web前端开发也成了新的课题。老实说，这是个好的时代，也是个糟糕的时代。

      好的方面主要有两点：一是html5比html4强大了很多，b/s结构的产品在技术底层上多了很多支持，比如websocket、transfrom、web worker、webgl、canvas2d、离线缓存等，在产品形态的创新上，有了强有力的支持；二是SPA开始流行，对前端代码的质量和编程技巧的要求相较web site高了很多。如果某个技术的门槛比较低，其实并不是件好事，web site这种产品形态对前端的代码质量要求其实并不高，所以并不能很好地驱使工程师去成长。

      坏的方面主要有三点：一是移动互联网时代，c/s结构比b/s结构主流。在pc互联网时代，b/s结构的产品比c/s结构的产品主流，比如微博、qq空间、人人网、豆瓣、淘宝、知乎、京东……b/s结构的产品风声水起，浏览器是入口，搜索引擎是入口，域名是入口，而web前端技术是b/s结构产品的必要技术。

      但到了移动互联网时代，浏览器不流行了，c/s结构的产品才是主流，想想在手机上你是怎么访问微博的？是去应用市场下载个微博客户端还是打开浏览器输入微博的域名？你是怎么看视频的？是下载客户端还是打开浏览器输入视频网站的域名？虽然站在web前端的技术角度看，我们有跨终端优势，有强大的html5，还有响应式设计，但从市场和用户习惯上看，移动互联网时代，web前端技术其实是在被边缘化的，如果用户没有需求没有使用习惯，技术上再强大又有何用？flex和silverlight技术都远比html4强大，但一样被html4干掉了。web前端技术必须为自己找到存在的价值和最佳的产品形态。有些同学认为hybrid是答案，我不认同。我更倾向于轻应用和微信公众账号这两种方式。未来，且行且看吧。

      二是碎片化严重，pc时代web的兼容问题和移动互联网时代相比，真的是小巫见大巫。pc时代的兼容问题基本只用区分IE和非IE，一般情况下，打开一个IE6和一个firefox，让网页兼容这两个浏览器，基本就能兼容所有浏览器了，常见的兼容问题不超过20个，特别是有了js框架以后，兼容问题全集中在了css方面。而在移动互联网时代，碎片化异常严重，不同的操作系统(pc、ios、android)、不同的系统版本号、不同的分辨率、不同的浏览器、不同的webview宿主环境……最近这三年多，我一直专注在移动互联网下的web开发，趟过无数的坑，说起来都是泪啊。

      三是新东西层出不穷，乱花渐入迷人眼。比如commonJS、ES6、hybrid、前端mvc、响应式设计、css框架、sass、typeScript、nodejs、webgl等等，无论哪个捡起来都够工程师们好好消化一阵子的，这个更新的速度有点快，内容很多，想把它们全部学好不太可能，所以工程师们需要做取舍，根据自己的需要列个学习的优先级，否则很可能直接被吓到，不知从哪儿开始下手。

      web2.0时期那个美好的不紧不慢的学习时代已经过去了，现在进入这个圈子的新同行们尤其要注意这点——新概念很多，不要盲目跟风，抓紧个主线开始学，什么东西是核心，什么东西是辅助性的。

      2/8原则——知识的深度和广度同时发展

 

      慕课网：架构师是比较高的技术职位，可能需要多年经验积累，能分享一下如何迈向架构师吗？

      阿当：知识的深度和广度要同时发展，很多同行朋友喜欢研究深度，不太愿意把注意力转到前端之外的领域，其实把自己限制住了。我觉得2/8原则很正确，花20%的精力就可以解决80%的常用需求。有些同行朋友会把剩下的80%精力用于提高那剩下的20%不常用需求，从某个方面来说，这些同学在追求精益求精，是值得尊敬的。只是从投入回报比来看，我个人觉得这么做是不太明智的。

      IT领域有很多方向，而且不少方向是交叉的，从工程角度看，一个项目从上游到下游会涉及到多个不同方向的知识，以web site为例，上游有ps的切图、css的布局和js的交互，中游有php、java、 python、ruby等的http服务端，sql或nosql的数据持久化、缓存，下游有linux操作系统、和linux下的各种常用服务器 。不同环节有不同的技术要点，只有清楚了所有环节的职责和要点，才能不存在黑盒，胸有成竹地进行设计。

      举个简单的例子吧，以前流行在server端进行mvc，url路由 + controllver + ORM + 模板引擎，随着移动端c/s结构的崛起，以及open api的流行，服务端已经不再流行模板引擎了，转而提供json接口的数据，让客户端自行解决数据的GUI渲染，于是模板引擎就转到了客户端。这是个有意思的变化，思路不复杂，但只有理解了前后端的职责和要点，才能很好地处理这种变化。

      编程技巧——主动“设计”

 

      另外还有一点非常重要——编程技巧。常见的知识有这么几类：语言、框架、工具。绝大多数人关注的都是这些方面，但除了这些方面之外，还有一些知识很重要，也就是我要说的编程技巧，包括抽象的能力、接口设计的能力、可扩展性、可读性、鲁棒性等等，这些能力也相当重要，这是架构师所必须具备的能力，却是很多人忽视的地方。

      其实很多时候，大多数人接触到的项目都偏小，加上有框架的帮助，真正需要自己组织的代码规模都不大，无论是客户端还是server端，所以很多同学不太有机会进行“设计”。这个只能靠自己主动了，一个小的功能，你可以用最简单的方法去实现，也可以换个思路，试试用面向对象的方式去设计一下。平时就以这样的方式锻炼一下，遇到大一些的项目时，就比较有基础了。

      广度与深度的平衡法

 

      虽然我说我更倾向广度的发展方向，并不意味着我不在乎深度，事实上，广度和深度是并行向前的，没有广度难有深度，没有深度空有广度也不值钱。只是如何平衡广度和深度，就见仁见智了。

      我自己有一个平衡的方法：在挖掘深度时，问问自己，这些知识“实用”吗？如果不实用，我就停下来，去扩展新的广度去了。有些同学说，哪有没有用的知识啊，其实是他们将“有用”和“实用”混淆了，“有用”却不“实用”，性价比就不高了。IT领域的知识浩瀚如海，随便找个领域一头扎进去都会发现深不见底，哪个领域都去深挖，不耽误自己时间吗？一专多长是最好的方式。

      敏捷开发——项管知识与编程技巧

 

      慕课网：在您所擅长的敏捷开发方面，能谈谈您个人的一些观点吗？

      阿当：我觉得敏捷就像九阴真经，是武林至尊，而且分为上下两卷。IT人中，除了很少一部分人是在做“研究”，绝大多数人是在做“项目”，而做项目最重要的是速度，天下武功唯快不破，这个速度不仅指项目的开发时间，也包括维护时消耗的时间。说敏捷是武林至尊，正是因为它其实就是在解决“速度”的问题。

      为什么说敏捷分为上下两卷呢？敏捷是个大话题，很多人直接把敏捷简单归类为项管知识，我不太认同。项管只是上卷，而下卷是编程技巧。其中项目经理擅长的是上卷项管知识，而架构师擅长的是下卷编程技巧。只有上下两卷都通读了，敏捷才能发挥威力。

      敏捷价值观——尊重与诚实

 

      先聊聊上卷项管知识吧，敏捷有很多方法论，这其中最知名的有xp极限编程、scrum和精益看板，特别是scrum，几乎直接成了敏捷的代名词。这三种敏捷方法论都遵循敏捷宣言中传达的价值观——尊重和诚实。听起来好像和编程关系不大，其实对编程的影响非常大，没理解这个价值观，就没办法用好敏捷。

      工程师一般都不太关注和人打交道的经验，注意力全放到了编程本身，而软件项目管理则跳出了编程本身，管理的就是项目进度、需求沟通和风险控制，处理的就是人和人怎样合作的问题。

      软件工程之所以能形成一个学科，有多套方法论，正是因为它有它的复杂性，需要合理的方法来进行管理，而不是简单的“有个监工”就能解决。非常多的公司里，项目经理是根据“技而优则仕”提拔起来的。什么“技”？编程技能。而编程技能和项管技能其实毫无关系。如果项目经理们不知道项目管理的方法论，也没意识到它的重要性，想当然地以为管理不过是“监工”，分配任务、开会跟进任务、压时间点、加班。这样的结果，往往是开发团队内耗很严重，需求控制出问题，代码反复改，质量越来越差，加班严重，搞不好最后项目还延期，而团队成员怨念很大。千万别忘了“尊重”和“诚实”这两个最重要的价值观，不要去压你的团队，逼他们承诺他们自己也没底的时间节点。只有重视人性，把人当人，而不是代码机器，才能玩好敏捷。去“帮”团队，而不是去“管”团队。

      不要小看项管知识，没有系统学习方法论的同学，真的需要好好学习一下。就从scrum入手，以scrum为框架，然后再补充些xp极限编程提倡的实践，比如结队编程、持续集成、每日构建。TDD的话，要看情况，如果项目规模很大，推荐使用，否则不建议使用。TDD的成本有点高，对于中小项目来说，性价比不高甚至得不偿失。一般的web项目，规模其实都还好，代码可能都在万行以内。我觉得十万行以内的代码规模，做TDD可能都不划算。

      敏捷项目管理最大的问题，可能出在“说服领导”上。据我的经验，绝大多数老板不懂敏捷，也不认同“人性”管理，认为管理就应该“加班”“压时间点”，习惯“我给你定时间交货，过程我不管”，看到团队不加班就慌了，看到团队热火朝天加班就感到踏实。面对这种老板，说服他接受敏捷的价值观和方法论，比较困难，而如果说服不了老板，敏捷就很难推行了。

      敏捷理念——迭代与代码质量

 

      再说下卷编程技巧。敏捷有一个非常重要的理念就是“迭代”，不同于瀑布式开发，一次性设计、开发、测试完成，敏捷讲究把项目分为多期，先把最核心功能开发完成，然后经过多轮迭代，渐渐完善产品，产品永远没有“完美”的时候，而是通过迭代逐渐趋于完美。

      迭代在代码层面意味着什么？很可能意味着“重构”和“扩展”。所以代码的架构设计好不好，可读性、扩展性和重用性好不好，每轮迭代后，代码有没有变腐坏，决定了项目能否很好地进行“迭代”工作。如果代码质量不高，很可能“重构”就变成了“重写”，“扩展”变成了“复制代码，repeat yourself”。这样，随着迭代的次数越来越多，每轮迭代的时间会越来越长，需求会越来越难以响应。如果不能控制代码质量，保证代码的可维护性，使用敏捷还不如使用瀑布。也就是说，保证代码质量，是实行敏捷项管的基本条件。

      如何保证代码质量？这里面其实有很多学问，比如如何命名、如何组织函数、如何进行面向对象设计、如何分层、如何写注释、如何重构代码、如何降低耦合、如何提高可读性等等，这其中都有技巧，而很不幸地，我发现大多数工程师不太关心这些技巧，只关心底层又新增了什么api，是否又出现了什么新框架新工具之类的。他们其实错过了非常重要且实用的知识。如果不具备这些知识，能写出代码，实现功能，但很难写出高质量的代码。

      其中原因不能完全归咎于工程师。据我所知，大多数做web开发的工程师，无论前端还是服务端，接触到的需求都比较简单，对“设计”的要求并不高，基础上能达到“重用”和“团队合作不产生冲突”这两个要求就够了。这和web site这种产品形态比较简单有关，或许等到SPA这种产品形态普及的时候，现在这种情况会迎来较大的变化。现在html5游戏就是SPA的一种流行的应用方向，未来还会有更多其它web app的形式出现，到时前端工程师们的差距会拉开，就像现在很多前端做不了html5游戏一样，不提高自己的编程技术，未来会跟不上的。

      总而言之，敏捷是个集项管方法论和编程技巧于一身的领域，在我眼里，它是九阴真经一样的终极追求，每个工程师都应该去学习一下。