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

近日，@左耳朵耗子 发布了两条微博，一条提出，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 ，同时请您说明推荐理由。