刚看了一篇疆的《软件工程师与程序员的差别》，明显是中了某些所谓“大师”的毒太深的。
从前我们搞语言祟拜，后来又有了模式祟拜和软件工程祟拜，现在则流行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干什么？
不同层次的人对自己职业人生的规划和认识都不一样，就像你几年前醉心于技术细节研究，感觉做一个coder很爽，过两年coder不能带给你快感，你渐渐 从喜欢研究架构，团队....于是你觉得PM才是你的追求，再过两年，你觉得PM的成功还不够，于是你就开始搞些资本运作，大谈管理理念。再过两年你已经 是个国际人士了，开始和陈天桥平起平坐啦，有过两年你开始热心于写写自传，到企业传道授业其实关键是不要停止思考不要满足现状就行，至于此刻悟道的，过两 年回头看看觉得很可笑，因为你又在另一个层次了。
这揭示出了其中的根本原因：那就是做Coder没有提升的通道。
每个人都有自己的特长与适应的范围，并不是所有人都适合于做Architect或Manager，更不用说什么资本运作之类的。按《彼德原理》的说法，当一个人被升到一个不能胜任的位置的时候，就会开始有这样的表现：故意表现出一种高深莫测的感觉。
或者如本文的题目所说：高来高去的扯淡。
我不敢说国内所有的Architect或(Project) Manager都是如此，但至少是大部分。最简单的判断这种人的方法就是：他们是不是在项目进展出现问题时，把责任一味地推给Coder。
其实本文的题目源于前几天与令狐在MSN上的闲聊。令狐说：
其 实现在感觉那些关于Architect的所谓技术都是扯淡，这种高来高去的东东还不是说什么就是什么。国内谈这些东西的目的很简单，就像我在群里说的“资 本运作”一样，弄点新概念出来吹吹，一是可以显示自己“了不起，这么新的东东我都理解了”；二是吹这个没风险，又不需要实际系统也不需要具体案例。
我补充道：还可以骗钱。中国的软件业没希望了，没人想踏踏实实地做事。
令狐：现在整个环境就是如此，大家都很浮躁，公司首先浮躁，客户也浮躁。因为现在很多项目是官方的，他们不怕花钱，所以工程商也无所谓，我只要我想要的效果，钱无所谓。就是这样。如果真的要花自己的钱，恐怕很多人就会认真的想想这个功能是不是自己真的需要的了。
其实ari在《漸近,悟道!》中说出了软件的本质：真正的用戶(或者說成熟的用戶),永遠不會在乎你技術細節的選擇他只關心他的需求得不得到滿足!
我在《效颦篇：编程本质论》也曾经表达过类似的观点：软件开发就两个重点，一个是需求，一个是对需求的实现。其它的手段都是为这两个重点服务，否则就是本末倒置。
那些高来高去扯淡还是少一点，多干点实事吧。
