BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

微博热报2012.05.14——写程序的重要性、架构师职位

| 作者 侯伯薇 关注 0 他的粉丝 发布于 2012年5月15日. 估计阅读时间: 12 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

近日,@左耳朵耗子 发布了两条微博,一条提出,IT领域的各种角色,像软件开发咨询、SQA、流程设计、软件项目管理等等,都需要会写程序的人来担当;另一条认为架构师是个应该被废弃的职称,在某些情况下其中的技术含量并不是太高。两条微博都引发了大家的广泛讨论。

前天,@左耳朵耗子 发表了这样一条微博:下午和团队谈到自己以前公司经历中程序员被咨询师,SQA,流程人员,项目经理搞得巨苦逼的各种案例。大家一致觉得,不会写程序的人来搞什么软件开发咨询,SQA,流程设计,软件项目管理,全是扯蛋。所以,程序员应该要像Linus一样自信的对这些人说:“Talk is cheap, show me the code.”

大家也都谈了自己对写程序重要性的感受:

七棵大树:是的,尤其烦一点都不懂,就一根筋的问行不行,多久能行?一周行不行?没见到生产环境,没测试过,怎么就知道行不行。产品经理一定要写过大量代码,经验丰富才行。

简生-_-:回复@Hegel2011:如果单纯就论观点而言,这的确是过了。如果借此来吐槽当前国内IT行业的情况,我是十分认同的。

yanghaocsg:“身着绮罗者,不是养蚕人”。呵呵,单位不写代码或者不屑于写代码的好像更容易成老大,而学校里的则更容易成计算机的教授副教授~

左耳朵耗子:对于那些张嘴闭嘴让你搞UT自动化,搞TDD,搞持续集成,持续部署,搞迭代,搞各种所谓软件工艺的不写程序的人来说,我们应该谦虚一点,应该向他们不耻下问——“能不能把你以前代码给我看看?”,或 “你能不能帮我们写写自动化UT的case?帮我们开发个持续部署的工具?”。

安德猫:靠这个吃饭并不可耻,可耻的是某些搞流程的人根本不懂软件开发,生搬硬套,只有写过程序,遇到过困难,找到过解决方法的人提出来的方法才是可信和有价值的。记得某段时间高价请了一个人来讲agile,问,长生命周期的电信产品agile后如何解决构架问题?支支吾吾了半个月,糊弄过去完事。

皮皮彭:这个还是要具体问题具体分析,比如项目管理的技能和写程序的技能完全是两码事,一股脑儿把非程序员打死也是很无知的做法。

云空乱:当年在果壳面试,本来是CTO CEO都面过了,还愉快的吃了顿饭。后来产品总监来直接一堆超级扯淡的瀑布测试、交叉测试的问题问吐了。我code5年从没用过这玩意,更没从身边的架构师里听到过。说真的,最怕外行用他那严谨但丝毫不相关的理论把你拉倒他的水平。

刘宇01685:昨天同事讲相声记得听了“自大一点他念臭”,正好可以用上。:)不过测试真不是让你容易坚持做10几年的工作,太多的郁闷了。 写个代码没什么了不去的,这确实是基层的工作,做任何领域往上称大家不容易,但自大点就真的很臭。

崔启亮-北京ISTQB:陈浩同学的观点很犀利,很吸引眼球,但是局限性太大。会写代码只能是很基础的一门技能,把技能形成产品,需要技术之外的技能,例如,发现市场需求,塑造企业品牌。具备这些技能的人,往往身居公司高层,他们很多人都不会编代码,也不会关注这些执行层面的问题。这些人是C-level,CXO人物。

杭州李云:这也是我为什么在《软件开发工程师技术能力层次模型》(http://t.cn/SawkWM)中将流程和质量保证方法论纳入工程师能力范围的缘故。流程不是别人给的(或许一开始的框架是),最终应是工程师自己制定和选择的。所有的方法论都应以工程师对其的接受度为本!忽视这一点,必无果!

Robin圈:为什么我觉得不懂技术而转管理很奇怪呢?答案与公司气度有关,如果公司把流程与制度,当成核心竞争力,管理者可以不懂技术,因为制度是比较容易执行的。而以人作为核心竞争力者,必须得懂,深刻理解团队的苦与乐,而不要以流程为由,做出2b的决定。不否认强制制度可以达成目标,但它是会牺牲团队快乐的。

张克强-敏捷307:回复@RayChase: SQA对于编码的检查不能称为“指导”,而是提醒编码高手容易忘记的一些事情,比如及时check in,修复前天自动代码静态检查出来的2级缺陷,跟踪关闭一周前的测试缺陷,提醒代码注释率低于组织要求,提醒跟踪代码对应的需求用例或用户故事,提醒测试覆盖率低于组织要求... 回复@RayChase: 过程方面的SQA就是这样苦B,吃力不讨好,出错还要负责。换位思考下,理解万岁。当然过程方面的SQA不是必需的岗位,但是一旦设立了,其天然的站在管理者的视角,需要协调与程序员的关系。

黄邦伟的微博:Code is not everything, but code is SOMETHING!!! 当然,软件开发不仅仅是代码,但代码是一个非常重要的一部份。还有,能写好代码的人,往往抽象能力强,思想清晰,也意味这他对软件开发的能力和潜能。写代码至少象站马步一样。会站马步,不表示能够打拳,但如果连马步都站不稳,还打啥拳?谈啥拳?教啥拳?

皮皮的一天:Coding很重要,但光Coding是不行的,最好的程序员在一起也不一定能做出做好的产品。这是一个需要各个角色协同配合的工作。记得有人说如果一个产品经理是程序员出生,那这个产品经理一定做不好,除非他不是优秀的程序员。So, 皓哥,@左耳朵耗子Coding is not everything.

今天,@左耳朵耗子 又对架构师的职位发表了自己的看法:对我来说,架构师是个应该被废弃的职称,这本质上是瀑布模型软件开发中出来的角色。我并不觉得今天国人所追逐的架构师有多牛,这是光环效应。一些网站前端工程师,做某些应用或工具软件(如:图型图像处理/P2P/智能算法/开发框架/浏览器/监控软件……)的工程师要比国内所谓的架构师技术含量高多得多。

大家对此也众说纷纭:

UMLChina潘加宇:计算机科学不是软件工程。软件是为人开发的,所以我们要做需求;软件是由人开发的,所以我们要做设计。软件工程更接近于经济学,而非计算机科学。“程序员”这个职业,软件工程的成分要比计算机科学的成分大。现在的大学计算机教育,基本还是以教授计算机科学为主,所教的软件工程仅是聊胜于无。这本来也没什么问题,毕竟象牙塔里的教授要教出好的软件工程也不容易,开发人员还是要在业界历练学习。不过,因为软件工程看起来没有计算机科学那么“深奥”,开发人员常会误认为某人只要对计算机科学的某个领域有一定研究,他对软件工程所发表的见解也一定是有道理的!这时问题就大了。事实上,以我所见所闻,即使是名校拿到了计算机专业的硕士博士,又在著名IT公司的研究院做研究多年,一张口仍然是“软件工程盲”的人士,并不鲜见。

agile123:回复@左耳朵耗子:呵呵,这个因果逻辑好像并不成立,类似的说法是:前锋/后卫/队长这个职位(角色)应该取消,因为这只不过是踢足球的运动员中的一项工作罢了。哪天曼联这么做了,建议国内也照做 //我的逻辑是,架构师这个职称应该被取消,因为这只不过是写软件的程序员中的一项工作罢了。

agile123:举个简单例子,Linus是Linux系统的架构师,他不会图像处理、P2P,难道要把他开了?其实“架构师”只是一个称谓,叫不叫、叫什么都无所谓,比如可以改成Technical Leader。国内架构师水平低,应该继续努力,但并不意味着最好把这个角色取消,每个企业每个项目里这些该做的(架构设计的)事还得有人去做。

agile123:不太同意,#软件架构师#与瀑布模型没必然联系,不应废弃。每个软件公司都能找出几个技术最牛的人,这些人就是架构师,是企业技术骨干。多数项目团队都应设置架构师职位,负责系统整体全局设计、关键细节设计和编程,所谓集体负责架构往往是句空话。架构师角色有无价值,与国内架构师的水平这是两个问题。

得意的那些事儿:如果人人都抱有架构思想的团队,会不会出现架构混乱?谁来协调?架构师!但架构师的作用不是做技术领袖,而更多的是技术评估,并最终交由团队来投票决定。所以架构师的设置,核心是技术要有把控,而不是技术独裁。也许牛B的公司有很多技术牛人,但是能领导这些人的一定是架构师。不然等着遭殃。

EdisonTsai:架构师不仅仅是一个title,更多的是其能统筹全局的表现,如果能做到每个人都有架构意识的话,按理分析是可以去掉架构师的职位,不过这是不可能的客观事实,就犹如每个人都可自觉工作不需要管理者一样,有这个可能吗?

大家叫我导演:架构师不只是一个title。架构师是通过开发,系分成长的;架构师是要写代码的。架构师不是空想的,不是只写ppt的;空降架构师要依托当前业务落地。架构师是按成功完成的产品说话而不是blog编写理论。

lazycai:事实上任何规模的系统、项目都有架构设计的成分在内,所以设计架构属于软件开发的基本技能。只不过,大规模系统架构设计、算法、语言这几个方面,菜鸟做不了,牛人比较多;而前端、工具开发领域则是菜鸟多牛人少,所以光环效应的产生很正常⋯⋯

TimYang:赞成架构师不应当是某个特定的角色,但是每个优秀的工程师需要具备架构意识,比如方案能力、全局观、历史兼容、投入产出比、方案与代码的简洁性、可扩展能力、可维护性……这些都是架构的体现。现实问题是不少工程师不愿意从架构层面思考小特性的改进,而是总期望做"大活"来提升架构。

于是我闻:架构师在IBM主要是做开发以前的需求分析工作,主要是指——数据建模。也未必是瀑布模型里面的角色,RUP里面也有。数据建模建立领域模型,这是一般程序员做不了的。有可能是能力不够,更大的可能是没有那个资历和权限去做。

tiger_tai:合格的架构师还是重要得多,项目越复杂,越需要一个好的结构,这个是架构师要思考的。把项目的整体结构、各个模块之间的关系接口处理好,这个比前端做出某个效果要重要的多。算法上来看可能不那么难,但很需要经验。

技术宅的每日三省:不太赞同。工程师的知识特点是专业、深入,架构师的知识相对较广,但不够深入。另外,架构师很多时候兼做项目经理,程序员,导师等多种角色。

关于写程序对于各种角色的重要性,以及架构师这个职位,你的观点如何,欢迎加入讨论。


欢迎读者关注@InfoQ官方微博,推荐热门话题,可私信@InfoQ,同时请您说明推荐理由。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

关于架构师,应该存在 by 葛 益宁

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT