副标题#e#
从事近十年的 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 日,我在开源中国网站发表了我人生的第一篇博文,这篇文章影响了我后续两年。其实说句心里话,当我第一次写这篇文章时,我心里是没底的,这个框架只是根据自己的理解做出来的一个设想,当时甚至连一行代码都没写过。我的想法是先将这个思想发表出来,让大家讨论起来,我会做一个决策,然后再亲自做具体实现,最后我会将实现过程通过博文的方式展现给大家,后续大家会对我的实现进行点评,我会基于大家的建议进行改善。整个开源过程正好与敏捷的思想是一致的,有效沟通、小步快跑、拥抱变化、不断改进。
也许就是我的技术文章吸引了很多广大读者,这里面不排除想邀请我加入的其它公司。我在 2014 年离开了 TCL 通讯,加入了易传媒。为什么我要放弃如此舒适的工作环境,去加入一家还在不断拼搏的企业呢?其实我看到的是未来互联网的发展趋势,广告程序化交易以及广告与大数据的结合,未来最值钱的一定是数据。抱着这样的信心,我加入了易传媒,担任系统架构师职位。当时易传媒正处于技术转型的初期,需要将 .Net 全部迁移到 Java,这件事情对于我而言是非常有挑战的。我的做法是:第一步定义开发规范与流程,第二步培养核心技术人员,第三步分阶段进行改造。仅半年时间,我们所有的产品成功地迁移到了 Java 平台,结果出乎大家的想象。公司市场也非常不错,产品得到了业界的认可,订单数源源不断,大家每天都很忙碌,但却很开心。而易传媒的“易家人”企业文化,让我所感动,不管是核心技术部门还是其它支持性部门,大家就像一家人一样,你的事情就是我的事情。
直到 2015 年初,阿里巴巴与易传媒建立了合作关系,两家公司进行了深度合作,易传媒公司与阿里妈妈事业部进行了整合,新阿里妈妈从此诞生了,于是我也成为了阿里巴巴的一员,目前负责阿里妈妈大数据品牌营销产品的系统架构工作。就在两家公司整合的过程中,我完成了人生中的处女作《架构探险 —— 从零开始写 Java Web 框架》这本书,目前该书正在各大网上书店售卖,我真心希望这本书能对一些想成为架构师的程序员们有所帮助,由于我个人水平有限,又是第一次写书,写得不好的地方还请大家多多包涵。
上面提到,写博客给我带来的收获颇多,那么我来分享下技术人如何写博客,又应该以怎样的态度对待。
#p#副标题#e##p#分页标题#e#
我认为技术人员写博客需要注意以下几点:
- 思路要清晰,文章要有明确的大纲与标题。
- 对于实战类型的文章,需要分步骤来描述。
- 多用短句,少用长句,能一句话说明白,就不用两句话。
- 对于不太好理解的内容,最好能打比方来说明。
- 文章末尾需要有总结,用最精辟的语言归纳出这篇文章的主要内容。
写博客首先是对自己所学知识的一个总结,此外,也为其他读者提供了很好的教程,知识得到了广播与传递。
技术一条不归路,选择了这条路从未有过放弃的想法。
做了十年的技术,我从来都没有放弃过它,相反,我非常热爱它,因为我一直以来都很喜欢学习,希望能学到更多的东西,这样遇到了具体的技术问题,可以随时从自己积累的知识库中找到最佳的解决方案。此外,目前我在公司虽然不怎么写代码了,但我还是会利用自己工作闲暇之余写一点开源项目或者代码框架等。
工作过很多大大小小的公司,那么公司最值钱的东西是什么呢?
我认为是实实在在做事情的程序员们。
他们虽然工资不高,每天坐在位置上敲着代码,在很多人眼中被称为“屌丝”或“宅男”,但我认为恰恰就是这些人,他们才是公司最有价值的人。
- 他们有自己的理想,希望能够通过自己的努力,从中得到那一点点所谓的成就感;
- 他们需要理解产品经理真正的意图,把想法变成现实,让产品真正落地;
- 他们更容易把握细节,而这些细节往往决定着产品的命运与成败;
- 他们突如其来的跳槽,对我们的项目的交付有直接的影响;
- 他们在一起工作的气氛,能体现技术公司的文化与底蕴。
由此看来,对程序员的重视是相当有必要的,我们需要关心每一位程序员的职业发展,让他们在团队里能够充分地发挥出自己的能力。
我们也需要对他们倍加关注,挖掘出有能力、肯吃苦、敢担当的人,给他们更多的机会,让他们成为技术领袖。
互联网技术公司需要大量这样的程序员:
- 他们是一群有着技术信仰的人,他们是一群热爱编程的人,他们是一群不解决问题睡不好觉的人;
- 他们不是打杂的,不是外包,更不是工具;
- 他们不喜欢被忽悠,不喜欢被冷落,更不喜欢被驱动;
- 他们需要尊重,需要培养,更需要激情!
具体说说程序员需要具备哪些素质。
我个人是这样理解真正的程序员的:
- 深爱技术,一天不写代码手就会痒,就喜欢那种成就感;
- 为了一个问题可以废寝忘食,有时会在梦中都能写代码;
- 代码洁癖症患者,喜欢优雅代码,写代码就像写诗一样;
- 善于分析问题,能快速看清问题的本质,并动手解决它;
- 喜欢研究优秀源码,学习大师的杰作,善于归纳与总结;
- 有自己的开源项目或技术博客,喜欢学习,更喜欢分享;
- 会关注技术圈子的新闻动态,时常会参加线下技术沙龙;
- 知道软件开发不是一个人在战斗,更需要的是团队协作;
- 保持良好健康的心态,用一颗积极向上的心去拥抱变化。
十年的职场之路坚持不易,分享下我的「IT 职场」经验。
时光飞逝,我事业中第一个十年已然结束了。在这十年里,让我收获了很多,跟大家分享一下我在 IT 职场方面的一些个人经验,不一定对每个人都实用,请大家仅作参考吧。
大家既然都是做技术的,那我们不妨先从技术这个话题开始说起吧。我要与大家分享的第一点经验就是:
1. 把技术当成工具
技术这东西,其实一点都不神秘,它只不过是一个工具,用这个工具可以帮助我们解决实际问题,就这么简单。
我们每天在面对技术,市面上也有很多技术,真的没有必要把这些技术都拿过来学习一遍,然后想办法找个场景去应用它。如果真的这样做了,那么只能说明技术不是工具,而是玩具,技术不是这样玩的。
我们应该从另一个角度来看待技术,不妨从自己的实际工作环境出发,现在需要什么,我们就学什么,而不要漫无目的的追求一些新技术。当然,对于新技术还是需要有所关注的,至少需要知道这个新技术是干什么用的,而且还要善于总结,将有价值的技术收集起来,以备将来使用,当需要使用的时候再来深入研究。
人的精力是有限的,人的生命也是短暂的,要善于利用自己的时间,合理地学习技术。
不要把技术看得那么重要,别把它当回事儿,把它当工具就行了,它就像我们写字的笔一样,用铅笔能写字,用钢笔一样能写字。
作为一名技术人员,除了学习与应用技术以外,还需要为自己做一个正确的职业规划,清晰认识自己究竟属于哪种技术人才,是技术专家类型的,还是技术管理类型的。路到底该怎么走?需要自己做出决定。
在我们职业路线上,最重要的人莫过于老板(我指的老板可以是公司大老板,也可以是自己的顶头上司),对待自己的老板,我也有一些经验:
2. 把老板当成情人
大家应该非常清楚,情人是需要浪漫的,浪漫是需要惊喜的。老板其实跟情人一样,也是需要惊喜的。我们做下属的,要懂得找到合适的机会给老板带来惊喜。我们跟情人谈情说爱,这是一种很好的沟通方式,可别忽略了跟老板“谈情说爱”,我们需要与老板保持良好的沟通,这种沟通并不仅仅是溜须拍马。
讲一个真实的故事吧。记得曾经我的一位同事,技术非常好,做东西非常快,质量也很高,同事们都觉得他是牛人,但他从来都不懂得在老板面前表现自己,老板也只是觉得他是可以做事的,但升职加薪的事情往往总是不会优先考虑他。
大家很定会问:怎样在老板面前表现自己呢?其实方法有很多,由于篇幅有限,我先提供三招吧:
- 第一招:在给老板做程序演示的时候,不要只是单纯的演示,不妨先用一个 PPT,简单表达一下自己的解决方案,然后再做演示,这样效果会好很多。老板会认为自己是花了心思的,是想把事情做得更好的。
- 第二招:把自己每天的工作简单记录一下,每周汇总一次,以邮件的形式发送给老板,让老板知道自己每天在做什么。每月写一篇本月工作总结与下月工作计划,同样发邮件给老板。年底可以写一个年终工作总结,打印出来,悄悄地放在老板的桌子上。
- 第三招:借汇报工作为理由,定期请老板出去吃饭,制造面对面单独沟通的机会。在谈话过程中,强调自己愿意帮助老板分担工作压力。
对待老板其实很简单,只要能帮他做事,又能让他开心,他基本上就搞定了。老板搞定了,自己的职业发展才会平步青云。但千万别忽略了还有一群人,他们或许是自己的团队战友,或许是自己的竞争对手,没错!他们就是同事。如何处理同事关系呢?以下便是我的经验:
3. 把同事当成小孩
#p#副标题#e##p#分页标题#e#
处理与同事关系,其实比处理与老板关系要稍微复杂一点,因为同事有多种身份,他们可以是队友,也可以是对手。如果大家在一起做同一个项目,那么这样的同事就是队友;如果为了竞争某个项目、岗位、资源,导致同级别的同事之间发生利益上的竞争,那么这样的同事就是对手。
对于队友而言,要学会主动给他们提供帮助,让大家能够体会到团队协作的气氛,在一起学习,在一起成长,在一起分享。可以时常跟大家一起聚餐,买点零食让大家品尝。
队友关系往往比较好处理,关键在于自己能否真正懂得去分享。很多技术人员,最不愿意的就是分享,因为担心自己花了很多精力学到的知识,分分钟就被别人学会了,自己失去了优势。这种心态最好不要在团队里产生,这样只会让自己变得越来越封闭,越来越渺小,队友们也会逐渐排挤自己。
对于对手而言,要想办法让自己成为他的兄弟,告诉他,咱们是兄弟,应该相互帮助。如果有机会,可以在老板面前,当着对手的面,夸奖自己的对手。做出这样的行为,其实并不会让老板觉得自己不如对手,而会让老板认为自己在用心去容纳对手。大家在一起工作,就是一种缘分,都是跟老板打工的,真的没有必要搞得不愉快。
其实同事就是自己的小伙伴,不妨把他们当成是单纯可爱的小孩吧,用自己的心去“收买”他们。
老板与同事,他们都是公司内部的人,不管怎么说,大家都在同一条船上,大家可以关上门吵一架,只要事情能够解决就行。但对于我们的客户而言,就需要用另外一种方法来处理好关系了。我是这样认为的:
4. 把客户当成病人
客户有需求,但没有技术,而我们有技术、有经验、有产品,正好可以帮助他们实现需求,从而提高他们的工作效率,这样客户才会心甘情愿地把钱放入我们的口袋。所以,在客户面前,我们要表现出高超的专业精神,不要被客户牵着我们的鼻子走,我们在客户面前就是技术权威,就需要这样的自信。从服装、言行、邮件、文档等各个方面,都要做到专业。
我们打算把自己的产品卖给客户的时候,千万不要一上来就对自己的产品夸夸其谈,这往往会让客户感到厌烦。我们不妨先告诉客户,他们已经“生病”了,而且病得不轻,如果不及时用药的话,后果将不堪设想。也就是说,要让客户意识到自己现在所面临的困境,让客户紧张,当他们正在思考如何应对的时候,我们再告诉他们,“药”已经准备好了,可以随时服用。
要让客户有种雪中送炭的感觉,这样就对了,他们一定会主动了解我们的产品。我们要做到这一切,必须花精力来分析行业现状,揣测客户老板们每天在想什么。如果有机会进入客户所在的公司工作一段时间,相信自己的感受会更加深入。
Java 会在很长的一段时间内是主流
为什么开发Java Web都要用框架?
我个人觉得框架有以下几点作用:
- 让开发更加高效,屏蔽底层技术细节,让开发人员关注在具体业务上。
- 框架实际上也是一种规范,可以让每位开发人员保持同样的编码风格。
- 会使用主流框架的开发人员,在人才市场上比较好获取。
现在做Java Web开发都用哪些框架呢?
常用的比如Spring MVC、Struts2 等,国内的 JFinal、Nutz 等也不错,当然Smart 也是一个很好的选择。
有一定Web前端开发经验的人,很多都会有这么个想法:那些写框架的人好厉害,什么时候我才能写一个自己的框架呢?有时候看看别人的框架代码,又觉得很复杂,对此我有一些建议以及新人学习需要什么基础?分享一些好的方法。
对于接触 Java 不太久的朋友,建议按照以下几个步骤来学习:
- 学习 Java 基础语法与核心技术,包括 Servlet、JSP、JDBC 等。
- 熟练使用流行开源框架,包括Spring、MyBatis 等。
- 研究开源框架源码,并吸取其中优秀的架构。
此外,在学习的过程当中,建议做学习笔记,最好能通过博客的方式来记录自己的收获。
使用 Python、Perl、PHP、Ruby 等脚本语言开发 Web 程序,跟使用 Java 开发 Web 程序相比有什么不同或者优劣?
前者属于动态语言,无需编译,可通过解释的方式来运行,而且 Java 需要首先通过编译,将源文件转为字节码,且载入 Java 虚拟机才能运行,相对来说,Java 对环境的要求较高,但 Java 具备更强的面向对象能力。此外,Java 还拥有较广的开源社区以及流行的开源中间件。因此,如果是做大型系统,建议使用 Java 来开发,而并非那些脚本语言。
针对 Web,Java、PHP、Python、.NET 之中未来发展前景最好的会是什么?
我认为 Java 在未来还会有一段很长的路,需要在语言本身上做到更加轻量级,用最少的代码来实现目标功能;PHP 相对来说会比较平稳,它的特点非常突出,上手快且易于开发 Web 项目;Python仍然不会有太大的用户群体;.NET 加入开源社区太晚,且较 Java 而言并没有太强的优势,可能会走下坡路。
在软件开发中有很多的设计模式,也有一些很高冷,谈谈我对软件设计的理解,以及让一些设计原则接地气。
了解设计模式的朋友们,想必都听说过“六大设计原则”吧。其实最经典的 23 种设计模式中或多或少地都在使用这些设计原则,也就是说,设计模式是站在设计原则的基础之上的。所以在学习设计模式之前,很有必要对这些设计原则先做一下了解。
GoF(四人帮),传说中的四位大神们,他们联手搞出了一套设计模式,堪称 OOD(面向对象设计)的经典之作!震惊了整个软件开发领域。但这四个老家伙非常怪异,总是喜欢显摆一些高深的理论,甚至有时候不说人话,十分让人费解。
#p#分页标题#e#
除了最经典的六大设计原则以外,还有一些其他的设计原则也非常重要。我将尽可能地解释这些晦涩的理论,希望看完之后,会让您对这些设计原则稍微加深一些理解。若有不正确的地方,恳请大家指正!
- 六大设计原则
先看一幅图吧:
这幅图清晰地表达了六大设计原则,但仅限于它们叫什么名字而已,它们具体是什么意思呢?下面我将从原文、译文、理解、应用,这四个方面分别进行阐述。
#p#副标题#e#
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)
如果重用了包中的一个类,那么也就相当于重用了包中的所有类,我们要尽可能减小包的大小。
#p#分页标题#e#
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)
不要一开始就把系统设计得非常复杂,不要陷入“过度设计”的深渊。应该让系统足够的简单,而却又不失扩展性,这是其中的难点。
一个成功的项目,离不开每个人的努力,分享下我曾经的项目管理经验。
#p#副标题#e#
给大家提出以下 10 点建议及其目标:
- Sprint 第一天,需要将目标定义清楚,并让团队所有人都知道「确保建立一致的目标并使之明确」;
- 若出现需求变更,则优先排到下次迭代,特殊情况需特殊处理「确保本次迭代可以按时完工」;
- Scrum Master 将迭代中的需求分解为任务,每个任务只能有一个任务负责人,且不超过一个人天「确保每日任务可评估」;
- 让 Product Owner 直接与相关开发人员确定需求,Scrum Master 需一同参与「确保需求与实现不会发生偏差」;
- 每日定时站会,时长不超过 15 分钟,规模不要太大「确保任务完成情况与计划保持一致」;
- 每日进行一次代码评审,由 Scrum Master 负责,并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」;
- 各个团队的 Scrum Master 保持每日沟通一次,时间不要超过 15 分钟「确保项目管理不会出现风险」;
- 每次迭代结束,让大家稍微放松一下,可提供一些团队活动,比如聚餐「确保团队能够更加凝聚」;
- Scrum Master 需要给团队一些承诺,比如项目奖金或特殊福利等「确保团队更加有激情」;
- 对于情绪异常的员工,Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」;
此外,作为项目管理者,需要不断在团队中加强以下 5 点文化:
- 方向一致
- 当面沟通
- 全情投入
- 充分信任
- 说到做到
真正的开源并非只是代码的开源,而是思想的开源
谈谈我对「开源」的看法,国内的开源的现在如何,对比国外呢?
我个人认为,真正的开源并非只是代码的开源,而是思想的开源。在做开源项目之前,建议能将自己的想法共享出来,而不是 埋头闭门造车。我不反对“重造轮子”,因为我们需要更好的轮子,轮子好了车子才能跑得快。凡是有利也有弊,我们也不能盲目地选择开源技术,因为并不是适合 别人的技术就适合自己,而是需要根据自身的需求,选择最适合的开源技术,搭建恰如其分的架构。
有大量的新技术,我首先会去关注它,了解它是做什么的,可以解决什么问题,但我一开始绝不会去深入研究它,更不会去看它的源码,因为一旦遇到这方面的需求场景,我就会从这个“知识库”中去寻找最好的解决方案,如果仍然寻找不到最合适的开源技术,我才会尝试自己去实现。
技术人的归途
走技术这条路,归途是什么?是否转型又该如何抉择呢?
至少有好几条路线是可以走的,比如:深入技术、转型做产品、转型做管理等,需要根据自己的特长和性格来选择,做自己喜欢的事情。
从技术转管理,对自身的要求比较高,说具体点,需要看自己的情商,为人处世的经验,与人沟通的技巧,自己也需要有足够的胸怀,去包容一些事情,还需要自己有足够的人格魅力去吸引别人,让别人愿意跟着你一起做事。管理有些东西是很难从书本上学到的,但一些经典的管理理论是必须要去学的。
相比较而言,继续深入技术或者从技术转产品会容易一些了,因为很多时候都不太需要与人打交道。