编程离软件工程有多远？_项目管理者论坛->项目经理职业发展版_国内最热门的项目管理经验交流论坛_国内PMP聚集社区

项目管理者联盟 | 中国工程管理网 | 中国研发管理网

会员中心

资料库

适合敏捷开发项目
敏捷项目管理最佳实践

重视项目商业分析
商业价值与需求分析能力

产品管理国际认证
全球产品管理最佳实践

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

大型复杂项目全球标准
定位高级项目管理层

链接战略与项目
实现组织资源投资回报

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

论坛
	价值源于交流与分享

会员区：

功能区：公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册

论
坛
导
航
区

项目型组织	项目管理	工程项目	科技项目	项目化管理	管理软件	资格认证	职业休闲
EPM体系与流程	综合集成管理	总承包管理	IT软件开发	项目型制造	P3E/P6	PMP \| PgMP	职业发展探讨
组织与人力资源	进度,范围,成本	国际工程	生物制药	专业服务	微软PROJECT	IPMP \| PRINCE2	管理学堂
项目管理信息化	团队建设与沟通	房地产	汽车设计开发	生活项目	PowerOn专版	软考项目管理	英语角\|读书版
多项目与大项目	质量与风险	监理与咨询	手机数码	文体娱乐		注册建造师	房车吃游
PMO建设与管理	采购与合同	工程设计				项目管理硕士	闲聊版\|商务版

俱乐部：北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立

TOP榜：精华 | 最新 | 最热 | 会员

版面信息

说明：探讨项目经理的职业发展之路，如何成长为一名优秀的项目经理，项目经理的未来职业之路又在哪里

	精华区		发表帖子
	投票区		发起投票
	资料区		上传资料

本版版主

zqjcep
登录：2019/1/2
次数：1846
注册：2003/5/13
发帖：6068

俱乐部导航

北京	大连	福州	广州	杭州
南京	山东	上海	深圳	四川
天津	武汉	西安	郑州

联盟·近期活动

社区热点

精彩专题

如何做好项目沟通计划

软件项目质量管理

国际工程索赔与反索赔

社区圈子

集团企业生态体.
圈主：ETPPM
行业：综合应用

深圳IT项目管理
圈主：lshcom
行业：综合应用

项目管理知识宝.
圈主：wenyu2010
行业：工程设计安装

项目经理职业生.
圈主：zhenjm
行业：综合应用

生态系统体系下.
圈主：ETPPM
行业：综合应用

联系社区管理员

编程离软件工程有多远？ [发表于 2014/3/1]

状态开放帖 浏览量 2493

复制该帖链接收藏本帖

[回复] [引用]

该帖子同步发自圈子：IT项目管理圈 (访问该圈子)

　　语言只是工具
　　我曾经是非常执著的开发人员。我有连续几天几夜 Coding 的经历，也曾经为了一个技术问题耗上三四个星期而导致项目一再延迟，还曾经为了一个实现细节与项目相关的人员逐一争论。
　　我也曾经像大多数的开发人员一样热衷于争论语言之间孰优孰劣。我在“Delphi大富weng论坛”上写过一个简介，其中个人特长是“擅长 TurboPascal、Delphi、TASM 系列语言，痛恨 C/C++。(凡见有价值之 C 代码，先读通，后写成Pascal/Delphi，最后骂一句：C 写得真笨!)”。我至今保留这段文字，因为那的确是真实的经历。
　　如今我已经不再专注于语言，正如我在第一章中写到的一样：成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。
　　然而就在我写这段文字之前的一年，我还在写《Delphi 源代码分析》，我还在无休止地深入语言的细节，深入操作系统的细节，以及深入……开发的细节。
　　就在 2004 年 3 月间，我接受一个朋友的邀请，去北京做一个名为“Delphi &Delphi .NET 源码分析”的专题培训。我用了近两周的时间，做了 50 页的幻灯，全面讲述 Delphi 和 Delphi .NET。然而在临行前的一晚，我辗转反侧，一直在思考一个问题：我究竟做了些什么?或者说，我究竟想告诉学员些什么?
　　凌晨 5 点，我在幻灯的末页后面插入了一张幻灯，标题是“语言只是工具”，而幻灯的内容是下面这样一张图。
　　这是与培训完全无关的一张幻灯。然而，这是我自 1997 年接触到管理，以及 1998年接触到工程以来，第一次正视“软件工程”这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系!
　　

　　对于一个程序员，或者以程序员自命的人来说，看清楚这一切的第一步，竟是一句“语言只是工具”!猿之于为人，“学会制作和使用工具”是最重要的标志。因而我不知道“语言只是工具”这句话，究竟是对语言的膜拜，还是漠视。
　　然而从那一刻开始，我才真正地知道工程。
　　关注点
　　在前面的模型图中，每一条纵向的细线用于定义一个关注点①。我在另一次培训中为这些关注点加上了标注，如下图所示。
　　

　　这被我命名为软件工程层状模型(EHM，Engineering Hierarchy Model)。EHM 模型不描述工程元素间的关系，甚至在试图割裂这些元素，以使得工程角色定位及各自的视角更加清晰明确。
　　从这个模型中可以看到，在“程序”与“方法”层面，是关注于“(具体的)实现”的;而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为，而项目经理则保障团队的稳定性和一致性。
　　程序
　　EHM 模型图中，在最内层的环里，是“程序=算法+结构”。这是编程的本源定义，也是原始的状态。与代码相关的任何工作，最终仍旧会落足于这样的一条规则。
　　编程的精义在于此。从有开发行为开始，它就存在了。愚公在数千年前就在用类同的行为做编程实践，而几十万年前的智人，也在循环与分支所构成的逻辑中打转。
　　方法
　　推动这种逻辑向前发展的，是“方法”和“方法论”的出现。长期的编程实践，自然的归演与总结，必须沉淀为某种(软件开发)方法，于是“过程”出现了，于是“对象”出现了，于是相关的方法论也就出现了。
　　这是实践的成果。方法不是某个人或者某个组织创造的。瓜熟而蒂落，实践积累达到一定的程度，微软不提出某个方法，IBM 也会提出这个方法。即便他们都不提出，可能你自己已经在使用这个方法了。
　　方法并不神秘，因为它就是你今天正在做的、从事的和实现的。正如“模式”是一种方法，而模式就是你昨天书写代码的那个行为。只不过，GoF 归纳、抽取、提升了这些行为的内在规律。
　　你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。
　　同理，理解过程也需要编程经验，理解对象也需要编程经验，理解 MDA(模型驱动架构)与 SOA(面向服务的体系结构)还是需要编程经验。
　　——这可能就发生在你去回顾你的上一行代码编写的经过，或者上一个项目失败的经历的那一瞬息。经验来源于回顾、理解与分析，而不是你将要写的下一行代码。
　　有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。
　　GoF 因为无数次的代码回顾而得道。
　　过程
　　过程伴生工程而出现。过程解决的是工程中角色间的关系问题。
　　过程说的是很多的人(团队)如何组织在一起进行开发的问题。它首先把工程中的环节分解出来。这样，有了环节，就有了角色;有了角色，就有了沟通。
　　因此过程中的问题，就是角色、沟通和环节的问题。哪些环节重要，取决于具体的编程行为，也就是具体的项目。
　　例如产品开发的周期可以一再拖延，因为对产品来说，更重要的是品质和技术壁垒。因此你可以看到暴雪公司(Blizzard)的游戏总是一再跳票，而它从来都是将大幅的玩家测试和开发人员的个性特征放在第一位。与此相同，DOOM 与 QUAKE 系列的灵魂就是在游戏引擎的开发和设计上。
　　如果用这样的模式去做项目，可能软件公司没死掉，工程需求方也被拖死掉了——你有看见客户因为你对技术的远景描述而憧憬吗?不，你只会看到他们因为项目的一再延迟而懊恼、沮丧，或……暴怒。
　　憧憬这种事情，只会发生在那些铁杆玩家的身上。
　　分不清玩家与客户的区别，对项目经理来说，是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。
　　角色的确定，以及角色间的沟通问题，在项目过程中也同样重要。工程组织是否合理，相互的协作是否紧密，是这个项目能否成功的保障。
　　“合作无间”通常是流于书面报告中的措辞。真正的“无间”，应当是沟通的结果。然而 UML，则可能是你与客户，以及项目经理与开发人员被“离间”的第一因素。

--------------------------------------------------------------------------------------------------------
项目管理是最好的执行力

>>> 由论坛统一发布的广告：

楼主

铁托

职务无
军衔主帅
来自安徽省
发帖 1460篇
注册 2006/4/30
PM币 19794
经验 8605点

！您尚未登录，不能回复主题。现在登录注册

建设运营：共创时网络