对技术的态度

最近人品爆发,图灵社区,InfoQ,51CTO相继对我做了采访,前两天我把InfoQ对我的采访张贴了出来,今天,图灵社区和51CTO对我的采访发布了(图灵的访谈 ,51CTO的访谈),我是一个有技术焦虑症的人,我的经历比较特殊,对大家来说可能也没有什么意思,这两个采都有一些重叠的部分,不过有些观点我想再加强一些,并放在这里和大家一起分享一下。

对于日新月异的新技术,你是什么态度?

遇到新技术我会去了解,但不会把很大的精力放在这些技术(如:NoSQL,Node.js,等)。这些技术尚不成熟,只需要跟得住就可以了。技术十年以上可能是一个门槛。有人说技术更新换代很快,我一点儿都不觉得是这样想。虽然有不成熟的技术不断地涌出,但是成熟的技术,比如Unix,40多年,C,40多年,C++,30多年,TCP/IP,20多年,Java也有将近20年了……,所以,如果你着眼成熟的技术,其实并不多。
我的观点是——要了解技术就一定需要了解整个计算机的技术历史发展和进化路线。(这个观点,我在《程序员练级攻略》和《C++的坑多吗?》中提到过多次了。)因为,你要朝着球运动的轨迹去,而不是朝着球的位置去,要知道球的运动轨迹,你就需要知道它历史上是怎么跑的
如果要捋一个技术的脉络,70年代Unix的出现,是软件发展方面的一个里程碑,那个时期的C语言,也是语言方面的里程碑。(当时)所有的项目都在Unix/C上,全世界人都在用这两样东西写软件。Linux跟随的是Unix, Windows下的开发也是 C/C++。这时候出现的C++很自然就被大家接受了,企业级的系统很自然就会迁移到这上面,C++虽然接过了C的接力棒,但是它的问题是它没有一个企业方面的架构,而且太随意了,否则也不会有今天的Java。C++和C非常接近,它只不过是C的一个扩展,长年没有一个企业架构的框架。而Java在被发明后,被IBM把企业架构这部分的需求接了过来,J2EE的出现让C/C++捉襟见肘了,在语言进化上,还有Python/Ruby,后面还有了.NET,但可惜的是这只局限在Windows平台上。这些就是企业级软件方面语言层面就是C -> C++ -> Java这条主干,操作系统是Unix -> Linux/Windows这条主干,软件开发中需要了解的网络知识就是Ethernet -> IP -> TCP/UDP 这条主干。另外一条脉络就是互联网方面的(HTML/CSS/JS/LAMP…)。我是一个有技术忧虑症的人,这几条软件开发的主线一定不能放弃。
另外,从架构上来说,我们可以看到,

  • 从单机的年代,到C/S架构(界面,业务逻辑,数据SQL都在Client上,只有数据库服库在S上)
  • 再到B/S结构(用浏览器来充当Client,但是传统的ASP/PHP/JSP/Perl/CGI这样的编程也都把界面,业务逻辑,和SQL都放在一起),但是B/S已经把这些东西放到了Web Server上,
  • 再到后来的中间件,把业务逻辑再抽出一层,放到一个叫App Server上,经典的三层结构。
  • 然后再到分布式结构,业务层分布式,数据层分布式。
  • 再到今天的云架构——全部移到服务器。
我们可以看到技术的变迁都一直再把东西往后端移,前端只剩一个浏览器或是一个手机。通过这个你可以看到整个技术发展的趋势。所以,如果你了解了这些变迁,了解了这些变迁过程“不断填坑”的过程,你将会对技术有很强的把握。

另外,我听到有很多人说,一些技术不适用,一些技术太学院派,但对我来说,无论是应用还是学术,我都会看,知识不愁多。何必搞应用的和搞学术的分开阵营,都是知识,学就好了。
技术的发展要根植于历史,而不是未来。不要和我描述这个技术的未来会多么美好(InfoQ 的 ArchSummit大会上有一个微软来的人把Node.js说得跟仙女一样,然后给了一个Hello World),我承认你用一些新的技术可以实现很多花哨的东西。但是,我认为技术都是承前的,只有承前的才会常青。所以说“某某(技术)要火”这样的话是没有意义的,等它火了、应用多了,规模大了,再说。有些人说:“不学C/C++也是没有问题的”,我对此的回应是:如果连技术主干都可以不学的话,还有什么其他的好学呢?这些是计算机发展的根、脉络、祖师爷,这样的东西怎么可以不学呢?
另外,我们要去了解整个计算机文化,我觉得计算机文化源起于Unix/C这条线上(注意,我说的是文化不是技术)。我也写过很多与Unix文化相关的文章,大家可以看看我写的“Unix传奇尤其是下篇)”。

可是在应用环境中,对新技术的需求是很高的,你觉得在教育领域计算机科学的侧重应该是什么样的?

学校教的大部分都是知识密集型的技术,但是社会上的企业大部分都是劳动密集型的。什么是劳动密集型的企业呢?麦当劳炸薯条就是劳动密集型的工作,用不到学校教授的那些知识。如果有一天你不炸薯条了,而要去做更大更专业的东西,学校里的知识就会派上用场。有人说一个语言、一个技术,能解决问题能用就行了,我不这样认为。我觉得你应该至少要知道这些演变和进化的过程。而如果你要解决一些业务和技术难题,就需要抓住某种技术很深入地学习,当成艺术一样来学习。
我在“软件开发‘三重门’”里说过,第一重门是业务功能,在这重门里,的确是会编程就可以了;第二重门是业务性能,在这一重门里,技术的基础就很管用了,比如:操作系统的文件管理,进程调度,内存管理,网络的七层模型,TCP/UCPUDP的协议,语言用法、编译和类库的实现,数据结构,算法等等就非常关键了;第三重门是业务智能,在这一重门里,你会发现很多东西都很学院派了,比如,搜索算法,推荐算法,预测,统计,机器学习,图像识别,分布式架构和算法,等等,你需要读很多计算机学院派的论文。
总之,这主要看你职业生涯的背景了,如果你整天被当作劳动力来使用,你用到的技术就比较浅,比较实用,但是如果你做一些知识密集型的工作,你就需要用心来搞搞研究,就会发现你需要理论上的知识。比如说,我之前做过的跨国库存调配,需要知道最短路径的算法,而我现在在亚马逊做的库存预测系统,数据挖掘的那些东西都需要很强的数学建模、算法、数据挖掘的功底。
我觉得真正的高手都来自知识密集型的学院派。他们更强的是,可以把那些理论的基础知识应用到现在的业务上来。但很可惜,我们国内今天的教育并没有很好地把那些学院派的理论知识和现实的业务问题很好地接合起来。比如说一些哈希表或二叉树的数据结构,如果我们的学校在讲述这些知识的时候能够接合实际的业务问题,效果会非常不错,如:设计一个IP地址和地理位置的查询系统,设计一个分布式的NoSQL的数据库,或是设计一个地理位置的检索应用等等。在学习操作系统的时候,如果老师可以带学生做一个手机或嵌入式操作系统,或是研究一下Unix System V或是Linux的源码的话,会更有意思。在学习网络知识的时候,能带学生重点学一下以太网和TCP/IP的特性,并调优,如果能做一个网络上的pub/sub的消息系统或是做一个像Nginx一样的web server,那会更好。如果在学图形学的过程中能带领学生实践一个作图工具或是一个游戏引擎,那会更有意思。
总之,我们的教育和现实脱节太严重了,教的东西无论是在技术还是在实践上都严重落后和脱节,没有通过实际的业务或技术问题来教学生那些理论知识,这是一个失败。

那么,现在做一个软件开发者是否更加困难了?

我觉得倒不是。做一个软件开发者更简单了。因为现在互联网很发达,你可以找到很多共享的知识——相对于我那个时候。第一,知识你容易查到,然后社区很多,文章、分享的人也越来越多。我们那个时候没有的。上网一查,什么都没有。都得去自己琢磨,自己去调查。所以我觉得相比我们那个时候更容易了。第二,工具变多了。现在的工具比那个时候好用多了。我们那个时候就是一天到晚在vi里面,连个自动提示都没有,连个版本库管理都没有。不光工具变多,框架也多了,各种各样的编程框架。我们那时候都是生写。写JavaScript,生写,连个jQuery都没有。没有这些辅助性的、让你提高生产力的东西。J2EE那时候也没有。而且整个(开发环境)都很不成熟。一个服务器的最高配置就1GB的情况下,一个WebSphere起来就占了900多MB——这还能跑什么应用?所以只能去用最基础的系统。所以我觉得现在,无论是环境,还是开发的过程,都更规范了。以前我做开发的时候就是,什么都不懂就上了,瞎搞,没有什么开发规范,没有人理你,反正你搞得好就搞好,搞不好就搞不好了,全靠自己,包括做测试维护等等。我觉得现在的软件开发就很好,你一上去,就有好的工具,有好的知识库,有好的社区,有好的开发框架,还有好的流程,方法,甚至还有人帮你做测试,还有人告诉你应该怎么做。幸福得很。现在好多人还说这个不好那个不好,开发难什么的。其实容易多了。
但是,有个东西我觉得是现在的软件开发者比我们那时候变得更难的。就是,你享福了以后,人就变懒,变娇气了。对很多东西的抱怨就开始多了。我们那个时候哪有什么好抱怨的?没啥好抱怨的,有活就干,有东西学就赶快学。现在呢,学个什么东西还挑挑拣拣的,抱怨这个语言太扯,那个IDE不好,这个框架太差,版本管理工具太扯,等等。这就好像以前我没东西吃,只有个糠吃,要是有面包有馒头,我就觉得非常非常好了。现在是,好吃的东西多了我们还学会挑食了,这也不好用,那也不好用
根本就不是技术变难了,环境变差了,是程序员变娇气了。所以软件开发变难,归根结底还是程序员们自己变娇气了。

你如何在进度压力下,享受技术带来的快乐?

中国人中庸的思想,入世和出世,每天的工作就是入世。举个例子,我十年前在上海的时候,给交通银行做项目的时候,每周休息一天,早九点到晚十点,每天工作12个小时,这样的工作持续了一整年,没有节假日,项目上的技术也没什么意思。当时我晚上十点回到住处,还想学一些C++/Java和Unix/Windows的技术,于是就看书到晚上11:30,每天如此,一年下来学到很多东西,时间没有荒废,心里就很开心。我觉得当时是快乐的,因为有成长的感觉是快乐的。
现在的我,工作、写博客、养孩子,事情其实更多。我早上7:30起床,会浏览一下国外的新闻,hacker news, tech church, reddit, highavailability之类的站点,9点上班。晚上6、7点钟下班,开始带孩子。十点钟孩子睡了觉,我会开始重新细读一下这一天都发生了些什么事情。这个时间也有可能会用来看书。学习的过程(我)是不喜欢被打断的,所以从十点到十二点,家人都睡了,这正是我连续学习的好时间。可能从晚上11:30开始,我会做点笔记或者写博客。我现在对酷壳文章的质量要求比较高一些,所以大概积累一个星期的时间才可以生成一篇文章。每天我大概都在一两点钟才会睡觉。没办法,我有技术焦虑症。但是觉得这样的生活很充实,也很踏实。
另外,任何一门技术玩深了,都是很有意思的。有些人形成了一个价值取向,“我只做什么,绝不做什么”。前段时间有一个刚来亚马逊的工程师,他原来做的是数据挖掘推荐系统,原来的公司重组要让他做前端,他不肯就离职了,他说他不想做前端。我觉得,前端后端都是编程,Javascript是编程,C++也是编程。编程不在于你用什么语言去coding,而是你组织程序、设计软件的能力,只要你上升到脑力劳动上来,用什么都一样,技术无贵贱。你可以不喜欢那个技术,但是还是要了解了解,也没有必要完全不用,完全抛弃。Javascript啊——只要能被Javascript实现的,未来总有一天会被Javascript所取代。
回到问题,怎么才能享受到快乐呢?

  • 第一,入世和出世要分开,不要让世俗的东西打扰到你的内心世界,你的情绪不应该为别人所控,也不应该被世俗所污染,活得真实,活得真实你才会快乐。
  • 第二,就是要有热情,有了热情,你的心情就会很好,加班都可以是快乐的,想一想我们整个通宵用来打游戏的时光,虽然很累,但是你也很开心,这都是因为有了热情的缘故。

总之一句话——如果你没有兴趣,什么都是借口,如果你有兴趣了,什么都是好玩的
转载本站文章请注明作者和出处 酷壳 – CoolShell.cn  http://coolshell.cn/articles/8088.html

敏捷团队的角色定义

敏捷团队的角色定义作用:描述敏捷团队Team中涉及的各类角色,每个角色的工作内容。Team中的全体成员遇到问题之后可以找对应角色的人员来协助解决障碍。
PO
1、产品负责人,负责产品整体规划,设定阶段目标,明确产品演进思路和版本发布规划,对外的统一负责人
2、负责明确产品需求、编写故事和设置优先级,输出Product Backlog 。
3、规划工作至少提前研发团队一个月;需求细化至少提前一个Sprint。
4、负责组织需求评审
5、负责解答Team中所有人员关于需求的疑问
6、负责验收研发团队交付的系统,对系统出厂的质量负责
项目负责人
1、跟进项目进度,并对外汇报项目进展
2、依据敏捷Team的各类输出,翻译成周报的格式提交给管理层
3、协调资源
Agile Coach
敏捷教练,协助SM进行敏捷实践和过程改进,推动Team完成持续改进
SM
1、Scrum Master,负责指导Team成员开展工作,确保各项工作的高效开展
2、优化工作流程和机制,确保各个角色之间顺畅、高效的协同工作
3、解决团队开发中遇到的障碍
4、作为研发团队与外部的接口,为团队排除障碍,屏蔽外界干扰
5、保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings
需求分析师
1、在PO输出的Product Backlog基础上,与PO沟通,将对应的故事细化成软件需求
2、解答研发团队开发过程中的需求疑问
技术负责人
负责整个系统的架构设计工作,对系统的技术架构和技术选型负责
子系统负责人
1、作为子系统的整体负责人
2、基于运营中心整体架构的基础上,完成子系统的架构设计和关键技术选型工作,对子系统的技术架构和技术选型负责
3、为子系统研发团队排除技术障碍,解决技术难点
4、指导子系统研发团队的开发工作
过程改进
1、协助SM开展过程改进工作,具体如下:
《1》关注研发过程中涉及的各类环境,确保各类环境正常稳定运行
《2》协助大家完成TDD的工作
《3》关注CI运行情况,提醒团队解决CI中的问题
《4》优化CI的执行过程
《5》定期Review大家的工作,如:Wiki、代码
2、发现团队中大家技能的短板,与SM一起提升大家的技能水平
开发工程师
1、依据Sprint Backlog,选取对应的任务,完成详细设计、代码编写(含测试代码)、修复BUG
2、承担项目中部分技术难点的攻关
WEB前端工程师
1、依据UI的设计方案,实现方案中的交互效果
2、将静态页面转换成动态页面,并完成与后端逻辑代码的集成
3、在技术负责人或者子系统负责人的指导下,完成WEB前端技术难点的攻关和结构的优化
UI
与PO沟通,基于需求完成线框制作、人机交互设计、效果图设计
UE
1、依据UI的设计方案,完成静态页面的实现
2、负责静态页面的浏览器兼容性测试
3、协助WEB前端工程师完成交互效果的实现
测试工程师
1、Review需求分析师输出的需求,从测试的角度判断是否具备可测试性
2、编写测试用例
3、负责运营中心各子系统的测试工作(功能、性能、稳定等),对系统出厂的质量负责
4、跟进BUG的修复进展
5、定期分析BUG,输出测试报告,作为团队改进的数据输入
版本管理
1、负责SVN的管理,如:账号、权限、branche和tag的创建
2、明确版本号及输出版本的发布说明