|
锁定老帖子 主题：双倍赤裸裸的真理——评《软件工艺》
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-06-02
感覺上去此工藝非彼工藝,我原先覺得,當然是課本上學的,工藝是在確定了工序之後,然後針對某個工序執行的某個動作,似乎工藝的作用是為了求精
前段時間看到關於過程目的的敘述:過程的目的是按時和用有效的成本提交可實施的軟件,並且還要注意的是在開發人員受到打擾最小的情況下,為項目內外的各種關鍵角色提供準確和有意義的信息.感覺此段話沒審麼不好的,而且覺得工藝和過程也沒審麼可比性而言,所以關於dlee大大的這段話比較有疑問: 引用 不过我现在对于工艺和过程的优先级来说肯定是把工艺放在过程之前的。道理谁都明白，没能力做出来的东西即使采用再好的过程仍然做不出来。所以一个软件公司最值得尊敬的是那些技艺精湛的老程序员（铁匠铺里的老师傅）。凤舞凰扬因为软件工程的书看的比较多，把这些人的能力矮化了，实际上这些人已经达到合格的系统架构师的层次，而不是只会对某个细节精益求精的人了。这样的人就应该一直做技术层面的工作，而不是学而优则仕地去做管理。当然收入分配也应该适当向这些人倾斜。我见过一些 PM 完全脱离了开发（甚至还有连需求都不认真做的），只会跟在屁股后面催进度，变成了真正的监工。这些人由于自身开发经验的缺乏，完全无法准确地估算工作量，控制项目的进度和质量。我并不认为这样的人对公司是有很大贡献的。从软件工艺的角度来建立一个公司员工能力和贡献大小的衡量体系是非常合理的，也是让员工更容易接受的一种方式（干的多干的好拿的也多，你有意见吗？）。
|
| 返回顶楼 | |
|
发表时间：2004-06-02
本人接触日本人的开发方式还算早。他们的V模型其实还是很好的，但是除此以外日本人的东西可以说全都是反面教材。而对于敏捷在日本的流行也比我们这里热的多。但是我不想给大家介绍这些，因为这些不是问题的核心。现在我们面对的不是不是5年前，以至于不是一年前。现在我们面对的是变化多端的市场体系，是一种对成本核算和质量标准要求近乎苛刻的市场。那些让你可以温文尔雅的按部就班的方法论，都不能让你适应这样的环境。XP在我看来都不够极端，都不能面对这样的场景。日本人的小儿科就更加让人觉得可笑。
现在我们即将面对的情况是你必然会失败，成功只是一展偶然的运气。我们所能做的，也不是那些以前些年软件工程研究的减少错误，优化流程就可以让你成功的了。我们将面对的环境要恶劣的多。在这样的条件下生存就将按照一种另外的形式进行，那些不能及时专横跋扈思维方式的人面对的就只有死亡。软件开发将从新成为一种个人英雄主义的活动，任何一种试图依靠所谓的方法和过程学说都会被认为是脑筋错乱的产物。组织高度自管理自控制，扁平的组织成为唯一的形式。动态和高变化成为首先要考虑的，所谓的以需求为驱动的开发将被彻底的抛弃。 我不知道谁能生存在这样的环境中，但是我知道日本人肯定不能生存。 |
| 返回顶楼 | |
|
发表时间：2004-06-02
to o6z：
o6z 兄的话深合我心。以前软件工程一类的书中举的案例动辄就是数十人、上百人的团队，开发时间持续一年以上。但是事实上我做过的项目很少有 6 个人以上、持续时间超过半年（我确实没有实施大项目的经验，没有什么好惭愧的，也许以后会有这样的经验）的。软件工程在这里不适用（实用）是非常明显的。我考虑的问题根本就不是如何中规中矩地实施软件工程或者某种软件过程，而是如何在这个项目结束的时候还能够幸存下来。非常幸运的是我做过的项目客户都真正用起来了，并且在后期的维护中我们基本上满足了客户对系统的绝大部分期望。我不知道这是不是某种成功，我只知道我现在仍然健在，这似乎不是一件偶然的事情，然而我居然没有依靠任何软件工程！ to potian： 已经读到第 5 章。作为一个老 Linux Fan 和一个天生的实用主义者，我无法否认书中所说的话。至少 90% 的内容都是令我信服的，因为在开源世界能找到如此多的证据来证明作者的观点。即使只是一本供消遣的书，区区 15 元钱居然能够让我得到如此多的阅读快感，已经可以说是物超所值了。当然也要感谢透明流畅的翻译。我并不会认为这本书浅显易懂就瞧不起它，否则《解析极限编程》同样是这样一类让我瞧不起的书了。 QEP 我没有看过，也不打算读，因为我本人对 XP 的质疑已经说的够多的了。我并不认为真的需要全盘照搬 XP（第一步，全盘照搬；第二步，吸收消化）才能够说真正理解 XP。XP 本身就像一泓清泉一样清澈见底和易于理解。我参与那个 XP 开发团队只有一个多月时间，可以说是浅尝辄止，后来我离开了那家公司。当时我就感觉 XP 有些问题。后来我非常认真地读了 Kent 和 Martin 写的那两本书更加让我认为不能照搬 XP。Kent 和 Martin 也从未认为 XP 就是什么万灵药。XP 实施的前提条件写的很明确了，非常遗憾的是能够满足这些前提条件的环境实在是太少了。 |
| 返回顶楼 | |
|
发表时间：2004-06-02
to:albert_qhd
工艺就等于不写文档？ 工程就等于日本式的软件开发？ 照着日本人的软件设计书写程序，也不是软件开发的全部，至少还要有人写设计书吧？那么我不甘心做蓝领，想去写设计书，有什么好被你嘲笑的呢？ albert_qhd说：“在中国很多公司文档一踏湖涂，代码一塌糊涂的情况下，单纯强调软件工艺时机未到” 我就无法理解，无论软件工艺还是软件工程，难道有哪一种是允许“文档一踏湖涂，代码一塌糊涂”的？或者说，实行了软件工程之后，“文档一踏湖涂，代码一塌糊涂”就能自动变好了？ 你的话，实在是过于偏颇了！ |
| 返回顶楼 | |
|
发表时间：2004-06-02
现在我们面临的是生存问题。我们没有DoD这样一个大家伙给我们托底，而且DoD还巴不得我们去给它埋单。动不动就说软件工程怎么怎么样，但是我想大家有几个人去真的了解了工程的含义，想过为什么软件工程来自美国。我并不认为软件开发就纯粹是工艺而没有工程，但是说日本和印度有软件工程，并且认为我们应该向他们学习，我是觉得不会同意的。第五代计算机和软件工厂的缔造者是唯一值得我们学习的经验就是他们的学习精神，而不是他们的愚蠢做法。
文档确实很重要，但是它没有重要的成为一种核心资产的地步。过程也很重要，但是和人的能力比较起来，它一钱不值。 我现在不是为xp辩护的问题，而是要主动出来否定xp的问题。我觉得xp还不够灵活，还不够轻，还不够快速。因为我们面对的环境已经不是2000年那个时候了，现在的商业环境变化更加快速了。我们现在面对的就是人力的缺乏，项目的紧迫，投资的缩减，质量的严格，等等极限型的项目。我认为极限编程并不能很好的解决这些极限问题，那些所谓的传统的陈词烂调就更加不是。这是一个挑战，一个大的挑战。我们必须在没有银弹的条件下，杀死人狼。 |
| 返回顶楼 | |
|
发表时间：2004-06-02
日本人是典型的一种矛盾的场景。
在CSDN上我的一个朋友他的老师是日本的面向对象专家，他是极力推行xp的。而这个人的号召力在日本绝对是最强的学伐。而日本人对体制的认同和对于条条框框的遵守是一种民族的属性。所以你经常会看到，那些高层的设计者使用敏捷的方式把系统完成以后，在把代码变成伪码，交给那些底层的编码者去完成。而他给我看过的一些日本网站，至少在我看来对于敏捷的接受程度要比国内的人强的多。而他所在的团队在日本很有名望，因为他们使用xp完成了很多IBM、日立、富士通这些公司所不能完成的项目。而我最早知道xp其实也是来自一个日本公司的ABC。 日本就是这样一个矛盾的国家，他们的民族特性让他们不可能真的形成自己的东西，他们只能模仿再模仿。 |
| 返回顶楼 | |
|
发表时间：2004-06-03
Dlee:或许我偏爱KentBeck，但KentBeck的书往往是微言大义，我看了总有微笑的欲望。
真正讲编程的书我就仔细看过两本，看C Programming Language的时候，我认为已经尽善尽美了。而看到Smalltalk Best Practice Patterns以后，我可谓失言了。(象“重构”这样的书和这本书一比，相差何止十万8千里，何况最有价值的就是CodeSmell.) 我刚才去看了，Amazon上所有的review都是5星的，或许可以看看别人的评论： 引用 Although I've never used SmallTalk and have read only a couple of on-line introduction chapters on Dolphin SmallTalk, I had no problems reading it and applying the patterns in another language like Java, C++ or Python. Let me put it simple: If you want to learn to think in objects, don't just read the book, do it! Milestone for Your Programming Life I wish I had read this book when I started getting into OO programming. This is OO to the max, at maximum granularity. Every Smalltalker should use this book as a style-guide or to help with refactoring. A Definite "Must Have", It's definitely one of those rare books that I return to over and over again... ...a classic. On the other hand, one could probably read the book without a Smalltalk background since it uses fairly simple examples. It gives clear explainations for style of codeing that is simple and understandable. Very helpful! Whatever OO-language you eventually code in. 看了这本书，我才知道什么叫做简单，什么叫做简单的美，什么才是OO。XPE和这本书是一脉相承的，KentBeck是一个真正化平淡为神奇的一代宗师。 个人观点，除了计算机科学和特定技术相关的书之外，我认为这两本书才是一个OO程序员必备的，并且是需要一遍一遍回过头来看的书。对一个程序员来说，这两本书就是春秋，其他都是释义而已。 |
| 返回顶楼 | |
|
发表时间：2004-06-03
potian:kent的书可以有电子版共享吗,
PS:不是不是想买,不过好象没有国内出版 |
| 返回顶楼 | |
|
发表时间：2004-06-03
Kent Beck的代码也很优秀，看看junit就可以看出这位高人绝对是一个又说又练的真把式。其实来自他的东西实在是太多了，模式/重构/TDD，几乎所有的热门OO技术都可以从他那里找到联系。可惜这位老兄的笔实在是不够水准，写的书虽然内容绝顶的好，但是看起来绝对的累，而TDD还算是好的。不过Smalltalk Best Practice Patterns这本书即使是用梵文写的，我也建议大家找来看看。
而C Programming Language，我想就不用我来介绍了，从它的印刷次数和册数就可以看出他的重要了。 这两本书我们看的不是技巧，不是语法，而是实实在在的思想。把思想写到这么一个实在的地步，这本身就是水平。 |
| 返回顶楼 | |
|
发表时间：2004-06-03
ozzzzzz 写道 Kent Beck的代码也很优秀，看看junit就可以看出这位高人绝对是一个又说又练的真把式。其实来自他的东西实在是太多了，模式/重构/TDD，几乎所有的热门OO技术都可以从他那里找到联系。可惜这位老兄的笔实在是不够水准，写的书虽然内容绝顶的好，但是看起来绝对的累，而TDD还算是好的。不过Smalltalk Best Practice Patterns这本书即使是用梵文写的，我也建议大家找来看看。
而C Programming Language，我想就不用我来介绍了，从它的印刷次数和册数就可以看出他的重要了。 这两本书我们看的不是技巧，不是语法，而是实实在在的思想。把思想写到这么一个实在的地步，这本身就是水平。 Small Talk的那本书，哪里可以找到呢？谢谢！ |
| 返回顶楼 | |
