590
社区成员
发帖
与我相关
我的任务
分享[转] 高来高去的扯淡--所谓的《软件工程师与程序员的差别》
from: http://blog.csdn.net/Raptor/archive/2005/04/01/334855.aspx
刚看了一篇疆的《软件工程师与程序员的差别》，明显是中了某些所谓“大师”的毒太深的。
从前我们搞语言祟拜，后来又有了模式祟拜和软件工程祟拜，现在则流行UML祟拜和架构祟拜。《国际歌》说得好：从来就没有什么救世主。F.Brooks在二十多年前说过：没有银弹！--实践是检验真理的唯一标准，这二十多年来的实践已经证明，Brooks的论断是正确的。
第一，在编码之前，不能有效地理解软件的设计思路与内容，具体表现为不能充分理解规范的UML模型；
如果Coder不能有效理解，仅仅是Coder的问题吗？Architect有没有把他的设计思路说明清楚？而且UML也不是设计的唯一表达手段，还有就是Architect自己是否对需求作了正确的理解，也许他的设计本来就是错的。再说了，如果Coder的水平高到可以很容易地看明白设计思路，甚至纠正其中的错误，那还要Architect干什么？
第二，在编码之后，不能向集成测试或系统测试人员提供高质量的代码，具体表现为不能自觉地进行单元测试；
不能自觉地进行单元测试固然主要是Coder的责任，但是按TDD的精神来说，测试（名词）是需求的表现，它应该是“先行”，而不是在编码完成后。这里同样存在一个问题：Architect在编码开始之前能否做到将需求细化到可以测试的程度？
第三，在编码过程中，不能有效地与其他开发人员进行协作，具体表现为缺乏基本的软件配置和变更管理概念与实践基础。
协作不良的问题存在着中国传统文化的基础，但还有一个很关键的原因是：公司自身的团队建设工作做不到位，也就是说那些Manager们有很重要的责任。至于软件配置和变更管理的使用完全没有技术含量，只要作一个简短的培训就行了，关键在于长效管理机制，比如制度化的DailyBuilding等。这些跟Coder也没有什么关系。
作为一名Coder，最重要的是把Coding工作做好。
地球人都知道，一个软件的成功或失败，并不完全是Code的原因。如549在ari的《漸近, 悟道!》的回复中所说：事实上,现在大部分人连做coder都不合格。这是一个很重要的事实。在这种情况下鼓吹Coder需要具备那些本该是Architect和Manager的素质是一种很阴险的论调。如果Coder们都有这样的能力的话，还要你们这些Architect和Manager干什么？
同样是在ari的《漸近, 悟道!》中，小错回复说：
不同层次的人对自己职业人生的规划和认识都不一样，就像你几年前醉心于技术细节研究，感觉做一个coder很爽，过两年coder不能带给你快感，你渐渐从喜欢研究架构，团队....于是你觉得PM才是你的追求，再过两年，你觉得PM的成功还不够，于是你就开始搞些资本运作，大谈管理理念。再过两年你已经是个国际人士了，开始和陈天桥平起平坐啦，有过两年你开始热心于写写自传，到企业传道授业其实关键是不要停止思考不要满足现状就行，至于此刻悟道的，过两年回头看看觉得很可笑，因为你又在另一个层次了。
这揭示出了其中的根本原因：那就是做Coder没有提升的通道。
每个人都有自己的特长与适应的范围，并不是所有人都适合于做Architect或Manager，更不用说什么资本运作之类的。按《彼德原理》的说法，当一个人被升到一个不能胜任的位置的时候，就会开始有这样的表现：故意表现出一种高深莫测的感觉。
或者如本文的题目所说：高来高去的扯淡。
我不敢说国内所有的Architect或(Project) Manager都是如此，但至少是大部分。最简单的判断这种人的方法就是：他们是不是在项目进展出现问题时，把责任一味地推给Coder。
其实本文的题目源于前几天与令狐在MSN上的闲聊。令狐说：
其实现在感觉那些关于Architect的所谓技术都是扯淡，这种高来高去的东东还不是说什么就是什么。国内谈这些东西的目的很简单，就像我在群里说的“资本运作”一样，弄点新概念出来吹吹，一是可以显示自己“了不起，这么新的东东我都理解了”；二是吹这个没风险，又不需要实际系统也不需要具体案例。
我补充道：还可以骗钱。中国的软件业没希望了，没人想踏踏实实地做事。
令狐：现在整个环境就是如此，大家都很浮躁，公司首先浮躁，客户也浮躁。因为现在很多项目是官方的，他们不怕花钱，所以工程商也无所谓，我只要我想要的效果，钱无所谓。就是这样。如果真的要花自己的钱，恐怕很多人就会认真的想想这个功能是不是自己真的需要的了。
其实ari在《漸近, 悟道!》中说出了软件的本质：真正的用戶(或者說成熟的用戶),永遠不會在乎你技術細節的選擇他只關心他的需求得不得到滿足!
我在《效颦篇：编程本质论》也曾经表达过类似的观点：软件开发就两个重点，一个是需求，一个是对需求的实现。其它的手段都是为这两个重点服务，否则就是本末倒置。
那些高来高去扯淡还是少一点，多干点实事吧。
=================================================
背景文章: 软件工程师与程序员的差别
from: http://borland.mblogger.cn/wujiang/posts/17773.aspx
程序员所具备的技能通常以深入理解一或多种语言及相应软件集成开发环境为主体。然而，众多软件开发机构往往感到程序员的技能单薄，具有明显的局限性，主要暴露在三个典型的方面：
第一，在编码之前，不能有效地理解软件的设计思路与内容，具体表现为不能充分理解规范的UML模型；
第二，在编码之后，不能向集成测试或系统测试人员提供高质量的代码，具体表现为不能自觉地进行单元测试；
第三，在编码过程中，不能有效地与其他开发人员进行协作，具体表现为缺乏基本的软件配置和变更管理概念与实践基础。
这三种典型的局限性是程序员与软件工程师之间的关键差异，也是软件企业决定录用开发人员的重要考量依据。
2005年3月31日 20:00
刚看了一篇疆的《软件工程师与程序员的差别》，明显是中了某些所谓“大师”的毒太深的。
从前我们搞语言祟拜，后来又有了模式祟拜和软件工程祟拜，现在则流行UML祟拜和架构祟拜。《国际歌》说得好：从来就没有什么救世主。F.Brooks在二十多年前说过：没有银弹！--实践是检验真理的唯一标准，这二十多年来的实践已经证明，Brooks的论断是正确的。
第一，在编码之前，不能有效地理解软件的设计思路与内容，具体表现为不能充分理解规范的UML模型；
如果Coder不能有效理解，仅仅是Coder的问题吗？Architect有没有把他的设计思路说明清楚？而且UML也不是设计的唯一表达手段，还有就是Architect自己是否对需求作了正确的理解，也许他的设计本来就是错的。再说了，如果Coder的水平高到可以很容易地看明白设计思路，甚至纠正其中的错误，那还要Architect干什么？
第二，在编码之后，不能向集成测试或系统测试人员提供高质量的代码，具体表现为不能自觉地进行单元测试；
不能自觉地进行单元测试固然主要是Coder的责任，但是按TDD的精神来说，测试（名词）是需求的表现，它应该是“先行”，而不是在编码完成后。这里同样存在一个问题：Architect在编码开始之前能否做到将需求细化到可以测试的程度？
第三，在编码过程中，不能有效地与其他开发人员进行协作，具体表现为缺乏基本的软件配置和变更管理概念与实践基础。
协作不良的问题存在着中国传统文化的基础，但还有一个很关键的原因是：公司自身的团队建设工作做不到位，也就是说那些Manager们有很重要的责任。至于软件配置和变更管理的使用完全没有技术含量，只要作一个简短的培训就行了，关键在于长效管理机制，比如制度化的DailyBuilding等。这些跟Coder也没有什么关系。
作为一名Coder，最重要的是把Coding工作做好。
地球人都知道，一个软件的成功或失败，并不完全是Code的原因。如549在ari的《漸近, 悟道!》的回复中所说：事实上,现在大部分人连做coder都不合格。这是一个很重要的事实。在这种情况下鼓吹Coder需要具备那些本该是Architect和Manager的素质是一种很阴险的论调。如果Coder们都有这样的能力的话，还要你们这些Architect和Manager干什么？
同样是在ari的《漸近, 悟道!》中，小错回复说：
不同层次的人对自己职业人生的规划和认识都不一样，就像你几年前醉心于技术细节研究，感觉做一个coder很爽，过两年coder不能带给你快感，你渐渐从喜欢研究架构，团队....于是你觉得PM才是你的追求，再过两年，你觉得PM的成功还不够，于是你就开始搞些资本运作，大谈管理理念。再过两年你已经是个国际人士了，开始和陈天桥平起平坐啦，有过两年你开始热心于写写自传，到企业传道授业其实关键是不要停止思考不要满足现状就行，至于此刻悟道的，过两年回头看看觉得很可笑，因为你又在另一个层次了。
这揭示出了其中的根本原因：那就是做Coder没有提升的通道。
每个人都有自己的特长与适应的范围，并不是所有人都适合于做Architect或Manager，更不用说什么资本运作之类的。按《彼德原理》的说法，当一个人被升到一个不能胜任的位置的时候，就会开始有这样的表现：故意表现出一种高深莫测的感觉。
或者如本文的题目所说：高来高去的扯淡。
我不敢说国内所有的Architect或(Project) Manager都是如此，但至少是大部分。最简单的判断这种人的方法就是：他们是不是在项目进展出现问题时，把责任一味地推给Coder。
其实本文的题目源于前几天与令狐在MSN上的闲聊。令狐说：
其实现在感觉那些关于Architect的所谓技术都是扯淡，这种高来高去的东东还不是说什么就是什么。国内谈这些东西的目的很简单，就像我在群里说的“资本运作”一样，弄点新概念出来吹吹，一是可以显示自己“了不起，这么新的东东我都理解了”；二是吹这个没风险，又不需要实际系统也不需要具体案例。
我补充道：还可以骗钱。中国的软件业没希望了，没人想踏踏实实地做事。
令狐：现在整个环境就是如此，大家都很浮躁，公司首先浮躁，客户也浮躁。因为现在很多项目是官方的，他们不怕花钱，所以工程商也无所谓，我只要我想要的效果，钱无所谓。就是这样。如果真的要花自己的钱，恐怕很多人就会认真的想想这个功能是不是自己真的需要的了。
其实ari在《漸近, 悟道!》中说出了软件的本质：真正的用戶(或者說成熟的用戶),永遠不會在乎你技術細節的選擇他只關心他的需求得不得到滿足!
我在《效颦篇：编程本质论》也曾经表达过类似的观点：软件开发就两个重点，一个是需求，一个是对需求的实现。其它的手段都是为这两个重点服务，否则就是本末倒置。
那些高来高去扯淡还是少一点，多干点实事吧。
=================================================
背景文章: 软件工程师与程序员的差别
from: http://borland.mblogger.cn/wujiang/posts/17773.aspx
程序员所具备的技能通常以深入理解一或多种语言及相应软件集成开发环境为主体。然而，众多软件开发机构往往感到程序员的技能单薄，具有明显的局限性，主要暴露在三个典型的方面：
第一，在编码之前，不能有效地理解软件的设计思路与内容，具体表现为不能充分理解规范的UML模型；
第二，在编码之后，不能向集成测试或系统测试人员提供高质量的代码，具体表现为不能自觉地进行单元测试；
第三，在编码过程中，不能有效地与其他开发人员进行协作，具体表现为缺乏基本的软件配置和变更管理概念与实践基础。
这三种典型的局限性是程序员与软件工程师之间的关键差异，也是软件企业决定录用开发人员的重要考量依据。
2005年3月31日 20:00
...全文
请发表友善的回复…
发表回复
gogovista 2007-11-02
- 打赏
- 举报
▄︻┻┳═一
if0000000 2007-11-02
- 打赏
- 举报
请看Ken Thompson在图灵奖颁奖演说词上怎么说：
我是一个程序员
http://www.cyberspace.org/~jhl/2678824_cn.html
我是一个程序员
http://www.cyberspace.org/~jhl/2678824_cn.html
gliet1981 2007-11-02
- 打赏
- 举报
好
redex 2007-11-02
- 打赏
- 举报
国内公司要在管理人上有点创新和进步, 而不要老搞 官僚体系下那一套, 除了军事化还是军事化
真不知道中国的公司除了"军事化"外你还能干什么??
在臭名昭著的 军事化 思路和心理理念下, 管理人始终摆脱不了"一管就死,一放就乱;再管再死,再
放再乱"的恶性循环; 缺乏对个人意志,创新理念的基本尊重, 使得中国公司的技术管理体系始终不能
真正有效建立起来(你说你通过了CMMI3, 但你的人在3个月内走了3分之2, 那不叫成功叫失败)
而在所谓的设计领域, 中国人普遍的"大而化之"的毛病使得所谓的"设计师","架构师"大致只是做了
模块划分之类的工作后就没事可干了; 另一方面, 他们把很大的一部分精力都用在讨好领导的方案
文档上了, 远做不到"详细设计"一层, 导致实际上的coder, 替那帮所谓的"高级人士"做了很多
设计乃至需求方面的工作... ...
这样的所谓"技术管理"(项目经理)和"高级技术"(设计,架构) 实在是够可耻的了, 但是大家还在
每天鄙视什么coder, 确实很可笑!
真不知道中国的公司除了"军事化"外你还能干什么??
在臭名昭著的 军事化 思路和心理理念下, 管理人始终摆脱不了"一管就死,一放就乱;再管再死,再
放再乱"的恶性循环; 缺乏对个人意志,创新理念的基本尊重, 使得中国公司的技术管理体系始终不能
真正有效建立起来(你说你通过了CMMI3, 但你的人在3个月内走了3分之2, 那不叫成功叫失败)
而在所谓的设计领域, 中国人普遍的"大而化之"的毛病使得所谓的"设计师","架构师"大致只是做了
模块划分之类的工作后就没事可干了; 另一方面, 他们把很大的一部分精力都用在讨好领导的方案
文档上了, 远做不到"详细设计"一层, 导致实际上的coder, 替那帮所谓的"高级人士"做了很多
设计乃至需求方面的工作... ...
这样的所谓"技术管理"(项目经理)和"高级技术"(设计,架构) 实在是够可耻的了, 但是大家还在
每天鄙视什么coder, 确实很可笑!
huanghaigood 2007-11-02
- 打赏
- 举报
有一定的意义，但楼主的意见我也不是完全苟同。
很多设计模式是在前人的经验的基础上经过实践证明是有效的，就像计算机中已有的
数据结构差不多，你很难自己创造出比它更好的结构。
至于你说的项目经历或者所谓的大师到底是否真的有本事?
我对此有很多也是表示怀疑的。
不过，我想如果一个优秀的数学家，如果搞计算机的研究，或者还能搞些名堂，但中国
的软件行业确实存在很多问题。
很多设计模式是在前人的经验的基础上经过实践证明是有效的，就像计算机中已有的
数据结构差不多，你很难自己创造出比它更好的结构。
至于你说的项目经历或者所谓的大师到底是否真的有本事?
我对此有很多也是表示怀疑的。
不过，我想如果一个优秀的数学家，如果搞计算机的研究，或者还能搞些名堂，但中国
的软件行业确实存在很多问题。
ies073288 2007-11-02
- 打赏
- 举报
jf
scow 2007-11-02
- 打赏
- 举报
个人意见，单就它列出的那三点来讲，和楼主你想表达的高来高去好像没什么联系。
redex 2007-11-02
- 打赏
- 举报
中国很多公司所谓的"项目经理", "软件设计师", "软件架构师"的水准普遍应该是很低的, 很可能
达不到基本的职业要求 和 职业道德水平:
表现在:
1.基本的文档及详细的设计往往被他们认为是所谓的"实现细节"推给coder
2.但这些所谓的"实现细节"极容易出问题: 出了问题只知道把责任往他们所谓的coder上推
所以我认为: 搞软件开发,技术管理的人 技术,管理固然重要, 学会做人更重要---如果我们社会所
培养的所谓"项目经理", "软件设计师", "软件架构师"等所谓的"高级人才" 全盘落入中国官僚社会
所养成的固有陋习的深渊, 那么你们就没有资格在那叫嚣什么 coder很低级, 因为你比coder还不如.
我认为: 坐在"项目经理", "软件设计师", "软件架构师" 这类职位上的人, 你本身就要有很好的
协调沟通能力并且这些东西应该是可以切实有效,高效实际执行(而不是光简历上写的什么"很好的团队
沟通, 管理, 协调能力"), 而在现实操作中, 很多所谓的"架构师"之类的人, 把他们所认为的所谓"架构"
或者"设计"彻底庸俗化了: 他们认为的架构就是把软件分块, 分成块以后让coder们去实现就完事了,
这样的职位确实太舒服了, 因为他们毫无集成风险意识, 没有详细设计的概念, 结果他们的水平在项目
中毫无提高, 反而用简单/粗俗的军事命令式的手法去教育别人"如何如何", 别人也学不到任何有用的
沟通,管理知识
达不到基本的职业要求 和 职业道德水平:
表现在:
1.基本的文档及详细的设计往往被他们认为是所谓的"实现细节"推给coder
2.但这些所谓的"实现细节"极容易出问题: 出了问题只知道把责任往他们所谓的coder上推
所以我认为: 搞软件开发,技术管理的人 技术,管理固然重要, 学会做人更重要---如果我们社会所
培养的所谓"项目经理", "软件设计师", "软件架构师"等所谓的"高级人才" 全盘落入中国官僚社会
所养成的固有陋习的深渊, 那么你们就没有资格在那叫嚣什么 coder很低级, 因为你比coder还不如.
我认为: 坐在"项目经理", "软件设计师", "软件架构师" 这类职位上的人, 你本身就要有很好的
协调沟通能力并且这些东西应该是可以切实有效,高效实际执行(而不是光简历上写的什么"很好的团队
沟通, 管理, 协调能力"), 而在现实操作中, 很多所谓的"架构师"之类的人, 把他们所认为的所谓"架构"
或者"设计"彻底庸俗化了: 他们认为的架构就是把软件分块, 分成块以后让coder们去实现就完事了,
这样的职位确实太舒服了, 因为他们毫无集成风险意识, 没有详细设计的概念, 结果他们的水平在项目
中毫无提高, 反而用简单/粗俗的军事命令式的手法去教育别人"如何如何", 别人也学不到任何有用的
沟通,管理知识
fellowcheng 2007-11-02
- 打赏
- 举报
看之
rickhunterchen 2007-11-02
- 打赏
- 举报
慢慢看
