刚看了一篇疆的《软件工程师与程序员的差别》,明显是中了某些所谓“大师”的毒太深的。
从前我们搞语言祟拜,后来又有了模式祟拜和软件工程祟拜,现在则流行UML祟拜和架构祟拜。《国际歌》说得好:从来就没有什么救世主。F.Brooks在二十多年前说过:没有银弹!--实践是检验真理的唯一标准,这二十多年来的实践已经证明,Brooks的论断是正确的。
第一,在编码之前,不能有效地理解软件的设计思路与内容,具体表现为不能充分理解规范的UML模型;
如 果Coder不能有效理解,仅仅是Coder的问题吗?Architect有没有把他的设计思路说明清楚?而且UML也不是设计的唯一表达手段,还有就是 Architect自己是否对需求作了正确的理解,也许他的设计本来就是错的。再说了,如果Coder的水平高到可以很容易地看明白设计思路,甚至纠正其 中的错误,那还要Architect干什么?
第二,在编码之后,不能向集成测试或系统测试人员提供高质量的代码,具体表现为不能自觉地进行单元测试;
不能自觉地进行单元测试固然主要是Coder的责任,但是按TDD的精神来说,测试(名词)是需求的表现,它应该是“先行”,而不是在编码完成后。这里同样存在一个问题:Architect在编码开始之前能否做到将需求细化到可以测试的程度?
第三,在编码过程中,不能有效地与其他开发人员进行协作,具体表现为缺乏基本的软件配置和变更管理概念与实践基础。
协 作不良的问题存在着中国传统文化的基础,但还有一个很关键的原因是:公司自身的团队建设工作做不到位,也就是说那些Manager们有很重要的责任。至于 软件配置和变更管理的使用完全没有技术含量,只要作一个简短的培训就行了,关键在于长效管理机制,比如制度化的Daily Building等。这些跟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在《漸近, 悟道!》中说出了软件的本质:真正的用戶(或者說成熟的用戶),永遠不會在乎你技術細節的選擇他只關心他的需求得不得到滿足!
我在《效颦篇:编程本质论》也曾经表达过类似的观点:软件开发就两个重点,一个是需求,一个是对需求的实现。其它的手段都是为这两个重点服务,否则就是本末倒置。
那些高来高去扯淡还是少一点,多干点实事吧。