专访黄勇：Java在未来的很长⼀段时间仍是主流（把⽼板当情⼈，把同事当⼩
孩，把客户当病⼈）
2015-09-06 13:18
摘要：本⽂采访了现任阿⾥巴巴公司系统架构师黄勇，从事近⼗年的JavaEE应⽤开发⼯作。采访内容包含了技术⼈⽣、IT职场、程序员、Java Web框架、研发管理、敏捷开发、开源等问题，希望你在技术这条路上不孤单。
【编者按】⼀个普通的技术⼈讲述不平凡的技术⼈⽣路。黄勇，在⼯作⼗年后，写了⼀本书：，这本书是给他⼗年技术路的最好礼物，今天我们有幸采访了黄勇，请他谈⼀谈他的⼀路⾛来，也就技术⼈员发展的⼀些问题进⾏讨论，以及分享他在研发管理、敏捷开发⽅⾯的研究。
本⽂内容很丰富，如果能够⽤⼼花时间读⼀读，不仅对你的IT职业⽣涯、技术积累等有所帮助，也会产⽣⼀种前⾏的推动⼒，因为成功的⼈依然在努⼒。也请那些在拼搏的IT ⼈，请继续「相信梦想的⼒量」。
在 Web 开发⽅⾯，Java 经历了怎样的发展？初学者如何从零开始写Java Web框架？黄勇⽼师将携《架构探险——从零开始写Java Web框架》⼀书，接受⽹友们关于Java Web 框架的相关提问，与此
同时，也欢迎⼤家来与黄勇⽼师交流技术⼈员⼊⾏、⼼态、技能，以及敏捷开发、开源等⽅⾯内容。
敬请关注：的第⼆⼗⼆期：
黄勇（），从事近⼗年的 JavaEE 应⽤开发⼯作，现任阿⾥巴巴公司系统架构师。对分布式服务架构与⼤数据技术有深⼊研究，具有丰富的 B/S 架构开发经验与项⽬实战经验，擅长敏捷开发模式。国内开源软件推动者之⼀，Smart Framework 开源框架创始⼈。热爱技术交流，乐于分享⾃⼰的⼯作经验。著有《架构探险——从零开始写Java Web框架》⼀书。
我的⼗年技术之路
CSDN：请和⼤家介绍下你和⽬前所从事的⼯作。
黄勇：⼤家好，我是黄勇。
我⽬前从事分布式服务架构的设计与开发⼯作，在阿⾥的⼤数据平台上进⾏应⽤程序开发。我们整个系统架构采⽤了“前后端分离”的思想，前端关注数据展现，后端关注数据⽣产，通过 REST服务将前后端整合起来，所有的应⽤都是⽆状态的，可以做到⽔平扩展。我们将整个系统拆分成许多“微服务”，服务之间通过统⼀的接⼝来调⽤，每个服务是通过容器技术进⾏隔离，此外服务可发布到统⼀的服务管理平台上，可通过该平台监控每个服务的运⾏状态与⽣命周期事件，并为服务调⽤者提供了服务发现
的能⼒，可对服务进⾏平滑升级。
阿⾥有许多优秀的中间件与基础服务，可以快速帮助我们搭建应⽤系统，⽽且这些技术在阿⾥内部全是开源的，⼤家可以通过源码和⽂档学习到很多有价值的经验。阿⾥也提供了浓厚的技术氛围，每位同学都⾮常专注于⾃⼰的⼯作领域，⼤家对⼯作⼀丝不苟，相互配合，⽅向⼀致。
CSDN：你是如何⾛上技术这条路的？
黄勇：2006 年⼤学毕业，我离开了母校武汉理⼯⼤学，在院长薛胜军⽼师的推荐下，我来到了上海，这个对于我来说⾮常陌⽣的地⽅。我有幸加⼊了⼀家名为“动量软件”的创业公司，这家公司的⽼板曾经是亚信科技的 CTO，他也是普元软件的创始⼈兼 CTO，他的名字叫黄柳青，他也是薛⽼师的⼤学同学。于是就这样，我的⽼板成为了我的⽼师，我习惯叫他黄⽼师，包括公司其他资深的同事也成为了我的⽼师，因为我很想他们⾝上学到更多有价值的东西。
刚开始⼯作的时候我学习了什么是云计算？什么是 SaaS、PaaS、IaaS？我们花了三年时间开发了⼀款名为 ODE 的 PaaS 平台，让⽤户可以在该平台上量⾝定制⾃⼰的软件，最终为客户提供基于 SaaS 的产品。确实很骄傲，那时我们已经在做云了，只是没想到后来云会在中国得到这么好的市场，可能当时只有黄⽼师⼀个⼈想到了吧。
在 2008 年，我为公司拿回了“第⼀桶⾦”，这也是我从程序员转向项⽬经理的⾥程碑。当时我带领团队远赴深圳，为国信证券公司开发经纪⼈管理系统，这个项⽬对于我个⼈⽽⾔却是⼀笔⾄⾼⽆上的财富，我开始学习如何与⼈打交道，如何做需求分析，如何将需求转变为技术，如何带领团队⼩伙伴⼀起⼯作。学到了太多太多，但我依然选择在我⼯作第四个年头⾥离开了动量软件，我刚加⼊动量软件的时候，公司只有 5 个⼈（包括⽼板和前台），当我离开动量软件的时候，公司已经有 200 ⼈左右了。感谢黄⽼师！我在他⾝上学到了很多，他的思想和态度直到今天都还在影响着我。
我的第⼆份⼯作还是选择了我最熟悉的证券⾦融⾏业，同样也是⼀家创业型公司，在这家公司⾥我担任了技术经理，管理了整个技术团队，从项⽬的售前到售后，我都亲⾃带领团队来完成。虽然在这家公司我只做了两年，但在这短短的时间⾥，我学会了如何提⾼开发效率、如何培养技术团队、如何选拔技术⼈才、如何建⽴企业⽂化。但最后我发现了⼀个问题，越是想做好，越是很难做好，为了做成⼀件事情需要做很多的尝试，做事情缺乏正确并有效的⽅法。
回想我⼯作的前六年时间⾥，我⼀直都是在创业公司⾥成长，虽然可以快速学到东西，但似乎很难学到更加规范的做事⽅法。于是我选择了新的⼯作机会，来到了 TCL 通讯，这是⼀家相当⼤的公司，公司的研发管理流程来源于法国阿⾥卡特公司。我在公司担任 Java 架构师职位，也算是整个 Java 团队的技术负责⼈，虽然团队并不是特别地⼤。我在这家公司做了三年，学到了如何整合现有资源、如何按标准流程去做事、如何设计系统架构、如何进⾏异地⼯作、如何跨团队⼯作、如何⽤英⽂来沟通。
说实话，当时我没有任何的⼯作压⼒，可以按时上下班，从来都不会加班。虽然⾃⼰空闲的时间很多，但我并没有选择去浪费时间，⽽是开始写点技术博客，也正是因为这些技术⽂章，才改变了我后续的职业发展道路。
我清楚的记得，那是在 2013 年 9 ⽉ 1 ⽇，我在开源中国（oschina）⽹站发表了我⼈⽣的第⼀篇博⽂，这篇⽂章影响了我后续两年。其实说句⼼⾥话，当我第⼀次写这篇⽂章时，我⼼⾥是没底的，这个框架只是根据⾃⼰的理解做出来的⼀个设想，当时甚⾄连⼀⾏代码都没写过。我的想法是先将这个思想发表出来，让⼤家讨论起来，我会做⼀个决策，然后再亲⾃做具体实现，最后我会将实现过程通过博⽂的⽅式展现给⼤家，后续⼤家会对我的实现进⾏点评，我会基于⼤家的建议进⾏改善。整个开源过程正好与敏捷的思想是⼀致的，有效沟通、⼩步快跑、拥抱变化、不断改进。
也许就是我的技术⽂章吸引了很多⼴⼤读者，这⾥⾯不排除想邀请我加⼊的其它公司。我在 2014 年离开了 TCL 通讯，加⼊了易传媒。为什么我要放弃如此舒适的⼯作环境，去加⼊⼀家还在不断拼搏的企业呢？其实我看到的是未来互联⽹的发展趋势，⼴告程序化交易以及⼴告与⼤数据的结合，未来最值钱的⼀定是数据。抱着这样的信⼼，我加⼊了易传媒，担任系统架构师职位。当时易传媒正处于技术转型的初期，需要将 .Net 全部迁移到 Java，这件事情对于我⽽⾔是⾮常有挑战的。我的做法是：第⼀步定义开发规范与流程，第⼆步培养核⼼技术⼈员，第三步分阶段进⾏改造。仅半年时间，我们所有的产品成功地迁移到了 Java 平台，结果出乎⼤家的想象。公司市场也⾮常不错，产品得到了业界
的认可，订单数源源不断，⼤家每天都很忙碌，但却很开⼼。⽽易传媒的“易家⼈”企业⽂化，让我所感动，不管是核⼼技术部门还是其它⽀持性部门，⼤家就像⼀家⼈⼀样，你的事情就是我的事情。
直到 2015 年初，阿⾥巴巴与易传媒建⽴了合作关系，两家公司进⾏了深度合作，易传媒公司与阿⾥妈妈事业部进⾏了整合，新阿⾥妈妈从此诞⽣了，于是我也成为了阿⾥巴巴的⼀员，⽬前负责阿⾥妈妈⼤数据品牌营销产品的系统架构⼯作。就在两家公司整合的过程中，我完成了⼈⽣中的处⼥作《架构探险 —— 从零开始写 Java Web 框架》这本书，⽬前该书正在各⼤⽹上书店售卖，我真⼼希望这本书能对⼀些想成为架构师的程序员们有所帮助，由于我个⼈⽔平有限，⼜是第⼀次写书，写得不好的地⽅还请⼤家多多包涵。
CSDN：上⾯提到，写博客给你带来的收获颇多，能不能分享下技术⼈如何写博客？⼜应该以怎样的态度对待？
黄勇：我认为技术⼈员写博客需要注意以下⼏点：
1. 思路要清晰，⽂章要有明确的⼤纲与标题。
2. 对于实战类型的⽂章，需要分步骤来描述。
3. 多⽤短句，少⽤长句，能⼀句话说明⽩，就不⽤两句话。
4. 对于不太好理解的内容，最好能打⽐⽅来说明。
5. ⽂章末尾需要有总结，⽤最精辟的语⾔归纳出这篇⽂章的主要内容。
写博客⾸先是对⾃⼰所学知识的⼀个总结，此外，也为其他读者提供了很好的教程，知识得到了⼴播与传递。
CSDN：技术⼀条不归路，选择了这条路是否有过放弃的想法？
黄勇：做了⼗年的技术，我从来都没有放弃过它，相反，我⾮常热爱它，因为我⼀直以来都很喜欢学习，希望能学到更多的东西，这样遇到了具体的技术问题，可以随时从⾃⼰积累的知识库中到最佳的解决⽅案。此外，⽬前我在公司虽然不怎么写代码了，但我还是会利⽤⾃⼰⼯作闲暇之余写⼀点开源项⽬或者代码框架等。
CSDN：你⼯作过很多⼤⼤⼩⼩的公司，你认为公司最值钱的东西是什么？
黄勇：我认为是实实在在做事情的程序员们。
他们虽然⼯资不⾼，每天坐在位置上敲着代码，在很多⼈眼中被称为“屌丝”或“宅男”，但我认为恰恰就是这些⼈，他们才是公司最有价值的⼈。
他们有⾃⼰的理想，希望能够通过⾃⼰的努⼒，从中得到那⼀点点所谓的成就感；
他们需要理解产品经理真正的意图，把想法变成现实，让产品真正落地；
他们更容易把握细节，⽽这些细节往往决定着产品的命运与成败；
他们突如其来的跳槽，对我们的项⽬的交付有直接的影响；
他们在⼀起⼯作的⽓氛，能体现技术公司的⽂化与底蕴。
由此看来，对程序员的重视是相当有必要的，我们需要关⼼每⼀位程序员的职业发展，让他们在团队⾥能够充分地发挥出⾃⼰的能⼒。
我们也需要对他们倍加关注，挖掘出有能⼒、肯吃苦、敢担当的⼈，给他们更多的机会，让他们成为技术领袖。
互联⽹技术公司需要⼤量这样的程序员：
他们是⼀有着技术信仰的⼈，他们是⼀热爱编程的⼈，他们是⼀不解决问题睡不好觉的⼈；
他们不是打杂的，不是外包，更不是⼯具；
他们不喜欢被忽悠，不喜欢被冷落，更不喜欢被驱动；
他们需要尊重，需要培养，更需要激情！
CSDN：你能具体说说程序员需要具备哪些素质吗？
黄勇：我个⼈是这样理解真正的程序员的：
1. 深爱技术，⼀天不写代码⼿就会痒，就喜欢那种成就感；
2. 为了⼀个问题可以废寝忘⾷，有时会在梦中都能写代码；
3. 代码洁癖症患者，喜欢优雅代码，写代码就像写诗⼀样；
4. 善于分析问题，能快速看清问题的本质，并动⼿解决它；
5. 喜欢研究优秀源码，学习⼤师的杰作，善于归纳与总结；
6. 有⾃⼰的开源项⽬或技术博客，喜欢学习，更喜欢分享；
7. 会关注技术圈⼦的新闻动态，时常会参加线下技术沙龙；
8. 知道软件开发不是⼀个⼈在战⽃，更需要的是团队协作；
9. 保持良好健康的⼼态，⽤⼀颗积极向上的⼼去拥抱变化。
CSDN：⼗年的职场之路坚持不易，能够分享下你的「IT 职场」经验？
黄勇：时光飞逝，我事业中第⼀个⼗年已然结束了。在这⼗年⾥，让我收获了很多，跟⼤家分享⼀下我在 IT 职场⽅⾯的⼀些个⼈经验，不⼀定对每个⼈都实⽤，请⼤家仅作参考吧。
⼤家既然都是做技术的，那我们不妨先从技术这个话题开始说起吧。我要与⼤家分享的第⼀点经验就是：
1. 把技术当成⼯具
技术这东西，其实⼀点都不神秘，它只不过是⼀个⼯具，⽤这个⼯具可以帮助我们解决实际问题，就这么简单。
我们每天在⾯对技术，市⾯上也有很多技术，真的没有必要把这些技术都拿过来学习⼀遍，然后想办法个场景去应⽤它。如果真的这样做了，那么只能说明技术不是⼯具，⽽是玩具，技术不是这样玩的。
我们应该从另⼀个⾓度来看待技术，不妨从⾃⼰的实际⼯作环境出发，现在需要什么，我们就学什么，⽽不要漫⽆⽬的的追求⼀些新技术。当然，对于新技术还是需要有所关注的，⾄少需要知道这个新技术是⼲什么⽤的，⽽且还要善于总结，将有价值的技术收集起来，以备将来使⽤，当需要使⽤的时候再来深⼊研究。
⼈的精⼒是有限的，⼈的⽣命也是短暂的，要善于利⽤⾃⼰的时间，合理地学习技术。
不要把技术看得那么重要，别把它当回事⼉，把它当⼯具就⾏了，它就像我们写字的笔⼀样，⽤铅笔能写字，⽤钢笔⼀样能写字。
作为⼀名技术⼈员，除了学习与应⽤技术以外，还需要为⾃⼰做⼀个正确的职业规划，清晰认识⾃⼰究竟属于哪种技术⼈才，是技术专家类型的，还是技术管理类型的。路到底该怎么⾛？需要⾃⼰做出决定。
在我们职业路线上，最重要的⼈莫过于⽼板（我指的⽼板可以是公司⼤⽼板，也可以是⾃⼰的顶头上司），对待⾃⼰的⽼板，我也有⼀些经验：
2. 把⽼板当成情⼈
⼤家应该⾮常清楚，情⼈是需要浪漫的，浪漫是需要惊喜的。⽼板其实跟情⼈⼀样，也是需要惊喜的。
我们做下属的，要懂得到合适的机会给⽼板带来惊喜。我们跟情⼈谈情说爱，这是⼀种很好的沟通⽅式，可别忽略了跟⽼板“谈情说爱”，我们需要与⽼板保持良好的沟通，这种沟通并不仅仅是溜须拍马。
讲⼀个真实的故事吧。记得曾经我的⼀位同事，技术⾮常好，做东西⾮常快，质量也很⾼，同事们都觉得他是⽜⼈，但他从来都不懂得在⽼板⾯前表现⾃⼰，⽼板也只是觉得他是可以做事的，但升职加薪的事情往往总是不会优先考虑他。
⼤家很定会问：怎样在⽼板⾯前表现⾃⼰呢？其实⽅法有很多，由于篇幅有限，我先提供三招吧：
第⼀招：在给⽼板做程序演⽰的时候，不要只是单纯的演⽰，不妨先⽤⼀个 PPT，简单表达⼀下⾃⼰的解决⽅案，然后再做演⽰，这样效果会好很多。⽼板会认为⾃⼰是花了⼼思的，是想把事情做得更好的。
第⼆招：把⾃⼰每天的⼯作简单记录⼀下，每周汇总⼀次，以邮件的形式发送给⽼板，让⽼板知道⾃⼰每天在做什么。每⽉写⼀篇本⽉⼯作总结与下⽉⼯作计划，同样发邮件给⽼板。年底可以写⼀个年终⼯作总结，打印出来，悄悄地放在⽼板的桌⼦上。
第三招：借汇报⼯作为理由，定期请⽼板出去吃饭，制造⾯对⾯单独沟通的机会。在谈话过程中，强调⾃⼰愿意帮助⽼板分担⼯作压⼒。
对待⽼板其实很简单，只要能帮他做事，⼜能让他开⼼，他基本上就搞定了。⽼板搞定了，⾃⼰的职业发展才会平步青云。但千万别忽略了还有⼀⼈，他们或许是⾃⼰的团队战友，或许是⾃⼰的竞争对⼿，没错！他们就是同事。如何处理同事关系呢？以下便是我的经验：
3. 把同事当成⼩孩
处理与同事关系，其实⽐处理与⽼板关系要稍微复杂⼀点，因为同事有多种⾝份，他们可以是队友，也可以是对⼿。如果⼤家在⼀起做同⼀个项⽬，那么这样的同事就是队友；如果为了竞争某个项⽬、岗位、资源，导致同级别的同事之间发⽣利益上的竞争，那么这样的同事就是对⼿。
对于队友⽽⾔，要学会主动给他们提供帮助，让⼤家能够体会到团队协作的⽓氛，在⼀起学习，在⼀起成长，在⼀起分享。可以时常跟⼤家⼀起聚餐，买点零⾷让⼤家品尝。
队友关系往往⽐较好处理，关键在于⾃⼰能否真正懂得去分享。很多技术⼈员，最不愿意的就是分享，因为担⼼⾃⼰花了很多精⼒学到的知识，分分钟就被别⼈学会了，⾃⼰失去了优势。这种⼼态最好不要在团队⾥产⽣，这样只会让⾃⼰变得越来越封闭，越来越渺⼩，队友们也会逐渐排挤⾃⼰。
对于对⼿⽽⾔，要想办法让⾃⼰成为他的兄弟，告诉他，咱们是兄弟，应该相互帮助。如果有机会，可以在⽼板⾯前，当着对⼿的⾯，夸奖⾃⼰的对⼿。做出这样的⾏为，其实并不会让⽼板觉得⾃⼰不
如对⼿，⽽会让⽼板认为⾃⼰在⽤⼼去容纳对⼿。⼤家在⼀起⼯作，就是⼀种缘分，都是跟⽼板打⼯的，真的没有必要搞得不愉快。
其实同事就是⾃⼰的⼩伙伴，不妨把他们当成是单纯可爱的⼩孩吧，⽤⾃⼰的⼼去“收买”他们。
⽼板与同事，他们都是公司内部的⼈，不管怎么说，⼤家都在同⼀条船上，⼤家可以关上门吵⼀架，只要事情能够解决就⾏。但对于我们的客户⽽⾔，就需要⽤另外⼀种⽅法来处理好关系了。我是这样认为的：
4. 把客户当成病⼈
客户有需求，但没有技术，⽽我们有技术、有经验、有产品，正好可以帮助他们实现需求，从⽽提⾼他们的⼯作效率，这样客户才会⼼⽢情愿地把钱放⼊我们的⼝袋。所以，在客户⾯前，我们要表现出⾼超的专业精神，不要被客户牵着我们的⿐⼦⾛，我们在客户⾯前就是技术权威，就需要这样的⾃信。从服装、⾔⾏、邮件、⽂档等各个⽅⾯，都要做到专业。
我们打算把⾃⼰的产品卖给客户的时候，千万不要⼀上来就对⾃⼰的产品夸夸其谈，这往往会让客户感到厌烦。我们不妨先告诉客户，他们已经“⽣病”了，⽽且病得不轻，如果不及时⽤药的话，后果将不堪设想。也就是说，要让客户意识到⾃⼰现在所⾯临的困境，让客户紧张，当他们正在思考如何应对的时候，我们再告诉他们，“药”已经准备好了，可以随时服⽤。
要让客户有种雪中送炭的感觉，这样就对了，他们⼀定会主动了解我们的产品。我们要做到这⼀切，必须花精⼒来分析⾏业现状，揣测客户⽼板们每天在想什么。如果有机会进
⼊客户所在的公司⼯作⼀段时间，相信⾃⼰的感受会更加深⼊。
Java 会在很长的⼀段时间内是主流
CSDN：能否先简答介绍下你的最新⼒作《架构探险——从零开始写Java Web框架》？⾯向的体是怎样的？有什么特别之处？
黄勇：建议有⼀定 Java Web 开发经验的读者阅读这本书，当然，如果⼤家想通过这本书来学习 Java Web 核⼼技术也是⾮常不错的，因为书中会有⼤量的实例来讲解 Java 必备的基础技能。此外，建议读者们能亲⾃动⼿去实践，虽然书中所有的源代码可以⾃由获取，但我不建议⼤家只是看看代码是怎么写的，⽽错过了⼀次很好的练⼿机会，因为所有的开发技能都需要不断地练习，孰能⽣巧，巧能⽣辉。
CSDN：《架构探险——从零开始写Java Web框架》是你撰写的第⼀技术书，是什么原因促使你写这本的？
黄勇：记得那是在 2014 年 11 ⽉底，我有幸结识了电⼦⼯业出版社博⽂视点编辑部的陈晓猛⽼师。陈
⽼师建议我写⼀本书，但我当时真的不知道该写什么，我想可能
在 Java Web ⽅⾯还可以尝试写点东西吧，于是在他的⿎励与帮助下，我就开始写书了。陈⽼师告诉我，写书其实就像写博客⼀样，当初我真这么觉得的，可是个⼈能⼒和经验还是⾮常有限，第⼀次写了 50 页就再也写不下去了，第⼆次竟然写到了 100 页，最后觉得⾃⼰的写作思路有问题，还是放弃了，直到第三次我才把结构梳理清楚，⼀⽓呵成地写完了整本书。在这个过程中，是我妻⼦⿎励并监督着我，那时我们的宝宝刚出⽣不久，每天在家⾥哭泣，我妻⼦把我⼀个⼈关在房间⾥，她独⾃⼀⼈带⼩孩，并操持着所有的家务，就是为了给我⼀个安静的环境，让我可以敞开思路，写出更加优秀的作品。在此，请允许我对我妻⼦说⼀声：⾟苦了！我永远爱你！
CSDN：写书不是⼀件容易的事情，能不能谈谈在这段期间的⾟酸和收获？
黄勇：虽然写书的过程⽐较艰⾟，但对我个⼈却有很⼤的收获：
1. 通过写书这件事情，让我学会了坚持，想做⼀件事情很简单，但想把这件事情做成却没那么容易。
2. 通过写书我重新对轻量级 Java Web 框架做更深层次的理解，⼀个好的框架不是看功能有多强⼤，⽽在于它的扩展性有多好。毕竟功能是做不完的，需要有⼀个“微内
核 + 多插件”的思想，核⼼是⾮常⼩的，它仅提供了整个框架的必备功能以及相关的扩展点，然后需要
将不同的功能封装在不同的插件中，并为更多其他的开发者提供统⼀的扩展⽅式。
3. 我希望这本书不再是教会读者如何去使⽤开源框架，⽽是让读者学会如何从零开始去编写开源框架，并⿎励读者发挥⾃⼰的⼒量，⼀起投⾝到开源社区中。
CSDN：为什么开发Java Web都要⽤框架？
黄勇：我个⼈觉得框架有以下⼏点作⽤：
1. 让开发更加⾼效，屏蔽底层技术细节，让开发⼈员关注在具体业务上。
2. 框架实际上也是⼀种规范，可以让每位开发⼈员保持同样的编码风格。
3. 会使⽤主流框架的开发⼈员，在⼈才市场上⽐较好获取。
CSDN：现在做Java Web开发都⽤哪些框架呢？
黄勇：常⽤的⽐如Spring MVC、Struts2 等，国内的 JFinal、Nutz 等也不错，当然Smart 也是⼀个很好的选择。
CSDN：有⼀定Web前端开发经验的⼈，很多都会有这么个想法：那些写框架的⼈好厉害，什么时候
我才能写⼀个⾃⼰的框架呢？有时候看看别⼈的框架代码，⼜觉得很复杂，对此你有什么建议吗？以及新⼈学习需要什么基础？有哪些好的⽅法分享？
黄勇：对于接触 Java 不太久的朋友，建议按照以下⼏个步骤来学习：
1. 学习 Java 基础语法与核⼼技术，包括 Servlet、JSP、JDBC 等。
2. 熟练使⽤流⾏开源框架，包括Spring、MyBatis 等。零基础学java编程
3. 研究开源框架源码，并吸取其中优秀的架构。
此外，在学习的过程当中，建议做学习笔记，最好能通过博客的⽅式来记录⾃⼰的收获。
CSDN：使⽤ Python、Perl、PHP、Ruby 等脚本语⾔开发 Web 程序，跟使⽤ Java 开发 Web 程序相⽐有什么不同或者优劣？
黄勇：前者属于动态语⾔，⽆需编译，可通过解释的⽅式来运⾏，⽽且 Java 需要⾸先通过编译，将源⽂件转为字节码，且载⼊ Java 虚拟机才能运⾏，相对来说，Java 对环境的要求较⾼，但 Java 具备更强的⾯向对象能⼒。此外，Java 还拥有较⼴的开源社区以及流⾏的开源中间件。因此，如果是做⼤型系统，建议使⽤ Java 来开发，⽽并⾮那些脚本语⾔。
CSDN：针对 Web，Java、PHP、Python、.NET 之中未来发展前景最好的会是什么？
黄勇：我认为 Java 在未来还会有⼀段很长的路，需要在语⾔本⾝上做到更加轻量级，⽤最少的代码来实现⽬标功能；PHP 相对来说会⽐较平稳，它的特点⾮常突出，上⼿快且易于开发 Web 项⽬；Python仍然不会有太⼤的⽤户体；.NET 加⼊开源社区太晚，且较 Java ⽽⾔并没有太强的优势，可能会⾛下坡路。
CSDN：在软件开发中有很多的设计模式，也有⼀些很⾼冷，能否谈谈你对软件设计的理解，以及让⼀些设计原则接地⽓？
黄勇：了解设计模式的朋友们，想必都听说过“六⼤设计原则”吧。其实最经典的 23 种设计模式中或多或少地都在使⽤这些设计原则，也就是说，设计模式是站在设计原则的基础之上的。所以在学习设计模式之前，很有必要对这些设计原则先做⼀下了解。
GoF（四⼈帮），传说中的四位⼤神们，他们联⼿搞出了⼀套设计模式，堪称 OOD（⾯向对象设计）的经典之作！震惊了整个软件开发领域。但这四个⽼家伙⾮常怪异，总是喜欢显摆⼀些⾼深的理论，甚⾄有时候不说⼈话，⼗分让⼈费解。
除了最经典的六⼤设计原则以外，还有⼀些其他的设计原则也⾮常重要。我将尽可能地解释这些晦涩
的理论，希望看完之后，会让您对这些设计原则稍微加深⼀些理解。若有不正确的地⽅，恳请⼤家指正！
六⼤设计原则
先看⼀幅图吧：
这幅图清晰地表达了六⼤设计原则，但仅限于它们叫什么名字⽽已，它们具体是什么意思呢？下⾯我将从原⽂、译⽂、理解、应⽤，这四个⽅⾯分别进⾏阐述。
1. 单⼀职责原则（Single Responsibility Principle - SRP）
原⽂：There should never be more than one reason for a class to change.
译⽂：永远不应该有多于⼀个原因来改变某个类。
理解：对于⼀个类⽽⾔，应该仅有⼀个引起它变化的原因。说⽩了就是，不同的类具备不同的职责，各施其责。这就好⽐⼀个团队，⼤家分⼯协作，互不影响，各做各的事情。
应⽤：当我们做系统设计时，如果发现有⼀个类拥有了两种的职责，那就问⾃⼰⼀个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让⼀个类⼲的事情太多！
2. 开放封闭原则（Open Closed Principle - OCP）
原⽂：Software entities like classes, modules and functions should be open for extension but closed for modifications.
译⽂：软件实体，如：类、模块与函数，对于扩展应该是开放的，但对于修改应该是封闭的。
理解：简⾔之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。
应⽤：当需求有改动，要修改代码了，此时您要做的是，尽量⽤继承或组合的⽅式来扩展类的功能，⽽不是直接修改类的代码。当然，如果能够确保对整体架构不会产⽣任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。
3. ⾥⽒替换原则（Liskov Substitution Principle - LSP）
原⽂：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
译⽂：使⽤基类的指针或引⽤的函数，必须是在不知情的情况下，能够使⽤派⽣类的对象。
理解：⽗类能够替换⼦类，但⼦类不⼀定能替换⽗类。也就是说，在代码中可以将⽗类全部替换为⼦类，程序不会报错，也不会在运⾏时出现任何异常，但反过来却
不⼀定成⽴。
应⽤：在继承类时，务必重写（Override）⽗类中所有的⽅法，尤其需要注意⽗类的 protected ⽅法（它们往往是让您重写的），⼦类尽量不要暴露⾃⼰的 public ⽅
法供外界调⽤。
该原则由⿇省理⼯学院的 Barbara Liskov ⼥⼠提出，她是美国第⼀位获取计算机博⼠学位的⼥性，曾经也获得过计算机图灵奖。
4. 最少知识原则（Least Knowledge Principle - LKP）
原⽂：Only talk to you immediate friends.
译⽂：只与你最直接的朋友交流。
理解：尽量减少对象之间的交互，从⽽减⼩类之间的耦合。简⾔之，⼀定要做到：低耦合，⾼内聚。
应⽤：在做系统设计时，不要让⼀个类依赖于太多的其他类，需尽量减⼩依赖关系，否则，您死都不知道⾃⼰怎么死的。
该原则也称为“迪⽶特法则（Law of Demeter）”，由 Ian Holland 提出。这个⼈不太愿意和陌⽣⼈说话，只和他⾛得最近的朋友们交流。
5. 接⼝隔离原则（Interface Segregation Principle - ISP）
原⽂：The dependency of one class to another one should depend on the smallest possible interface.
译⽂：⼀个类与另⼀个类之间的依赖性，应该依赖于尽可能⼩的接⼝。
理解：不要对外暴露没有实际意义的接⼝。也就是说，接⼝是给别⼈调⽤的，那就不要去为难别⼈了，尽可能保证接⼝的实⽤性吧。她好，我也好。
应⽤：当需要对外暴露接⼝时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。⼀旦您提供了，就意味着，您将来要多做⼀件事情，何苦要给⾃⼰事做
呢。
6. 依赖倒置原则（Dependence Inversion Principle - DIP）
原⽂：
High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions 译⽂：⾼层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
理解：应该⾯向接⼝编程，不应该⾯向实现类编程。⾯向实现类编程，相当于就是论事，那是正向依赖（正常⼈思维）；⾯向接⼝编程，相当于通过事物表象来看本
质，那是反向依赖，即依赖倒置（程序员思维）。
应⽤：并不是说，所有的类都要有⼀个对应的接⼝，⽽是说，如果有接⼝，那就尽量使⽤接⼝来编程吧。
将以上六⼤原则的英⽂⾸字母拼在⼀起就是 SOLID（稳定的），所以也称之为 SOLID 原则。
只有满⾜了这六⼤原则，才能设计出稳定的软件架构！但它们毕竟只是原则，只是四⼈帮给我们的建议，有些时候我们还是要学会灵活应变，千万不要⽣搬硬套，否则只会把简
单问题复杂化，切记！
补充设计原则
1. 组合/聚合复⽤原则（Composition/Aggregation Reuse Principle - CARP）
当要扩展类的功能时，优先考虑使⽤组合，⽽不是继承。这条原则在 23 种经典设计模式中频繁使⽤，如：代理模式、装饰模式、适配器模式等。可见江湖地位⾮常
之⾼！
2. ⽆环依赖原则（Acyclic Dependencies Principle - ADP）
当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引⼊“中介者模式”解决该问题。
3. 共同封装原则（Common Closure Principle - CCP）
应该将易变的类放在同⼀个包⾥，将变化隔离出来。该原则是“开放-封闭原则”的延⽣。
4. 共同重⽤原则（Common Reuse Principle - CRP）
如果重⽤了包中的⼀个类，那么也就相当于重⽤了包中的所有类，我们要尽可能减⼩包的⼤⼩。
5. 好莱坞原则（Hollywood Principle - HP）
好莱坞明星的经纪⼈⼀般都很忙，他们不想被打扰，往往会说：Don't call me, I'll call you. 翻译为：不要联系我，我会联系你。对应于软件设计⽽⾔，最著名的就
是“控制反转”（或称为“依赖注⼊”），我们不需要在代码中主动的创建对象，⽽是由容器帮我们来创建并管理这些对象。
其他设计原则
1. 不要重复你⾃⼰（Don't repeat yourself - DRY）
不要让重复的代码到处都是，要让它们⾜够的重⽤，所以要尽可能地封装。
2. 保持它简单与傻⽠（Keep it simple and stupid - KISS）
不要让系统变得复杂，界⾯简洁，功能实⽤，操作⽅便，要让它⾜够的简单，⾜够的傻⽠。
3. ⾼内聚与低耦合（High Cohesion and Low Coupling - HCLC）
模块内部需要做到内聚度⾼，模块之间需要做到耦合度低。
4. 惯例优于配置（Convention over Configuration - COC）
尽量让惯例来减少配置，这样才能提⾼开发效率，尽量做到“零配置”。很多开发框架都是这样做的。
5. 命令查询分离（Command Query Separation - CQS）
在定义接⼝时，要做到哪些是命令，哪些是查询，要将它们分离，⽽不要揉到⼀起。
6. 关注点分离（Separation of Concerns - SOC）
将⼀个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。难就难在如何进⾏分离。
7. 契约式设计（Design by Contract - DBC）
模块或系统之间的交互，都是基于契约（接⼝或抽象）的，⽽不要依赖于具体实现。该原则建议我们要⾯向契约编程。
8. 你不需要它（You aren't gonna need it - YAGNI）
不要⼀开始就把系统设计得⾮常复杂，不要陷⼊“过度设计”的深渊。应该让系统⾜够的简单，⽽却⼜不失扩展性，这是其中的难点。
敏捷开发模式的修炼之道
CSDN：请问你是如何接触到敏捷开发的？你如何理解敏捷开发？
黄勇：曾经我们开发项⽬都是采⽤传统的“瀑布式”流程进⾏开发，即需求、设计、开发、测试、上线等阶段，其中每个阶段都有明确的交付时间点，且每个阶段都依赖于它的上个阶段，⼀旦需求有变化，就会影响后续的每个阶段，项⽬管理存在⼀定的风险。为了避免这个风险，做到更好地拥抱变化，我们尝试使⽤了敏捷开发⽅法，最为典型的
是 Scrum。我们参考Scrum 的流程结合⾃⾝的特点，总结了⼀套更容易落地的Scrum，后⾯我会跟⼤家讲到⼀些相关细节。
我理解的敏捷开发实际上是⼀个轻量级的项⽬管理规范，因为我们可以将整个⼤的需求范围拆分成若⼲迭代周期，我们为这些迭代周期设置明确的⾥程碑，且评估完成这些功能需要花费的成本，更重要的是，每次迭代完成以后，我们会对本次迭代进⾏⼀个回顾，取其精华，去其糟粕，不断完善，持续改进。
CSDN：你认为国内的敏捷开发何时能成为主流？敏捷开发的未来⾛向是什么？
黄勇：我认为敏捷开发现在已经成为了主流，传统开发模式已经出现了明显的缺陷，随着互联⽹的发展，软件开发的节奏会越来越快，变化也会越来越频繁，需要我们能够快速地发现变化，并进⾏及时地调整。
我认为敏捷开发的未来会变得更好，不仅仅在软件开发⾏业，⽽且可能会在其它⾏业⾥也会得到应⽤，因为从客户的⾓度来看，他们想要的是能通过最短的时间看到⾃⼰想要的东西，很多时候不做出⼀点东西出来，客户是没有任何想法的，所以需要将事情分解成多阶段，迭代完成每个阶段的⾥程碑，让客户满意，才是企业最⼤的收获。
CSDN：在你的⼯作⽣涯中，前期是在创业公司，后来是⼤公司，有着⼀套⾃⼰的敏捷开发模式，能够谈谈在你现在使⽤的敏捷开发⼯具或⽅法？
黄勇：敏捷这个话题⼤家⼀直都在谈论，也有很多关于敏捷的⼯具或⽅法，我个⼈⽐较倾向于 Scrum。我理解的敏捷其实是⼀种思想，Scrum 是对让这个思想落地的⼀个参考。也就是说，我们⼤可不必完全拘泥于 Scrum 定义的规范，只需要参考它并结合⾃⾝的条件做适当调整即可。⽐如说，每⽇站会这个环节就⾮常重要，不管是放在每天上午，还是放在每天下午，总之最好要有固定的周期。此外，每次 Sprint（迭代）结束后除了有评审会以外，Scrum Master 不要忘记对本次 Sprint 做⼀个回
顾与总结，哪些是本次迭代中做的好的地⽅，哪些是做的不好的，再对⽐上次迭代的的结论，哪些是有改进的，哪些是新的问题。
Scrum 提供了三类⾓⾊，分别是：Product Owner（⼀般由产品经理担任）、Scrum Master（⼀般由开发经理担任）、Scrum Team（包括开发与测试⼈员），其
中，Scrum Master 的⾓⾊⾄关重要，对项⽬的成败起决定性作⽤。
阿⾥巴巴也在⼴泛使⽤ Scrum 敏捷开发模式，⽽且整个项⽬⼏⼗⼈都可以⽤ Scrum，只是⾸先需要将整个团队拆分成若⼲⼩团队，保证每个⼩团队按照 Scrum 进⾏操作，此外，再将每个⼩团队的 Scrum Master 召集在⼀起，再做⼀轮 Scrum，这就是所谓的 Scrum of Scrum。过程稍微复杂⼀点，但可以将敏捷⽤于更⼤的团队规模，并能保证敏捷的效果。
CSDN：你认为Scrum Master 的⾓⾊⾄关重要，对项⽬的成败起决定性作⽤。那敏捷开发中由产品经理担任Scrum Master会有什么问题？
黄勇：我个⼈不太建议由产品经理来担当Scrum Master，原因如下：
1. Scrum Master 关注的是项⽬开发视⾓，⽽产品经理关注的是产品功能视⾓，两者关注的视⾓是不⼀样的。
2. Scrum Master 需要有⼀定的技术开发功底，需要对开发⼯作量进⾏评估，也需要对技术实现进⾏评审，可能还会有⼀定的编码⼯作，⽽具有技术功底的产品经理毕竟太少
了，即便有的话，可能对技术⽅⾯也不会太深⼊。
3. 需要有⼀个⼈，他来对整个产品负责，这个⼈就是Product Owner，该⾓⾊最好由产品经理来担任。
CSDN：敏捷开发过程中测试团队的职责和产出是什么？
黄勇：在敏捷开发过程中，我认为测试团队的职责有以下⼏点：
1. 根据产品需求，定义测试⽤例。
2. 针对测试⽤例进⾏功能测试，并将测试的结果反馈给开发⼈员。
3. 负责搭建系统运⾏所需的环境，包括软件安装、数据初始化等。
CSDN：除了Scrum，还有XP、CM、FDD、ASD、DSDM等敏捷开发⽅法，如何去选择⼀个合适的敏捷开发⼯具或者⽅法呢？
黄勇：敏捷开发⽅法有很多，不仅仅只有Scrum ⼀种，其实不妨相互借鉴，再结合⾃⾝的特点，定义⼀套适合⾃⼰的敏捷开发⽅法。例如XP 中所提倡的结对编程、持续集成、测试驱动等，这些都是很好的⽅法，值得借鉴。包括看板也是⼀个很不错的⼯具，可以结合Scrum 来⼯作。
CSDN：从博客上，你也研究过「使⽤看板进⾏敏捷开发」，能不能分享你的研究成果？
黄勇：敏捷开发⼯具“看板”，该词汇来⾃于岛国，当我看到看板的英⽂时，我真的惊呆了，看板竟然就是 Kanban？！
我们可以结合 Scrum 与 Kanban，让项⽬管理更加有效，让资源分配更加合理，让绩效考核更加公平！
对于项⽬经理⽽⾔，最担⼼的就是项⽬进度不可控，不知道每位开发⼈员具体的⼯作进度，有了 Kanban ⼀切都是那么地清晰。
对于开发经理⽽⾔，最担⼼的就是资源分配不合理，忙的⼈忙死，闲的⼈闲死，有了 Kanban ⼀切都是那么地⾃然。
对于开发⼈员⽽⾔，最担⼼的就是绩效考核不公平，“凭什么我做的⽐他多，拿的⼯资却⽐他少？不公平啊！”有了 Kanban ⼀切都是那么地公平。
可见，项⽬经理、开发经理、开发⼈员拥有了 Kanban，也就拥有了和谐与快乐！
那么 Kanban 到底是什么呢？我们先来看看这张表格吧：
下⾯我们来理解⼀下这个表格吧！
这个表格有 5 列：Backlog（原始需求）、Selected（被选中的需求）、Develop（开发阶段）、Deploy（部署阶段）、Live（上线阶段）
其中 Develop 阶段包括 2 个⼦阶段：Ongoing（进⾏中）、Done（已完成）
包括 3 中⾓⾊：产品经理（红⾊⼩⼈）、开发⼈员（蓝⾊⼩⼈）、部署⼈员（绿⾊⼩⼈），其实还有项⽬经理，只是他/她贯穿于始终，所有就没有画出来了。
在 Backlog 中放置了许多⼩卡⽚，它们在 Kanban 中被称为 WIP（Work In Process，在制品）。对于产品经理⽽⾔，WIP 是需求，⽽对于开发⼈员与部署⼈员⽽⾔，WIP 却是任务。
实际这些 WIP 卡⽚上都带有⼀些⽂字描述，包括：标题、描述、优先级等信息。
需要注意的是，Selected、Develop、Deploy 下⽅有⼀个数字，该数字表⽰此阶段中最多可以放置的
WIP 数量。例如，在 Selected 中最多只能放 2 个 WIP；在 Develop 中（包括它的⼦阶段）最多只能放置 2 个 WIP。这⾥的数字只是⼀个⽰例，具体多少可根据团队实际情况⽽定。有⼀个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”，减 1 表⽰⼤家需要协作，例如：4 ⼈的团队，WIP 上限是 7。
也许有⼈会提出，为什么没有 Test 阶段？—— 这个可以有，这⾥只是⼀个⽰例⽽已，你不妨⾃⾏加上去。
对于多个项⽬⽽⾔，可以在这张表格中添加更多的泳道（⾏），每⼀⾏相当于⼀个项⽬，所有的项⽬进度清晰明了。
好！继续我们的 Kanban，有意思的事情即将发⽣！
产品经理挑选了 2 个 WIP 到 Selected 中，此时，由开发经理决定该任务的技术难度，并由项⽬经理将任务分配到指定的开发⼈员，也可将同⼀个任务分配给两个⼈，让他们去结对编程。
开发⼈员（架构师与程序员）可对 Selected 中的需求进⾏⼯作量评估，可采⽤投票的⽅式进⾏，最终给出⼀个合理的评估值，整个估算过程，项⽬经理⽆需参与，主要是开发⼈员共同完成。
开发经理可以对任务设置⼀个“分值”，这个分值可直接影响到后续的绩效考核，所以对⼤家来说，这个分值是公开可见的，谁做的多，谁做得少，⼀⽬了然。当然，开发⼈员也可以主动承担具有更具挑战
的任务（为了锻炼⾃⼰，也为了多拿点钱），但任务分配的决定权始终在项⽬经理⼿中。
现在假设 A、B 两个任务已经分别被不同的开发⼈员处理了，那么这些任务就应该移动到 Ongoing 中，同时，产品经理可以从 Backlog 中挑选出 2 个优先级较⾼的需求
到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。