黄勇,从事近十年的 JavaEE 应用开发工作,现任阿里巴巴公司系统架构师。对分布式服务架构与大数据技术有深入研究,具有丰富的 B/S 架构开发经验与项目实战经验,擅长敏捷开发模式。国内开源软件推动者之一,Smart Framework 开源框架创始人。热爱技术交流,乐于分享自己的工作经验。著有《架构探险——从零开始写Java web框架》一书。
我目前从事分布式服务架构的设计与开发工作,在阿里的大数据平台上进行应用程序开发。我们整个系统架构采用了“前后端分离”的思想,前端关注数据展现,后端关注数据生产,通过 REST服务将前后端整合起来,所有的应用都是无状态的,可以做到水平扩展。我们将整个系统拆分成许多“微服务”,服务之间通过统一的接口来调用,每个服务是通过容器技术进行隔离,此外服务可发布到统一的服务管理平台上,可通过该平台监控每个服务的运行状态与生命周期事件,并为服务调用者提供了服务发现的能力,可对服务进行平滑升级。
阿里有许多优秀的中间件与基础服务,可以快速帮助我们搭建应用系统,而且这些技术在阿里内部全是开源的,大家可以通过源码和文档学习到很多有价值的经验。阿里也提供了浓厚的技术氛围,每位同学都非常专注于自己的工作领域,大家对工作一丝不苟,相互配合,方向一致。
2006 年大学毕业,我离开了母校武汉理工大学,在院长薛胜军老师的推荐下,我来到了上海,这个对于我来说非常陌生的地方。我有幸加入了一家名为“动量软件”的创业公司,这家公司的老板曾经是亚信科技的 CTO,他也是普元软件的创始人兼 CTO,他的名字叫黄柳青,他也是薛老师的大学同学。于是就这样,我的老板成为了我的老师,我习惯叫他黄老师,包括公司其他资深的同事也成为了我的老师,因为我很想他们身上学到更多有价值的东西。
刚开始工作的时候我学习了什么是云计算?什么是 SaaS、PaaS、IaaS?我们花了三年时间开发了一款名为 ODE 的 PaaS 平台,让用户可以在该平台上量身定制自己的软件,最终为客户提供基于 SaaS 的产品。确实很骄傲,那时我们已经在做云了,只是没想到后来云会在中国得到这么好的市场,可能当时只有黄老师一个人想到了吧。
在 2008 年,我为公司拿回了“第一桶金”,这也是我从程序员转向项目经理的里程碑。当时我带领团队远赴深圳,为国信证券公司开发经纪人管理系统,这个项目对于我个人而言却是一笔至高无上的财富,我开始学习如何与人打交道,如何做需求分析,如何将需求转变为技术,如何带领团队小伙伴一起工作。学到了太多太多,但我依然选择在我工作第四个年头里离开了动量软件,我刚加入动量软件的时候,公司只有 5 个人(包括老板和前台),当我离开动量软件的时候,公司已经有 200 人左右了。感谢黄老师!我在他身上学到了很多,他的思想和态度直到今天都还在影响着我。
我的第二份工作还是选择了我最熟悉的证券金融行业,同样也是一家创业型公司,在这家公司里我担任了技术经理,管理了整个技术团队,从项目的售前到售后,我都亲自带领团队来完成。虽然在这家公司我只做了两年,但在这短短的时间里,我学会了如何提高开发效率、如何培养技术团队、如何选拔技术人才、如何建立企业文化。但最后我发现了一个问题,越是想做好,越是很难做好,为了做成一件事情需要做很多的尝试,做事情缺乏正确并有效的方法。
回想我工作的前六年时间里,我一直都是在创业公司里成长,虽然可以快速学到东西,但似乎很难学到更加规范的做事方法。于是我选择了新的工作机会,来到了 TCL 通讯,这是一家相当大的公司,公司的研发管理流程来源于法国阿里卡特公司。我在公司担任 Java 架构师职位,也算是整个 Java 团队的技术负责人,虽然团队并不是特别地大。我在这家公司做了三年,学到了如何整合现有资源、如何按标准流程去做事、如何设计系统架构、如何进行异地工作、如何跨团队工作、如何用英文来沟通。说实话,当时我没有任何的工作压力,可以按时上下班,从来都不会加班。虽然自己空闲的时间很多,但我并没有选择去浪费时间,而是开始写点技术博客,也正是因为这些技术文章,才改变了我后续的职业发展道路。
我清楚的记得,那是在 2013 年 9 月 1 日,我在开源中国(oschina.net)网站发表了我人生的第一篇博文 《Smart Framework:轻量级 Java Web 框架》 ,这篇文章影响了我后续两年。其实说句心里话,当我第一次写这篇文章时,我心里是没底的,这个框架只是根据自己的理解做出来的一个设想,当时甚至连一行代码都没写过。我的想法是先将这个思想发表出来,让大家讨论起来,我会做一个决策,然后再亲自做具体实现,最后我会将实现过程通过博文的方式展现给大家,后续大家会对我的实现进行点评,我会基于大家的建议进行改善。整个开源过程正好与敏捷的思想是一致的,有效沟通、小步快跑、拥抱变化、不断改进。
也许就是我的技术文章吸引了很多广大读者,这里面不排除想邀请我加入的其它公司。我在 2014 年离开了 TCL 通讯,加入了易传媒。为什么我要放弃如此舒适的工作环境,去加入一家还在不断拼搏的企业呢?其实我看到的是未来互联网的发展趋势,广告程序化交易以及广告与大数据的结合,未来最值钱的一定是数据。抱着这样的信心,我加入了易传媒,担任系统架构师职位。当时易传媒正处于技术转型的初期,需要将 .Net 全部迁移到 Java,这件事情对于我而言是非常有挑战的。我的做法是:第一步定义开发规范与流程,第二步培养核心技术人员,第三步分阶段进行改造。仅半年时间,我们所有的产品成功地迁移到了 Java 平台,结果出乎大家的想象。公司市场也非常不错,产品得到了业界的认可,订单数源源不断,大家每天都很忙碌,但却很开心。而易传媒的“易家人”企业文化,让我所感动,不管是核心技术部门还是其它支持性部门,大家就像一家人一样,你的事情就是我的事情。
直到 2015 年初,阿里巴巴与易传媒建立了合作关系,两家公司进行了深度合作,易传媒公司与阿里妈妈事业部进行了整合,新阿里妈妈从此诞生了,于是我也成为了阿里巴巴的一员,目前负责阿里妈妈大数据品牌营销产品的系统架构工作。就在两家公司整合的过程中,我完成了人生中的处女作《架构探险 —— 从零开始写 Java Web 框架》这本书,目前该书正在各大网上书店售卖,我真心希望这本书能对一些想成为架构师的程序员们有所帮助,由于我个人水平有限,又是第一次写书,写得不好的地方还请大家多多包涵。
我认为技术人员写博客需要注意以下几点:
思路要清晰,文章要有明确的大纲与标题。
对于实战类型的文章,需要分步骤来描述。
多用短句,少用长句,能一句话说明白,就不用两句话。
对于不太好理解的内容,最好能打比方来说明。
文章末尾需要有总结,用最精辟的语言归纳出这篇文章的主要内容。
写博客首先是对自己所学知识的一个总结,此外,也为其他读者提供了很好的教程,知识得到了广播与传递。
做了十年的技术,我从来都没有放弃过它,相反,我非常热爱它,因为我一直以来都很喜欢学习,希望能学到更多的东西,这样遇到了具体的技术问题,可以随时从自己积累的知识库中找到最佳的解决方案。此外,目前我在公司虽然不怎么写代码了,但我还是会利用自己工作闲暇之余写一点开源项目或者代码框架等。
我认为是实实在在做事情的程序员们。
他们虽然工资不高,每天坐在位置上敲着代码,在很多人眼中被称为“屌丝”或“宅男”,但我认为恰恰就是这些人,他们才是公司最有价值的人。
由此看来,对程序员的重视是相当有必要的,我们需要关心每一位程序员的职业发展,让他们在团队里能够充分地发挥出自己的能力。
我们也需要对他们倍加关注,挖掘出有能力、肯吃苦、敢担当的人,给他们更多的机会,让他们成为技术领袖。
互联网技术公司需要大量这样的程序员:
我个人是这样理解真正的程序员的:
时光飞逝,我事业中第一个十年已然结束了。在这十年里,让我收获了很多,跟大家分享一下我在 IT 职场方面的一些个人经验,不一定对每个人都实用,请大家仅作参考吧。
大家既然都是做技术的,那我们不妨先从技术这个话题开始说起吧。我要与大家分享的第一点经验就是:
1.把技术当成工具
技术这东西,其实一点都不神秘,它只不过是一个工具,用这个工具可以帮助我们解决实际问题,就这么简单。
我们每天在面对技术,市面上也有很多技术,真的没有必要把这些技术都拿过来学习一遍,然后想办法找个场景去应用它。如果真的这样做了,那么只能说明技术不是工具,而是玩具,技术不是这样玩的。
我们应该从另一个角度来看待技术,不妨从自己的实际工作环境出发,现在需要什么,我们就学什么,而不要漫无目的的追求一些新技术。当然,对于新技术还是需要有所关注的,至少需要知道这个新技术是干什么用的,而且还要善于总结,将有价值的技术收集起来,以备将来使用,当需要使用的时候再来深入研究。
人的精力是有限的,人的生命也是短暂的,要善于利用自己的时间,合理地学习技术。
不要把技术看得那么重要,别把它当回事儿,把它当工具就行了,它就像我们写字的笔一样,用铅笔能写字,用钢笔一样能写字。
作为一名技术人员,除了学习与应用技术以外,还需要为自己做一个正确的职业规划,清晰认识自己究竟属于哪种技术人才,是技术专家类型的,还是技术管理类型的。路到底该怎么走?需要自己做出决定。
在我们职业路线上,最重要的人莫过于老板(我指的老板可以是公司大老板,也可以是自己的顶头上司),对待自己的老板,我也有一些经验:
2.把老板当成情人
大家应该非常清楚,情人是需要浪漫的,浪漫是需要惊喜的。老板其实跟情人一样,也是需要惊喜的。我们做下属的,要懂得找到合适的机会给老板带来惊喜。我们跟情人谈情说爱,这是一种很好的沟通方式,可别忽略了跟老板“谈情说爱”,我们需要与老板保持良好的沟通,这种沟通并不仅仅是溜须拍马。
讲一个真实的故事吧。记得曾经我的一位同事,技术非常好,做东西非常快,质量也很高,同事们都觉得他是牛人,但他从来都不懂得在老板面前表现自己,老板也只是觉得他是可以做事的,但升职加薪的事情往往总是不会优先考虑他。
大家很定会问:怎样在老板面前表现自己呢?其实方法有很多,由于篇幅有限,我先提供三招吧:
对待老板其实很简单,只要能帮他做事,又能让他开心,他基本上就搞定了。老板搞定了,自己的职业发展才会平步青云。但千万别忽略了还有一群人,他们或许是自己的团队战友,或许是自己的竞争对手,没错!他们就是同事。如何处理同事关系呢?以下便是我的经验:
3. 把同事当成小孩
处理与同事关系,其实比处理与老板关系要稍微复杂一点,因为同事有多种身份,他们可以是队友,也可以是对手。如果大家在一起做同一个项目,那么这样的同事就是队友;如果为了竞争某个项目、岗位、资源,导致同级别的同事之间发生利益上的竞争,那么这样的同事就是对手。
对于队友而言,要学会主动给他们提供帮助,让大家能够体会到团队协作的气氛,在一起学习,在一起成长,在一起分享。可以时常跟大家一起聚餐,买点零食让大家品尝。
队友关系往往比较好处理,关键在于自己能否真正懂得去分享。很多技术人员,最不愿意的就是分享,因为担心自己花了很多精力学到的知识,分分钟就被别人学会了,自己失去了优势。这种心态最好不要在团队里产生,这样只会让自己变得越来越封闭,越来越渺小,队友们也会逐渐排挤自己。
对于对手而言,要想办法让自己成为他的兄弟,告诉他,咱们是兄弟,应该相互帮助。如果有机会,可以在老板面前,当着对手的面,夸奖自己的对手。做出这样的行为,其实并不会让老板觉得自己不如对手,而会让老板认为自己在用心去容纳对手。大家在一起工作,就是一种缘分,都是跟老板打工的,真的没有必要搞得不愉快。
其实同事就是自己的小伙伴,不妨把他们当成是单纯可爱的小孩吧,用自己的心去“收买”他们。
老板与同事,他们都是公司内部的人,不管怎么说,大家都在同一条船上,大家可以关上门吵一架,只要事情能够解决就行。但对于我们的客户而言,就需要用另外一种方法来处理好关系了。我是这样认为的:
4. 把客户当成病人
客户有需求,但没有技术,而我们有技术、有经验、有产品,正好可以帮助他们实现需求,从而提高他们的工作效率,这样客户才会心甘情愿地把钱放入我们的口袋。所以,在客户面前,我们要表现出高超的专业精神,不要被客户牵着我们的鼻子走,我们在客户面前就是技术权威,就需要这样的自信。从服装、言行、邮件、文档等各个方面,都要做到专业。
我们打算把自己的产品卖给客户的时候,千万不要一上来就对自己的产品夸夸其谈,这往往会让客户感到厌烦。我们不妨先告诉客户,他们已经“生病”了,而且病得不轻,如果不及时用药的话,后果将不堪设想。也就是说,要让客户意识到自己现在所面临的困境,让客户紧张,当他们正在思考如何应对的时候,我们再告诉他们,“药”已经准备好了,可以随时服用。
要让客户有种雪中送炭的感觉,这样就对了,他们一定会主动了解我们的产品。我们要做到这一切,必须花精力来分析行业现状,揣测客户老板们每天在想什么。如果有机会进入客户所在的公司工作一段时间,相信自己的感受会更加深入。
我个人觉得框架有以下几点作用:
常用的比如Spring MVC、Struts2 等,国内的 JFinal、Nutz 等也不错,当然Smart 也是一个很好的选择。
对于接触 Java 不太久的朋友,建议按照以下几个步骤来学习:
此外,在学习的过程当中,建议做学习笔记,最好能通过博客的方式来记录自己的收获。
前者属于动态语言,无需编译,可通过解释的方式来运行,而且 Java 需要首先通过编译,将源文件转为字节码,且载入 Java 虚拟机才能运行,相对来说,Java 对环境的要求较高,但 Java 具备更强的面向对象能力。此外,Java 还拥有较广的开源社区以及流行的开源中间件。因此,如果是做大型系统,建议使用 Java 来开发,而并非那些脚本语言。
我认为 Java 在未来还会有一段很长的路,需要在语言本身上做到更加轻量级,用最少的代码来实现目标功能;PHP 相对来说会比较平稳,它的特点非常突出,上手快且易于开发 Web 项目;Python仍然不会有太大的用户群体;.NET 加入开源社区太晚,且较 Java 而言并没有太强的优势,可能会走下坡路。
了解设计模式的朋友们,想必都听说过“六大设计原则”吧。其实最经典的 23 种设计模式中或多或少地都在使用这些设计原则,也就是说,设计模式是站在设计原则的基础之上的。所以在学习设计模式之前,很有必要对这些设计原则先做一下了解。
GoF(四人帮),传说中的四位大神们,他们联手搞出了一套设计模式,堪称 OOD(面向对象设计)的经典之作!震惊了整个软件开发领域。但这四个老家伙非常怪异,总是喜欢显摆一些高深的理论,甚至有时候不说人话,十分让人费解。
除了最经典的六大设计原则以外,还有一些其他的设计原则也非常重要。我将尽可能地解释这些晦涩的理论,希望看完之后,会让您对这些设计原则稍微加深一些理解。若有不正确的地方,恳请大家指正!
先看一幅图吧:
这幅图清晰地表达了六大设计原则,但仅限于它们叫什么名字而已,它们具体是什么意思呢?下面我将从原文、译文、理解、应用,这四个方面分别进行阐述。
1.单一职责原则(Single Responsibility Principle - SRP)
来源: http://geek.csdn.net/news/detail/247960