umlchina上的一场讨论

[ozzzzzz]

今天晚上在论坛精华里看到一篇题为：
“UMLCHINA已经害得很多屁都不懂刚本科毕业的小朋友走火入魔了，
作者3nt,发表于002/02/02 00:36”
原文如下：
“清除余毒将是一项艰巨的任务。
一些刚本科毕业什么项目都没做过的小家伙满口uml、rup、软件工程、cmm等等名词迅速把持了用户单位（甲方）的重要岗位（如项目监理）。对开发项目提出种种不合理要求，给开发单位（乙方）的工作带来了难以克服的困难和烦恼，直接导致了项目无法按期完工以及项目组成员的士气低落，给甲乙双方都带来了时间和金钱上的巨大损失。这些小朋友的共同特征是经常浏览UMLCHINA并不加区别地直接引用umlchina上的某些观点和言论。他们的共同症状都是模型至上论和文档至上论。
因此本人认为非常有必要在umlchina进行一次讨论：澄清什么才是软件开发项目的根本任务，什么才是真正的软件系统，以帮助这些小朋友转变认识，端正态度。
欢迎大家踊跃发言，谢谢。”

下面我想谈谈自己的看法：
本人是去年刚毕业的计算机专业的本科生，从事软件开发才一年多一点，我对软件工程概念懂的只是很少的皮毛，对各位高手来说，本人只能算是刚刚才学会走路的小孩，不知道那位3nt的从事软件开发有多少年了？任何一个程序员都是从“小朋友”向“大朋友”过度的，当前各种软件开发规范越来越多，大学里最先接触的是软件工程，其次才是uml,其次才是rup,结果现在又出来一个什么xp，本人只听说过windows xp,office xp等等其他很多软件都带得有xp，本人一直没有搞懂为什么那么多的软件都带了一个xp？？难道是赶时髦？更奇怪的是居然软件规范里也出了一个xp（请各位高手能告诉我是什么东东，谢谢）???
（1）3nt那位“大朋友”说我们好象没有必要知道那么多的名词，我认为对于任何一样新的知识，我认为每个人都有权利了解（可惜的知识更新太快，跟不上速度），然后对每样新的知识通过了解以后才会有对比，才能够选择适合自己发展的方向，如果连基本的知识都不懂，如何对比？如何选择适合自己发展的方向？况且每种新的知识都有它自己的精华，我们完全可以通过比较掌握他们精华的地方，对自己的能力提高有很大的帮助。
（2）3nt那位“大朋友”说我们经常提些种种不合理的要求，从而会造成项目的失败。我承认有时候我们会提出不合理的要求，为什么会提出不合理的要求，那是因为我们对软件这个行业并不是真正的了解，所以提出不合理的要求是很正常的，这说明我们是在积极努力的思考问题，这有利于我们不断提高自己的能力。我认为造成项目失败的责任并不在我们身上啊，真正的原因应该是在那些项目主管人的身上，如果他们真正的有能力，就应该能判断什么是正确的，什么是错误，应该有自己的一套思维能力，而不会听信他人说的。所以项目失败只能说明那些项目主管人没有能力。
（3）3nt那位“高手”认为非常有必要在umlchina进行一次讨论：澄清什么才是软件开发项目的根本任务，什么才是真正的软件系统，以帮助这些小朋友转变认识，端正态度。我想请教3nt两个问题：“软件开发项目的根本任务是什么？，你知道吗？请告诉我，谢谢”，“真正的软件系统是什么？你知道吗？谢谢”。
我对两个问题从我工作开始的第一个月就一直在苦苦的思考，现在也没有想出真正的答案（也许我确实是太笨）。如果你能“准确”的对这两个问题给出“精确”的回答，能够帮助我这个小朋友“转变认识，端正态度”，那说明你是真正的“大朋友”，否则，别太贬低我们这些“小朋友”，任何人都是从“无知”到“有知”，相信3nt也是这么过来的，除非你是“神童”。
所以，我认为某些自认为是“高手”的人不要以为自己工作了好多年就可以随便去教训“小朋友（包括我在内）”，我们提倡的是一个“和平共处，互相帮助”的环境，不希望看到那些“自命清高”的人存在。
注：我说的这些话并不是针对哪个人，请别介意，我只是想说说自己心里的想法而已。

smilemac 回复:
那位朋友的意思我想是这样的：本来一个刚毕业的学生刚出校门时前途无限，可以有机会成为数学家，成为物理学家，成为化学家，甚至成为考古学家，但就因为学了太多的uml，结果只能成为一个哲学家了。呵呵。


hglaz
呵呵，不管将来能成为数学家？物理学家？化学家？考古学家？但是每种“家”都是从“无知”到“有知”啊，每个人都肯定会经历这种“蜕变”的过程（包括我在内），所以，呵呵，不要因为自己“长大”了，就可以对后来的“小朋友”
横眉竖鼻了，smilemac,你说对不对？？？


newdongkui
凡是不可形而上学,我觉得3NT得话确实有过激得地方,好多达朋友,很多年了,也一直这样理论和虚幻,到不都只是小朋友.UMLCHINA 也不过是个论坛,走火入魔是个人得认识问题,在学校里,刚学软件工程,也都神经兮兮得.如果不幸做到技术管理位置,还确实是害人.


hglaz
举双手和双脚同意newdongkui的话,此贴回答的比较经典,应该列入酷贴,不知道newdongkui朋友是否同意??哈哈
任何人都是从理论到实践,再从实践到理论,所以人人都脱不开理论,关键就看人自己如何把握自己了.如果不幸做到技术管理位置,除非他是"神童"（我不是神童，所以现在还只是写代码的打工仔而已），否则，不仅会给公司带来害处，也说明那个公司的主管能力也有问题。newdongkui,你说是不是？？

newdongkui 别提了,一说都是眼泪
smilemac 夫多谋必寡断
一个优秀“软件工程专家”的最好出路可能只是做咨询或参谋,不能当大任.马谡谈兵法连孔明都佩服,可就是不能领兵.还有赵括.软件工程本来是一门技术性很强的学科,可很多“软件工程专家”却整天去流程来流程去，浮于表面上的管理形式化，有多少人能够潜下心去研究软件度量，去研究耦合度，去研究统计测试，自动测试，这些也都是软件工程，怎么少见人讨论（不是完全没有），所有人都避难趋易，背了一肚子名词、概念，谈来头头是道，做起文字游戏来思路清晰，但有多少人能够面临问题时随手拿出一个最适合的软件工程工具或其变种来解决问题呢？而这样的能力需要你去真正潜心去研究具体的软件工程工具，真正掌握各种工具的精髓，化多谋为少谋，将书读薄，而不是读厚。
newdongkui
很精彩的话,你的文字,基本赞成,我有些不同,在软件开发和实施过程中,人是最主要的,而不是工具,工具浅尝则止,深入理解客户的需要和业务是关键,人多多积累业务专业知识,才可厚积而薄发.其次,书读薄,并非终点,用,可让书变厚,而复薄.
smilemac
对，一样的，我说的工具不是指软件工具，而是如测试方法，度量方法等这些技术工具。这些东西都非常有用，尤其在时间紧，人手不够的情况下。
hglaz
对,我认为真正的“软件专家”不在于他满嘴的“之乎者”也，而在于他面临问题时是否能将书上的理论“真正的”应用于实际，能否能否将问题“分，而治之；治，而合之”。可能“理论用于实践”这句话很好说，但是真的做起来，却很难。这我可是有亲身体会的，至今想来还“心惊动魄”（可能说的很夸张，却是我最难忘的一件事情）。
另外，smilemac在最后说到的关于工具（不是指软件工具，而是测试方法、度量方法等），可惜现在又有多少人愿意给我们这些小朋友讲解这些方法呢？我们这些小朋友得不到高人的指点，又怎么能掌握软件工程的精髓呢并将之很好的运用于实际中去？我现在在工作中，很多时候都是瞎猫，在软件领域里乱转，很多时候都只能靠自己在不断的“头破血流”中汲取教训，获得新的知识。但有时候撞的“晕头晕向”，都还是没办法找到答案，缘何？没人愿意指点。
所以，我认为“软件专家”这两个字并不能因为他的工作时间长，是大朋友，就可以“自封其号”，很多时候，还应该记得帮助小朋友进步，让我们这些小朋友少走弯路。只有这样的“大朋友”，我才认为他已经有1/5的资格可以当“软件专家”了。

[老朱有话说]

埋单

[gigix]

我同意Daph()()()()()()()()()的意见：如果甲方提出了不合理的要求，乙方为什么不指出？如果乙方是因为除软件技术之外的原因而不得不接受这些不合理的要求，那么和甲方的“小朋友”有什么关系？

但是，为什么乙方往往不能指出甲方的哪些要求是不合理的？也许正是因为“软件工程不是科学”的态度。最近看裘宗燕教授翻译的《从规范出发的程序设计》，软件开发就是一个从计算机不可理解的规范精化到计算机可理解的代码的过程。如果乙方就不能从科学的角度证明甲方提出的要求是合理的，或者不能从科学的角度证明甲方要求的某个精化过程是合理的，这中间出了“不合理的要求”，你说应该怪谁？

to ozzzzzz(希望敏捷)：

我很同意“SE是工程学”的说法。以前做项目的时候，我们的软件常常做得乱七八糟，但老板总有办法弄到钱，你说这不是社会工程是什么？

我仍然认为，如果SE没有科学的证明，那么它就是瞎猫撞死耗子，就是我所说的“算命先生”。对于一个没有科学证明的SE，我宁可它从来不存在，至少还可以让开发者知道自己的无知。

不知道你对Refactoring有多少了解？从表面上来看，refactoring完全是一些经验的加合；但是实际上refactoring的语义保持性是得到了形式化证明的，因此它是科学的而非经验的——如果你跟别人说：“据我的经验，这样改改代码可以提高可读性。”谁敢采纳呀？

另一个例子：Eiffel采用的Design by Contract被认为是很有前途的方式。实际上，Design by Contract的理论基础在那本《从规范出发的程序设计》中都可以找到。看过那本书以后，你只会感觉奇怪：为什么以前没有支持Design by Contract的语言出现？再一次地证明了“工程学”的短视。

我完全同意工程学部分角色的重要。对于大多数的软件开发者来说，搞好工程是最重要的。但是，如果因此而放弃对软件科学的探索……再一次用那个词：短视。

顺便说一句：我最反感“满口uml、rup、cmm等等名词”的所谓“软件工程师”。不过，这不是软件工程的问题，而是某些人已经把“软件工程”当做在IT业这个权力租金盛行的地方寻租的一种资本。那种开口UML闭口OO的人，又有几个真正研究过OO的形式化证明的？这种软件科学是伪科学，跟我所说的软件科学是两码事。

[八爪鱼-杭州]

学习

[jlandzpa]

有意思.

[Elkel]

-_-!

[zhuma]

棒喝
好险

这段时间我好像也陷入"方法学至上论"了
动不动就用这套东西和导师胡侃
前几天连boss也没放过

虽然最近一直在看这方面的材料
但要用何其难呀

我有个一起打工的同学陷得比我还深
动不动就让我画UML

我真是敢说不敢用
怕刀没耍好，反伤了自己

估计目前只能在实践中体会理论了

幸好导师有个研究型项目交给了我
就用它作试验品吧

欢迎指导

[drama]

服了U.好像你比我大多少似的.
代码只是权宜之计,一旦人手足够,我就放手了.以为我没事就愿意去code啊.

[yowa]

“减肥其实本来就是一种生活态度，减与不减随你”，我们这边就是“这些技术就是一种开发方式，用与不用随你”!呵呵……

[drama]

o6z,好像你比我大很多似的.
编码只是权宜之计,等人手够了.就放手了.呵呵.以为我愿意编码啊

[3nt]

张三对李四说：“哥们儿，你拉链忘拉上了。”
李四对张三翻白眼：“这叫酷，懂吗。再说了，前天你不也忘了吗”
旁边王五跳出来叫道：“别犯啥了，1加1就是等于2”

[3nt]

修正版：
张三大喊：“大家都来看哪，哈哈，李四没关前门。”
李四对张三翻白眼：“这叫酷，懂吗。再说了，前天你不也忘了吗，拽什么拽”
旁边王五跳出来叫道：“你们别犯傻了，以柏拉图、苏格拉底、孔夫子、李耳、息达多、基督耶稣、莫罕莫得、牛顿、马克思、爱因斯坦、图灵、克林顿、叽里咕噜、阿里巴巴的名义1加1就是等于2！”

[ynli2002]

:)

[ozzzzzz]

其实我真的不太理解小朋友 因为我毕业的时候不是这样的 那个时候我们死活哦不出头 所以也没有什么大想法 只要把领导交给的事情办好就很满足了 而这些小朋友似乎更有追求 但是他们忘了 软件这个行业经验宝贵的要命 我们之所以还可以在这里混饭吃 必定有我们的东西 如其和我们争执 不如向我们学习 只要我们的工作可以达到你的要求 不要管我们是怎么做的 当你有了一些工作和社会的经验以后 自然会明白我们的一些作法 其实向我们这些老东西都会很谦逊 真的
drama这个家伙是个小朋友 我就是要大家知道这是人成长的烦恼 我们有过 所以我们应该多对小朋友一些善意的指引
drama你以后别写码了 经理干些经理干的事情多好 干好自己的事情 学学linux 这个东西以后是你们电子政务的基础平台

[ozzzzzz]

gigix(透明)
方法学不是科学 但是不能说方法学不是建立在科学基础上的 请注意 而且在很多情况下甲方的不合理要求不是能够马上直接的指出的 这是有销售方法的问题 同时本身也有过程学是建立在大量经验基础上 有些东西只是一个统计学的结论的结果 而且有些什么甲方的要求貌似合理 但是在你作为甲方看来没有实施的可能 而你要支持你自己的结论 你就要付出成本来验证你的观点 儿这有时候是代价很高的 而且在一些没有实践经验的人看来事情似乎很简单 但是实际完全不同 经验永远是我们最宝贵的财富 当然不能让它变为包袱
还有过程学永远是商人的科学 它研究的最大课题就是成本 很多情况下你的做法很科学 很有开创性 但是成本太大 那么就不能实施 我想这一点你也很明白 而且最为我们的研究的不是甲方需求的合理性 我们研究的是他们需求实现的成本的合理性 这是一个信任的问题 我们应该相信甲方对于他们业务的专业素质 而同时甲方也应该相信我们的专业素质 如果我们花费大量时间去做互相的对对方专业的研究 是不现实的 但是原理上说我们精通我们所服务的行业绝对必要 但是这是要时间和代价的 所以从这一点来说 工程学总是短视的

[kx-gaowei]

很有收获,UP!

[jspxnet]

一半的一半

[AiWangji]

to gigix(透明):

首先要申明我非常同意你大多数的观点，包括现有的软件工程学还是
一门非常“短视”的学科。一些“满口uml、rup、cmm等等名词”的所
谓“软件工程师”其实他们离软件是什么还没有搞清楚了（他们可能
还在背“软件=程序+文档”的教条）。

但是就你的因“软件工程”不能被量化的验证而就将其成为“伪科
学”我想提出一点质疑。记得确实有一名很著名的前苏联科学家在讲
数学的重要性时，提出只有能用数学的方法加以验证的规律才能成为
科学。当时我认为这句话很经典。可是后来仔细想一想，我觉得还是
应该加一个定语，既是人目前能认知的科学。其实这只要问一个简单
的问题就会明白了，数学的产生只有几百年的历史，而不依赖于我们
人的认知的科学规律是从恒古以前就存在了，我们用一个人的认知
概念（数学）来定义一个不依赖于人的认知而存在的客观规律（科学）
是不是有一点不妥呢。是不是前面要加一个定语呢。否则的话所有的
哲学，方法学，以及部分的认识论都将不成为科学了。而认为虽然上述
学科不能被数学证明，但是只要是一种正确反映统计规律的学科的话，
那么我们也能将其成为是一门科学，当然是一门没有被数学验证的科学，
或可以称为不能被完全验证的客观规律（科学）。

那么为什么我们比较容易接受用数学证明过的科学呢。最近霍金比较
热，借用他的一个比喻，其实我们生活在一个多维的空间里，但是由于
我们的渺小使我们只能看到一个多维空间在四维空间的投影，我们也就
容易接受宇宙万物是四维的了，其实不然。同理，因为我们人的能力
所限我们现在只能当规律规律映射在数字世界里时我们才能去接受它，
认识它，但是这不表明规律是不存在的。

说了这么多，其实就是一句话：软件工程虽然现在很短视，但是不能
否认其科学性。

[AiWangji]

订正一下

那么为什么我们比较容易接受用数学证明过的科学呢。最近霍金比较
热，借用他的一个比喻，其实我们生活在一个多维的空间里，但是由于
我们的渺小使我们只能看到一个多维空间在四维空间的投影，我们也就
容易接受宇宙万物是四维的了，其实不然。同理，因为我们人的能力
所限我们现在只有当规律映射在数字世界里时我们才能去接受它，
认识它，但是这不表明在数学世界之外的规律是不存在的。

说了这么多，其实就是一句话：软件工程虽然现在很短视，但是不能
否认其科学性。

[f190]

看了这么多，我只想说这些开口闭口牛顿康德XP的人，这些故弄玄虚的人
能否你们列出你们做了那些有名有姓的项目
项目的金额有多大？客户对你们的项目评价又如何
能否让我们瞻仰一下
还是只有成吨的辩论，纸上谈兵
古代的马谡赵括之流当年想来也就如此罢

[mis98ZB]

我也差不多是3nt老大说的那种小p孩呢……

我现在正在作一个纯C项目的详细设计，
正试着在函数里面使用static变量来部分模拟对象，以期降低函数接口的复杂度，提高变量的安全性。请各位老大评估一下这个想法的可行性和实用性。

StructA* InputBufferOperater(int OperateType){
static StructA* ptrBufferHead = NULL;
static StructA* ptrBufferReader = NULL;
switch(OperateType)
case 0://create buffer and set ptrBufferHead
case 1://get read pointer
case 2://move read pointer to next record
//if buffer is empty call FileOperate(1) to read data
case -1://destroy buffer
}