1,265
社区成员
发帖
与我相关
我的任务
分享大胆痴说:《反传统软件工程》！
计算机从大型机时代到小型机再到微机再到移动计算，小型化是几十年来的发展趋势。
然而软件开发方法的发展却相对缓慢。从早期的手工作坊(相当于算盘时代)，到20世纪60年代出现的传统软件工程(被称为“巨型方法”，相当于大型机时代)，再到近几年兴起的全程建模、敏捷方法，同样经历着由无序到有序、由巨型到微型的发展轨迹。
但是我有一些疑问：
1。极限编程等新式方法的出现是不是就意味着软件工程方法发展的结束？是不是还会有更微型化的软件开发方法出现？
2。以UML这个符号体系为中心的面向对象分析方法是与结构化方法一起属于传统软件工程还是相反？
3。XP是“大型机”和“算盘”的折中吗？它是反传统的方法还是传统软件工程的小型化。
4、“交互设计之父”海伦·库伯认为许多软件开发失败的原因是技术与现实世界脱节造成的。UML这种符号体系是否正好和海伦·库伯的观点相抵触？
5。如果说从无论大型机还是微型机都是基于冯·诺依曼体系，那么传统软件工程和现代软件过程是否都基于某种同样的方法论？
6、从哲学意义上讲，什么样的软件工程（或曰开发模式）更接近科学的方法论，更能够提高软件开发这一思维性极强的生产的生产力？
然而软件开发方法的发展却相对缓慢。从早期的手工作坊(相当于算盘时代)，到20世纪60年代出现的传统软件工程(被称为“巨型方法”，相当于大型机时代)，再到近几年兴起的全程建模、敏捷方法，同样经历着由无序到有序、由巨型到微型的发展轨迹。
但是我有一些疑问：
1。极限编程等新式方法的出现是不是就意味着软件工程方法发展的结束？是不是还会有更微型化的软件开发方法出现？
2。以UML这个符号体系为中心的面向对象分析方法是与结构化方法一起属于传统软件工程还是相反？
3。XP是“大型机”和“算盘”的折中吗？它是反传统的方法还是传统软件工程的小型化。
4、“交互设计之父”海伦·库伯认为许多软件开发失败的原因是技术与现实世界脱节造成的。UML这种符号体系是否正好和海伦·库伯的观点相抵触？
5。如果说从无论大型机还是微型机都是基于冯·诺依曼体系，那么传统软件工程和现代软件过程是否都基于某种同样的方法论？
6、从哲学意义上讲，什么样的软件工程（或曰开发模式）更接近科学的方法论，更能够提高软件开发这一思维性极强的生产的生产力？
...全文
请发表友善的回复…
发表回复
AiWangji 2002-09-06
- 打赏
- 举报
看到你们提到了集体主义和自由主义，我也来凑一个热闹。
下面仅是我个人的观点，供大家批判。
我认为以宇宙的扩散为代表的世间万物都是在追求更大的活动
空间既自由度，那么为什么还需要约束呢？这是因为当物不具有
对自由的约束能力的话，自由会使物丧失其形态，使之不成为其物。
也就是物的消亡了。物为了维持其存在（生命）必需对自由进行
控制，但是追求自由毕竟是万物的本性。所有约束都只是为了存在，
当对自由的驾驭能力不是很强时，就需要强约束来维持其生存，
当对自由的驾驭能力变强时，约束就可以消减一点。而从总趋势
来讲我们永远是在追求对时空的最大利用，即自由。
在软件工程领域也是一样的，我们为什么需要强控制类型方法论，
是因为我们对软件开发的驾驭能力还很差，所以需要强约束，否则
软件的品质无法控制，软件就不能成为商品而存在，而当
我们对软件的认识有了提高，驾驭软件开发的能力变强时，较自由的
方法论就会激发更多的创造力，让软件在更大的空间得到发展。
下面仅是我个人的观点，供大家批判。
我认为以宇宙的扩散为代表的世间万物都是在追求更大的活动
空间既自由度，那么为什么还需要约束呢？这是因为当物不具有
对自由的约束能力的话，自由会使物丧失其形态，使之不成为其物。
也就是物的消亡了。物为了维持其存在（生命）必需对自由进行
控制，但是追求自由毕竟是万物的本性。所有约束都只是为了存在，
当对自由的驾驭能力不是很强时，就需要强约束来维持其生存，
当对自由的驾驭能力变强时，约束就可以消减一点。而从总趋势
来讲我们永远是在追求对时空的最大利用，即自由。
在软件工程领域也是一样的，我们为什么需要强控制类型方法论，
是因为我们对软件开发的驾驭能力还很差，所以需要强约束，否则
软件的品质无法控制，软件就不能成为商品而存在，而当
我们对软件的认识有了提高，驾驭软件开发的能力变强时，较自由的
方法论就会激发更多的创造力，让软件在更大的空间得到发展。
SHIZUMARU 2002-09-06
- 打赏
- 举报
关于巨型项目和一些莫名其妙不容易理解的软件工程现象，可以看看Ed Yourdon的Death March（《死亡之旅》，电子工业出版社）。这本书满有趣，我现在每天放在包里，上下班的车上看。
我不同意完全否定银弹的存在。Brooks当时说的原意是：在未来十年中，不会有任何方法使软件开发的生产率提高一个数量级，简称“没有银弹”。我有个朋友很喜欢举制药业的例子：制药业也没有找到什么“终极真理”，但他们发明了“生物导弹”，可以非常快速、低成本地做实验，从而极大地提高了生产率。软件开发既然是建立在经验和实际操作的基础上，如果有一种办法能够极大地降低做实验的时间和成本，那么也有可能成为软件业的“银弹”。
至于维特根斯坦那句话，他的意思是：我们说的话有两种，逻辑正确的和逻辑错误的。逻辑错误的是胡说八道，逻辑正确的是废话。因此在逻辑的方面，没什么可说的。不过，逻辑正确的话虽然是废话，但可以方便别人理解，因此在别人不明白的时候，是有必要说的。等别人也明白了，就会发现我们以前所说的是废话。因此，才会有这种说法。
我不同意完全否定银弹的存在。Brooks当时说的原意是：在未来十年中，不会有任何方法使软件开发的生产率提高一个数量级，简称“没有银弹”。我有个朋友很喜欢举制药业的例子：制药业也没有找到什么“终极真理”，但他们发明了“生物导弹”，可以非常快速、低成本地做实验，从而极大地提高了生产率。软件开发既然是建立在经验和实际操作的基础上，如果有一种办法能够极大地降低做实验的时间和成本，那么也有可能成为软件业的“银弹”。
至于维特根斯坦那句话，他的意思是：我们说的话有两种，逻辑正确的和逻辑错误的。逻辑错误的是胡说八道，逻辑正确的是废话。因此在逻辑的方面，没什么可说的。不过，逻辑正确的话虽然是废话，但可以方便别人理解，因此在别人不明白的时候，是有必要说的。等别人也明白了，就会发现我们以前所说的是废话。因此，才会有这种说法。
AiWangji 2002-09-06
- 打赏
- 举报
是的，自由是有条件的，没有控制的自由必然导致失控。
从这一个意义上讲，自由离不开每一个个体的强控制能力的。
当大多数的个体的控制能力不够强大时，就需要借助整体的控制
力量来维持其存在，否则就要消亡（既不能维持其稳定的形态）。
而随着个体的控制能力（能量）都得到加强时整体的控制就会成为
其向新空间发展的阻碍，随着其中个体的能量的增强，如果整体的
控制力量不加以释放的话就会发生聚变。
从这一个意义上讲，自由离不开每一个个体的强控制能力的。
当大多数的个体的控制能力不够强大时，就需要借助整体的控制
力量来维持其存在，否则就要消亡（既不能维持其稳定的形态）。
而随着个体的控制能力（能量）都得到加强时整体的控制就会成为
其向新空间发展的阻碍，随着其中个体的能量的增强，如果整体的
控制力量不加以释放的话就会发生聚变。
SHIZUMARU 2002-09-05
- 打赏
- 举报
to o6z：
严重同意你对重构的看法。在主流语言无法提供self-specify的时候，重构可以极大地帮助提高代码的可读性。
如果你有空，倒是可以看看Eiffel（http://www.eiffel.com），当然看OOSC（Object-Oriented Software Construction 2nd Edition，清华大学出版社）里面讲Design by Contract那一章也行。也许DBC离self-specify还有一定的距离，但是确实已经在Eiffel上获得了相当的成功，并且，“与思维方式的距离”没有想象中的那么大。稍微习惯了Eiffel的语法之后，就会觉得Design by Contract真是满好的，避免了以前OO过程中许多不必要的人与人之间交流造成的问题。
to 楼主：
SE方法从巨型到微型，我想主要还是因为应用的场合变了。以前的软件都是军方大型项目，需求极少变化，资源又丰富，所以巨型方法会很合适；现在的软件都是民用项目，规模越来越小，需求变化越来越多，对资源的要求越来越高，所以适应变化的微型方法比较合适。我一直认为：SE方法对软件开发的前瞻性的指导意义并不大，对应不同的应用会有不同的SE方法，环境一变方法也变，对于别人恐怕不太有借鉴价值。
如果要说哲学，结构化方法需要一个主控模块，比较像集体主义（注：是指哈耶克在《通往奴役之路》中所说的“集体主义”）；OO方法将责任划分给小模块，由一只“看不见的手”来使它们合作，比较像自由主义。至于SE过程，我觉得也是有这两种划分的。高展先生最近常常抨击OO方法，看他的SE过程却是以结构化的过程做OO软件——哈耶克在《通往奴役之路》中说到：计划与自由，没有一种折中的选择；如果把两者混合在一起，得到的将是最坏的结果。
至于哪种方式更科学、更提高生产力，很难说。Brooks说“没有银弹”，我们甚至没有看清楚银弹存在的可能性。借用维特根斯坦的一句话：凡不可言说者，必保持沉默。
严重同意你对重构的看法。在主流语言无法提供self-specify的时候，重构可以极大地帮助提高代码的可读性。
如果你有空，倒是可以看看Eiffel（http://www.eiffel.com），当然看OOSC（Object-Oriented Software Construction 2nd Edition，清华大学出版社）里面讲Design by Contract那一章也行。也许DBC离self-specify还有一定的距离，但是确实已经在Eiffel上获得了相当的成功，并且，“与思维方式的距离”没有想象中的那么大。稍微习惯了Eiffel的语法之后，就会觉得Design by Contract真是满好的，避免了以前OO过程中许多不必要的人与人之间交流造成的问题。
to 楼主：
SE方法从巨型到微型，我想主要还是因为应用的场合变了。以前的软件都是军方大型项目，需求极少变化，资源又丰富，所以巨型方法会很合适；现在的软件都是民用项目，规模越来越小，需求变化越来越多，对资源的要求越来越高，所以适应变化的微型方法比较合适。我一直认为：SE方法对软件开发的前瞻性的指导意义并不大，对应不同的应用会有不同的SE方法，环境一变方法也变，对于别人恐怕不太有借鉴价值。
如果要说哲学，结构化方法需要一个主控模块，比较像集体主义（注：是指哈耶克在《通往奴役之路》中所说的“集体主义”）；OO方法将责任划分给小模块，由一只“看不见的手”来使它们合作，比较像自由主义。至于SE过程，我觉得也是有这两种划分的。高展先生最近常常抨击OO方法，看他的SE过程却是以结构化的过程做OO软件——哈耶克在《通往奴役之路》中说到：计划与自由，没有一种折中的选择；如果把两者混合在一起，得到的将是最坏的结果。
至于哪种方式更科学、更提高生产力，很难说。Brooks说“没有银弹”，我们甚至没有看清楚银弹存在的可能性。借用维特根斯坦的一句话：凡不可言说者，必保持沉默。
ozzzzzz 2002-09-05
- 打赏
- 举报
SHIZUMARU(绯雨闲丸)
高展先生很厉害 厉害到我们都不知道他要做什么 关于所谓集体主义和自由主义的问题 这个比喻很形象 看书的时候我怎么没有想到 ：）
不过我感觉 其实所谓巨型的方法即使在现在地军事应用也是很有风险的 首先我不能想象一个数百人的程序组共同开发一个程序 应该说SE很多已有资料都清楚表明 增加人员无助于质量和开发速度的提高 而其主要开发人员的责任过分集中 而且我想大多数人都会承认一个看起来合理的设计在实现的时候未必就合理 而巨型方法对小版本（也就是多次小迭代的支持很有问题） 而且巨型方法的唯一优势就是可以很清楚地划分责任（当然这也是相对的）和对过程的严格控制符合（当然是看起来像）大多数管理者的胃口 且大量的文档使那些不懂技术又没有时间去听取开发者的意见的人感到可信（当然是建立在一种错觉上的） 二者都是符合一些传统的组织的管理理念和文化 哈哈 说了巨型方法一大堆坏话
我个人从自己的经验和调查的一些情况来看 似乎一个开发组最大的规模不超过20人为好 注意这里的20人是指coding的人员 不包括测试和辅助人员 在10左右往往效果最好 如果可以把一个大型的项目合理划分成一些符合这样小组开发的模块 我看会好的多 这也是我们大家经常做的 但是这也需要很大的设计的经验和管理协调能力 所以从这个方面来说 楼主的想法是很好的 但是还有很多的路要走 而如果采取敏捷的作最小可使用版本 不断地增加应用的方法似乎更加合适 也就是最开始只有一个小组最最基本的版本的开发 然后不断地增加小组最重构和增加特性的开发 这样似乎更加合理一些 当然这只是我的一个设想
SE是方法学 当然只能是建立在经验和实际操作的基础上的 所以我看只能是短视的
没有银弹 不可能有 现在没有以后也不会有 但是银钳子回有 呵呵 《重构 完善代码设计》中就说重构是
但是我不同意：凡不可言说者，必保持沉默。 如果那样我们还在这里说什么：）
哈哈 似乎敏捷的方法更加原始 所以要说传统 xp最传统 有点文物的感觉了
高展先生很厉害 厉害到我们都不知道他要做什么 关于所谓集体主义和自由主义的问题 这个比喻很形象 看书的时候我怎么没有想到 ：）
不过我感觉 其实所谓巨型的方法即使在现在地军事应用也是很有风险的 首先我不能想象一个数百人的程序组共同开发一个程序 应该说SE很多已有资料都清楚表明 增加人员无助于质量和开发速度的提高 而其主要开发人员的责任过分集中 而且我想大多数人都会承认一个看起来合理的设计在实现的时候未必就合理 而巨型方法对小版本（也就是多次小迭代的支持很有问题） 而且巨型方法的唯一优势就是可以很清楚地划分责任（当然这也是相对的）和对过程的严格控制符合（当然是看起来像）大多数管理者的胃口 且大量的文档使那些不懂技术又没有时间去听取开发者的意见的人感到可信（当然是建立在一种错觉上的） 二者都是符合一些传统的组织的管理理念和文化 哈哈 说了巨型方法一大堆坏话
我个人从自己的经验和调查的一些情况来看 似乎一个开发组最大的规模不超过20人为好 注意这里的20人是指coding的人员 不包括测试和辅助人员 在10左右往往效果最好 如果可以把一个大型的项目合理划分成一些符合这样小组开发的模块 我看会好的多 这也是我们大家经常做的 但是这也需要很大的设计的经验和管理协调能力 所以从这个方面来说 楼主的想法是很好的 但是还有很多的路要走 而如果采取敏捷的作最小可使用版本 不断地增加应用的方法似乎更加合适 也就是最开始只有一个小组最最基本的版本的开发 然后不断地增加小组最重构和增加特性的开发 这样似乎更加合理一些 当然这只是我的一个设想
SE是方法学 当然只能是建立在经验和实际操作的基础上的 所以我看只能是短视的
没有银弹 不可能有 现在没有以后也不会有 但是银钳子回有 呵呵 《重构 完善代码设计》中就说重构是
但是我不同意：凡不可言说者，必保持沉默。 如果那样我们还在这里说什么：）
哈哈 似乎敏捷的方法更加原始 所以要说传统 xp最传统 有点文物的感觉了
SHIZUMARU 2002-09-04
- 打赏
- 举报
严重同意o6z关于重构的建议。
我始终认为：文档应该是给程序员之外的人看的。在程序员之间，多一份文档就跟多一份重复代码一样，只会造成混淆。o6z有没有看过裘宗燕翻译的《从规范出发的程序设计》？从最初的客户需求开始，逐渐精化直到生成最后的代码之前，中间所有的东西都叫做“程序”——我们的所谓“开发文档”也就是这种东西吧？如果你要求程序员同时看两个东西（代码和文档），又怎么能要求他们出错的几率不提高呢？
说到这里，必须指出：传统的OO有着一个巨大的缺陷。o6z很了解重构，应该知道：我们需要给每个单元（包括类、方法、参数……）起一个好的、一目了然的名字，让使用者能够从这个名字直接地看出这个单元的用途，也就是所谓的“self-document”的代码。但是你不觉得这很可笑吗？我觉得，这样的要求实在太感性了，可以是一种不错的经验，无法成为一种科学的方法。
在程序单元和单元的使用者之间，应该有一种严格的规范限制。每个程序单元必定有一个前条件（precondition）和一个后条件（postcondition），但在传统OO语言（例如C++、JAVA、smalltalk）中，前条件和后条件是依靠程序员的“自觉”来保证的。OO方法的不成功，恐怕与此大有关系。我觉得，OO程序不但要“self-document”，而且还要“self-specify”，用代码本身来强制保证前条件和后条件。不然，OO软件的可靠性永远都没有保证，永远都只能靠程序员的“自觉性”——无论什么事情，一旦要依赖于人的自觉性，我都会不相信它。
在保证前条件和后条件的实践方面，Design by Contract是一个很好的尝试。我记得3nt对Eiffel有兴趣，o6z你有没有研究这方面？
我始终认为：文档应该是给程序员之外的人看的。在程序员之间，多一份文档就跟多一份重复代码一样，只会造成混淆。o6z有没有看过裘宗燕翻译的《从规范出发的程序设计》？从最初的客户需求开始，逐渐精化直到生成最后的代码之前，中间所有的东西都叫做“程序”——我们的所谓“开发文档”也就是这种东西吧？如果你要求程序员同时看两个东西（代码和文档），又怎么能要求他们出错的几率不提高呢？
说到这里，必须指出：传统的OO有着一个巨大的缺陷。o6z很了解重构，应该知道：我们需要给每个单元（包括类、方法、参数……）起一个好的、一目了然的名字，让使用者能够从这个名字直接地看出这个单元的用途，也就是所谓的“self-document”的代码。但是你不觉得这很可笑吗？我觉得，这样的要求实在太感性了，可以是一种不错的经验，无法成为一种科学的方法。
在程序单元和单元的使用者之间，应该有一种严格的规范限制。每个程序单元必定有一个前条件（precondition）和一个后条件（postcondition），但在传统OO语言（例如C++、JAVA、smalltalk）中，前条件和后条件是依靠程序员的“自觉”来保证的。OO方法的不成功，恐怕与此大有关系。我觉得，OO程序不但要“self-document”，而且还要“self-specify”，用代码本身来强制保证前条件和后条件。不然，OO软件的可靠性永远都没有保证，永远都只能靠程序员的“自觉性”——无论什么事情，一旦要依赖于人的自觉性，我都会不相信它。
在保证前条件和后条件的实践方面，Design by Contract是一个很好的尝试。我记得3nt对Eiffel有兴趣，o6z你有没有研究这方面？
ilang 2002-09-04
- 打赏
- 举报
关注
ozzzzzz 2002-09-04
- 打赏
- 举报
SHIZUMARU(绯雨闲丸)
抱歉 我对Eiffel没有什么研究 但是对于你说的self-document我认为最成功的是ADA 哈哈 毕竟花了那么多钱 但是我感觉self-specify可能会很难实现 到不是这样的语言不能设计出来 而是self-specify和我们使用的自然语言相差太多 也就是和我们的思维方式有距离 但是作为一种思想self-specify是绝对应该追求的 还有我觉得如果要self-specify 付出的代价是不是很大 这也是我们应该考虑的问题 我觉得现在做到self-document就很不错了（当然是注意成本的基础上 那些100行的注释 说明一行代码的情况 本身就说明 代码自身有问题 而不使用注释 让self-document才是真正的self-document 但是这也有成本问题）而重构是走向self-document一致于self-specify一个很好的途径
抱歉 我对Eiffel没有什么研究 但是对于你说的self-document我认为最成功的是ADA 哈哈 毕竟花了那么多钱 但是我感觉self-specify可能会很难实现 到不是这样的语言不能设计出来 而是self-specify和我们使用的自然语言相差太多 也就是和我们的思维方式有距离 但是作为一种思想self-specify是绝对应该追求的 还有我觉得如果要self-specify 付出的代价是不是很大 这也是我们应该考虑的问题 我觉得现在做到self-document就很不错了（当然是注意成本的基础上 那些100行的注释 说明一行代码的情况 本身就说明 代码自身有问题 而不使用注释 让self-document才是真正的self-document 但是这也有成本问题）而重构是走向self-document一致于self-specify一个很好的途径
netsong 2002-09-04
- 打赏
- 举报
好像离题了
ozzzzzz 2002-09-03
- 打赏
- 举报
mach(照虎画猫)
如果你是在MIS这样的商业领域 我看你应该有办法 我说的工具不是你说的rose之类的东西 我是只像重构这样的方法 其实看代码也是要方法的 你必须有一种看代码的方法 这个事情在国内至少很重要 你如何强调文档 也只能是为以后作打算 现在你遇到的就是没有文档 而且我也遇到过有文档 你也没有办法下手的情况 在国内这个不是危言耸听 我相信你也会同意这一点 如果你还不明白重构 那就只好自己画uml图 自己分解功能了 虽然这样很慢 但是也没有别的办法 不行就从头设计 从新开始 特别是MIS这类东西 用pd之类的很快就可以成型
工具一定要有 必要的时候只能自己创造符合自己要求的工具 注意不是rose这类东西 如果原始的代码设计有问题 你用rose之类导出的类图 一样是混乱无比 所以它们是不会帮助你的 而这个时候你只能用重构这类的工具 虽然你可能对xp感到很不喜欢 但是我希望你还是应该去学习重构和CRC卡这两个东西使用的方法 他们应该是属于大家的
如果你不知道什么是重构 你可以去umlchina那里下载refactoring这部书来看看 很有意思的东西 这个东西有点复杂 但是很有用 特别是对于理解别人的代码
如果你是在MIS这样的商业领域 我看你应该有办法 我说的工具不是你说的rose之类的东西 我是只像重构这样的方法 其实看代码也是要方法的 你必须有一种看代码的方法 这个事情在国内至少很重要 你如何强调文档 也只能是为以后作打算 现在你遇到的就是没有文档 而且我也遇到过有文档 你也没有办法下手的情况 在国内这个不是危言耸听 我相信你也会同意这一点 如果你还不明白重构 那就只好自己画uml图 自己分解功能了 虽然这样很慢 但是也没有别的办法 不行就从头设计 从新开始 特别是MIS这类东西 用pd之类的很快就可以成型
工具一定要有 必要的时候只能自己创造符合自己要求的工具 注意不是rose这类东西 如果原始的代码设计有问题 你用rose之类导出的类图 一样是混乱无比 所以它们是不会帮助你的 而这个时候你只能用重构这类的工具 虽然你可能对xp感到很不喜欢 但是我希望你还是应该去学习重构和CRC卡这两个东西使用的方法 他们应该是属于大家的
如果你不知道什么是重构 你可以去umlchina那里下载refactoring这部书来看看 很有意思的东西 这个东西有点复杂 但是很有用 特别是对于理解别人的代码
Go_Rush 2002-09-03
- 打赏
- 举报
...
mach 2002-09-03
- 打赏
- 举报
ozzzzzz(希望敏捷)
谢谢你的建议。
谢谢你的建议。
ozzzzzz 2002-09-03
- 打赏
- 举报
mach
CRC卡是很好的东西 作文档都可以
但是我感觉你对重构不是很了解 我劝大家都应该学学重构 只要你的程序是oop的 那么就可以用重构来阅读
CRC卡是很好的东西 作文档都可以
但是我感觉你对重构不是很了解 我劝大家都应该学学重构 只要你的程序是oop的 那么就可以用重构来阅读
mach 2002-09-03
- 打赏
- 举报
重构和CRC对我来说都不是陌生的概念，CRC的基础是oo，如果面对的不是oo的代码就不好使了。
不幸的是，我们做的不是mis，是比较新的金融业务，国内银行界懂这个的都不多，更别说搞IT的了。更不幸的是，我们做二次开发，而原来的产品开发得实在太差，业务逻辑迷失在几十万行代码里了。
同意你说的“而且我也遇到过有文档 你也没有办法下手的情况”
不幸的是，我们做的不是mis，是比较新的金融业务，国内银行界懂这个的都不多，更别说搞IT的了。更不幸的是，我们做二次开发，而原来的产品开发得实在太差，业务逻辑迷失在几十万行代码里了。
同意你说的“而且我也遇到过有文档 你也没有办法下手的情况”
gdsean 2002-09-02
- 打赏
- 举报
2 ozzzzzz(希望敏捷):
要想重用软件文档是必须的。你当然可以写出很不错的代码，我听过一句话：蠢人写的代码给机器读，聪明人写的代码是给人读的。我也觉得注释没有什么必要，除了一些人为定义的final常量代表什么意义。但是注释不等于文档，注释可以不要，文档还是必须存在，起码每个API定义是出于什么想法应该写出来。个人看法
要想重用软件文档是必须的。你当然可以写出很不错的代码，我听过一句话：蠢人写的代码给机器读，聪明人写的代码是给人读的。我也觉得注释没有什么必要，除了一些人为定义的final常量代表什么意义。但是注释不等于文档，注释可以不要，文档还是必须存在，起码每个API定义是出于什么想法应该写出来。个人看法
ozzzzzz 2002-09-02
- 打赏
- 举报
mach(照虎画猫)
哈哈 我告诉你 我只崩溃过一次 那是我在看到那么多正规的文档的时候
关键是你有没有合适的工具 文档也是一种工具 而且最重要的不是文档 而是你原来的code设计是不是良好 书写清晰 这就像我很许多人说 好的代码不需要做注解一样 很多人不理解 你知道重构吗 如果你在为这个问题而苦恼 劝你去学习一下 关键不是文档 如果设计的不好 文档再多 你对code再理解 你一样会崩溃
哈哈 我告诉你 我只崩溃过一次 那是我在看到那么多正规的文档的时候
关键是你有没有合适的工具 文档也是一种工具 而且最重要的不是文档 而是你原来的code设计是不是良好 书写清晰 这就像我很许多人说 好的代码不需要做注解一样 很多人不理解 你知道重构吗 如果你在为这个问题而苦恼 劝你去学习一下 关键不是文档 如果设计的不好 文档再多 你对code再理解 你一样会崩溃
eastsun 2002-09-02
- 打赏
- 举报
up.
eastsun 2002-09-02
- 打赏
- 举报
如果是确定性算法，用UML或者ER关系图等工具。
如果是非确定性算法。那恭喜你了。你得看看达尔文、孟德尔的著作了。还得有耐心。最后，有评价鲁棒性的方法。没有什么确定好的方法。
c_antinomy 2002-09-02
- 打赏
- 举报
说半天不是工具就是方法，说到底都只起辅助作用。无论那一领域，理解问题才是
关键，这一点做不到，一切工具方法都白搭。想只靠方法工具就像做出结构良好的
软件无异于痴人说梦。问题理解了，再谈工具方法吧！
照我看最好的工具是笔与纸，最好的方法是交流，深入学习问题领域的知识。
关键，这一点做不到，一切工具方法都白搭。想只靠方法工具就像做出结构良好的
软件无异于痴人说梦。问题理解了，再谈工具方法吧！
照我看最好的工具是笔与纸，最好的方法是交流，深入学习问题领域的知识。
mach 2002-09-02
- 打赏
- 举报
ozzzzzz(希望敏捷)
呵呵，老兄你总是长篇大论的。
至于文档，的确没必要那么八股，写文档的目的是沟通。其实CMM关注也不是文档，而是过程的持续改进。
有的时候并不是“我们一看就对程序的基本流程有大概的了解”，很不幸我目前的项目就是这样，程序很庞大，但是没有任何文档，试图从code中找出逻辑的努力都失败了。“ 你如果只是看代码 会很累 用用工具吧”我们尝试了rose和together，生成的模型同样无法达到理解的目的。
“可能我这个反对文档的家伙做的文档比你还多 还详细 ”我可是作过不少文档的：），不过里面有一些的确不必要，不过那也不是我要作的。
“还有我也很不喜欢你的写作文档的方式”什么方式？
其实我并没有非常有意识地进行过重构，但是我见过许多软件熵达到一定高度只能重写的例子。
Javadoc当然用过，效果不是很理想，很多程序员的表达能力不是非常出色的，他们写的注释有时可能只有自己能看懂。
呵呵，老兄你总是长篇大论的。
至于文档，的确没必要那么八股，写文档的目的是沟通。其实CMM关注也不是文档，而是过程的持续改进。
有的时候并不是“我们一看就对程序的基本流程有大概的了解”，很不幸我目前的项目就是这样，程序很庞大，但是没有任何文档，试图从code中找出逻辑的努力都失败了。“ 你如果只是看代码 会很累 用用工具吧”我们尝试了rose和together，生成的模型同样无法达到理解的目的。
“可能我这个反对文档的家伙做的文档比你还多 还详细 ”我可是作过不少文档的：），不过里面有一些的确不必要，不过那也不是我要作的。
“还有我也很不喜欢你的写作文档的方式”什么方式？
其实我并没有非常有意识地进行过重构，但是我见过许多软件熵达到一定高度只能重写的例子。
Javadoc当然用过，效果不是很理想，很多程序员的表达能力不是非常出色的，他们写的注释有时可能只有自己能看懂。
加载更多回复（15）
