发信人: fentid(欢乐英雄)
整理人: telescope(2001-03-03 22:00:25), 站内信件
|
个人觉得还是有点道理的，所以转过来给大家评论。
现在做一个系统分析员要面对的却不仅仅是技术，他们还必须面对各种各样的商业规范，有些客户甚至把整个商业模式的设计也推到了系统分析员的身上，这些客户根本不知道自己要做什么，连人事，财务方面的要求都说不出来，商业模式的设计是经济学家的事，而不是计算机专家的事，但这种超越了外部设计范围的事却在很多情况下落到了系统分析员的身上，在这样的情况下也许系统分析员都得是MBA他的设计才能让客户满意，看着我那个group里的那个系统分析员用了差不多一星期时间和客户讨论商业运作上的问题，我当时的想法就是我以后坚决不干这一行。其实公司应该专门养一个MBA（如果养得起的话）来应付这些无理的客户。因为一毕业就到日本打工，所以我说的都是日本公司的情况。国内情况不太了解，想必也差不多吧。听说国内还得应付公司内部的种种勾心斗角，更让我心寒。
现在软件工程论坛好像有一种盲目推崇印度的风气，其实印度的方法真的那么值得我们学吗？其实未必。
先谈一下waterfall的问题。waterfall的开发模型适合于印度，但不适合于中国。因为印度的主要市场是接受国外软件公司的定购，由于客户本来就是同行，需求非常明确，也不太可能在开发期间有什么改动，设计书大家都签了字，要改可以，拿钱来。另外，印度的程序员很多都是高中生，成本低，好管理，所以waterfall在印度并没有太高的风险和成本。虽然waterfall在印度获得成功，但的的确确它是一种非常古老和落后的模型。工程一旦启动，几乎无法更改，设计期间程序员几乎无事可干，人员利用率低下，抹杀个性，程序员劳动积极性低下，无法实现程序员富有创造力的想法，程序员对技术的研究不深入，开发出的程序运行效率低下。另外，设计几乎是面向工程的，代码的重用性很低。这种模型唯一的好处是对管理者和开发者的要求都很低，高压政策加上没有思想的廉价劳动力就可以了。这个模型对很多公司是不适用的，比如说在日本，如果客户在中途要更改要求，这时虽有法律文书在手却是一纸空文，因为大部分软件公司的主要客户是公司的最大股东，得罪了客户意味着什么就不用我说了吧（没有竞争的社会，也许是日本软件虽排名世界第二出口缺少的可怜的原因吧）。所以我们公司都是用的spiral模型。我想在国内，虽然不太会有类似日本的原因，但可能连相关法规是否健全（不是指书面条款而是具体执行）都成问题吧，另外还有同行的恶性竞争（往往是通过非法手段）。我想在这样的环境下盲目学印度简直是自杀。我想还是用spiral模型跟加适合国情。（prototyping太作坊化，没有前途的。）其实spiral是一个非常好模型，不光在日本，在欧美也非常普遍地被采用，因为它和当今的面向对象技术是最容易紧密结合的。有人抱怨这个模型开发的东西不稳定，确实这个模型给程序员较大的空间，但这并不成为程序不稳定的原因。这个模型需要管理者有更高的素质，在这个模型下高压政策行不通。所谓“牛人”在项目中捣乱，往往是出于它没有获得应有的尊重引起的。他们一腔热情去学习各种最新的技术，去了解系统，去研究各种算法，而换来却是编码是最低级的事情，拧拧螺丝罢了之类的话。其实他们不知道，做一个牛人要比做分析员付出更多的努力才行。那里有压迫哪里就有反抗，不写注释，无他，这样的领导太让人不放心，为了生存而已。变态到希望没有人看懂自己代码的人毕竟是少数。一个好的项目负责人，不应该忽视组里每一个人的作用，而不是整天一副高高在上，目中无人的样子。这样其实比一个坏的设计方案对工程的影响更大，大家不敢得罪你，就把气出到分析员身上，可怜的分析员。好像听说还有分析员兼任项目经理的，连分工都不明确谈什么软件工程。
在日本，除了sa还有se，他们的主要工作仍然是代码，还有内部设计，但是他们几乎拿着和sa相同的工资。这样做其实让代码高手有了一个可以得到肯定的机会，对提高软件的质量其实是很有帮助的。其实在把外部设计和内部设计分开比印度人那样把内部设计和代码分开更科学，因为se负责的模块范围都不大，而se都是编码高手，对自己的负责范围几乎可以完全控制，所有代码都要经过se的检验和修改，其实每个模块都接近出自一人之手的状态，另外spiral模型是waterfall和prototyping的混合，从se负责的模块开始使用prototyping，所以在这个层次上代码是完全独立的，所以即使将来要修改，一般也不会出现一发而动全身的事情。相反，像印度那样连设计函数接口的人都不写代码（其实一般直到这一步都是由sa完成），其实在这种情况下，代码是很容易失控的，除非招收一批没有思想的编程机器，印度的种姓制度为产生这种机器创造了极佳的条件，我敢说，除了印度，世界上不会有第二个国家的程序员那么听话。其实他们有一个共同弱点，把编程作为一种职业，而不是一种事业，一种乐趣，他们的代吗简直就是八股文，想想中国过去的科举制度吧。思想上的高度统一和僵化虽然可以取得短期的领先，但最后必然走向灭亡。这与软件业也一样适用。有一点思想的印度程序员都会到国外去，我问过公司的一个印度人为什么到日本来，他告诉我，虽然在这里他感到受歧视，但每个人都可以有自己的想法并说出来，工作时是互相合作，而不是盲目听命于某个从来不写程序的人的指挥。我问他怎么看他们国家的软件业，他只回答了我一个词hopeless。
我说印度人的代码烂是有根据的，我们的客户（股东）因为经营状况不好，去年没有向我们公司而向印度人定制了一个solaris下的一个商务系统（贪图便宜），回来后发现奇慢无比，拿回去返工，结果印度人不认帐，说项目书里没有说明速度要求。自己理亏没办法，只好来找我们公司帮忙改，为了筹集资金，抛掉了我们公司40%的股票（日本的企业制度我到现在还不太明白，当然这70几亿日元在这个项目上只用了10亿，另外都用来发工资还债之类了）。这个项目最后落到我们组里，看了项目书，我们的sa当时说要重做，因为有一个关键数据结构要从双相链表改成B+树，否则快不了（真不知道是那个混蛋设计的）。后来由于客户态度强硬（在外没本事回来发威了），和几个se商量了几天决定硬着头皮改。由于程序结构的问题，这个改动工程浩大，连我这个本来做做notes jsp的小喽罗都叫去帮忙了。改了几段程序，从而有幸目睹印度人程序的风采，文档是不错，还有英日两套版本，所以象我这种从来没玩过Unix的人也能看懂他们的程序（当然这几段代码都和系统无关），可里面的代码简直就是垃圾，到处充斥着穷举冒泡之类的低级算法，我不知自己的这个模块是不是被经常调用，如果是的话，即使主结构没问题，这个程序也快不了。整个系统调试完毕以后，响应速度从45秒提高了10秒。不过经过这次折腾，我们的客户业没吃亏，因为本来我们公司的开价是27亿，现在连付给印度人的，才花了15亿（知道印度出口额高的主要原因了吧）。
以中国计算机教育的现状根本不可能招收大量高中生做程序员，所以对一群平均学里超过本科高水平的程序员队伍，（如果不做程序员，他们会和你一样有很高的地位。）不应该盲目学印度采用野蛮的方法来管理，多学学欧美，日本才对。难道我们发展软件业的目标仅仅是做廉价劳动力吗？（我没资格说这句话，因为我自己也是）还有，我们的管理者们，不要整天梦想着自己有一群没有思想没有自尊程序员，而是要努力提高一下自己的管理艺术，就你们这种水平，把你换到gates的位置上，用不着联邦法院的命令，微软的程序员就把微软拆了。
----
人潮人海中 有你有我
相遇相识相互琢磨
人潮人海中 是你是我
装作正派面带笑容
不必过分多说 自己清楚
你我到底想要作些什么
不必在乎许多 更不必难过
终究有一天你会明白我 |
|