反驳"软件开发中最流行的错误观点"

来自Quora的Lee Semel他列出了一些流行的错误观念,我个人认为这些错误观点反而是相对正确的,至少有一定道理,见:

● 瀑布模型是在实施软件之前最行之有效的描述系统的模型,它能帮助软件实施时循序渐进,而非循环反复。人们一直当它是一个好的实施方案,而一篇论文中恰好将它列为很差的实施方案,因此引起广泛讨论。http://en.wikipedia.org/wiki/Waterfall_model

banq:如果你非常熟悉业务,瀑布模型无疑是是最有效率,也是最见功力的,体现了几十年的老分析师相比嫩芽的最大不同。

● 用户知道他们想要什么,他们也能够将需求阐述清楚。
banq:用户确实知道他们想要什么,他们能够从不同方面将需求点点滴滴的阐述清楚,只要你善于不断沟通 倾听和深入。

● 有某种语言、技术或是流行方法将会是杀手锏,能够取代你正在使用的方法,解决你的问题。
banq:新的语言和技术方法能够带来效率和新的设计理念,与其在一个方向里艰苦斗牛较真,不如轻松重新选择一个方法,重新选择一个工具,起到事半功倍的效果,劳动并不光荣,会劳动才光荣。

● 人月神话里说,在一个开发团队中增加人手会让效率成线性增长。http://en.wikipedia.org/wiki/The_Mythical_Man-Month
banq:如果你采取DDD领域驱动设计这样新方法,那么随着项目扩大,线性增加人手,效率也是线性增长,而采取数据库驱动或脚本过程驱动则相反。

● 对规范文档的认同意味着对实际功能的认同,甚至规范文档本身写的很模糊或是有出入也要遵守规范文档。http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php
banq:没有共识,就没有统一行动,对统一模型的认同才能象灯塔一样照耀指挥群体协调前进,如同音乐指挥一样,如果规范文档表现的模型写得很模糊,表示有待确认和细化,是否与实际出入只能由重要建模人员决定,普通开发者只有认为自己理解角度或层次不够。

● 唯有一种方法能将开发实施得最好,程序员的自由被所用的语言严格束缚。
banq:一个项目中只有实施一种方法,才能将开发实施最好,多个方法会混乱脚步,就象两个人同时喊:一二一。

● 有多于一种方法来完成一个任务,程序员有完全的自由。
banq:程序员只要在确认规范文档统一模型后,有完全的自由,难道程序员在自己的技术领地也失去自由?请问谁敢剥夺?

● 设计模式是通用的,而不像某种编程语言的表达式一样有诸多限制。
banq:模式不通用,就不能称为模式,称为API。

● 最好的技术方法就是最好的方法。
banq:最好的技术方法通常代表最好的方法,否则最好的方法就无法落地,无法让人们认识到它是最好的方法。

● 你可以用正则表达式来解析HTML:http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags
banq:当然可以,替换性很强,可以定制。我就用过。

● 不需要理会市场反应,应该让市场来适应软件。
banq:如果你是乔布斯,你可以这样,在未来创新市场,都是一片空白,市场本身就为零,哪来市场反应?无生有。

● 软件可以被精确估计。
banq:如果不能被精确估计,那么就无法实现规模化生产,就如同中医,需要走另外一条思维模式了。


● 软件开发可以被当作固定价格、固定限期的项目出售。
banq:打包出售,关键在于你和购买方怎么谈判。

● 对象是对现实世界最好的描述。对象最好的应用方面便是描述真实世界中的实体。
banq:对象符合人们的直观认识,虽然很多人可能不知道那称为对象,我们可以用一个“有边界事物”抽象表达,老子道德经开篇就说:无欲观其缴(边界)

● 数据应该隐藏在对象后面,对象应提供操作数据的需要的所有方法。
banq:对于没有对象概念的人,入门这点指引约束是最起码的,这样才尊重边界的作用,否则划分边界做啥?

● JavaScript和Java有关系。
banq:当然有关系,推出Java以后,又推出JS,面向两个不同领域,从语法上都很类似,但理念不同。


● 逻辑应该和显示完全分离开。
banq:如果不完全分离,如何实现各自拓展变化?这也是遵循边界。

● 软件开发最重要的是需要好的数学能力,最好的学习方法是学习理论的计算机科学,数学能力强的也能写出好的软件。解决逻辑难题的能力是判断一个软件工程师能力在最有效方法。
banq:数学能够培养逻辑,逻辑能力是软件工程师能力最基本的能力,逻辑培养是目标,数学是通往目标的方式之一。

● 软件就是表面上看到的,设计后面发生了什么不需要引起我们的注意,尤其对于那些非技术出身的经理和客户来说更是这样。
banq:软件是一种显式化设计,作为设计师的重要职责就是将功能等进行显式化,如果对于客户看不到的,可以理解为是因为设计师没有将其进行显式,可能是有意或无意。


● 编写软件对于缺乏人际沟通能力的人来说是一个好职业。
banq:道德:以道行事;以德容人。编写软件是做事行事,如果你不愿意和人打交道,处处让人,忍受各种人性的丑陋,不如埋在代码中,体现事物之道的优美。

● 软件可以有效的用其他媒介来模拟和设计,例如wireframes或Photoshop comps,因为用实际的代码来设计(HTML和CSS)太难,太贵了。
banq注:Flash横行说明这点吧,HTML5试图统一客户端,目标很美好,途径很残酷,就像互联网并不是IT业发明的一样,想在IT技术上统一的人都是痴心梦想。

● 设计师们不能也不需要学习写代码,应该尽量远离真实的代码。
banq注:是的,避免具体代码技术对更高层面设计的影响,不要被小事累赘,要学会抽象,不抛弃对地面的贪恋,如何能够飞翔?

● 设计仅仅是表面上的装饰,其重要性没有好的开发重要。
banq注:设计是一种显式方法,横看成岭侧成峰,设计只是一层窗户纸,捅破了啥都没有。

● 软件可以基于一系列的抽象的基础之上可靠的构建,你仅需要理解最上的抽象层,而不需要了解背后的实现细节。参看Joel Spolsky关于抽象漏洞定律的讨论:http://www.joelonsoftware.com/articles/LeakyAbstractions.html
banq注:这是基本方向,从罗素悖论至今,人类在方法论上唯一一点可怜的进步就是分层。

● 当你最终发布了新的应用或是网站,就意味着一切结束了。
banq注:无为是一种目标,如果你从开始就抱着要开发出一个无需人为维护干涉的系统出来,而且意识到,很多问题都是因为Fix BUG带来的,而不是原始设计带来的,那么早点住手,也许是一种好的办法。


[该贴被admin于2012-05-02 16:07修改过]
[该贴被admin于2012-05-02 16:07修改过]

写这篇文章不是故意唱反调,而是仁者见仁,有时投票最多的观点不一定正确。大众误解比较多,或者视角不同而已。

对于现在推崇的敏捷或xp方法,我也从另外一个角度谈谈我的观点,这实际借助方法论壮胆,对于进入一个未知业务领域,就如同探险一样,一切都是为将损失降到最低,通过不断循环迭代,不断纠错,小心谨慎,无疑带来的缺点是效率不高。如果你在这个业务领域侵淫几十年,比如一直做保险行业软件,用得着这么小心吗?该吃得亏几乎都吃了,哪些实体设定几个字段都能量化,这时效率纠是追求第一了。
[该贴被banq于2012-05-03 08:50修改过]

2012-05-02 13:52 "@banq"的内容
● 设计师们不能也不需要学习写代码,应该尽量远离真实的代码。
banq注:是的,避免具体代码技术对更高层面设计的影响,不要被小事累赘,要学会抽象,不抛弃对地面的贪恋,如何能够飞翔? ...

不写代码,怎么验证你的设计行不行得通?

2012-05-03 15:21 "@chanball"的内容
不写代码,怎么验证你的设计行不行得通 ...

通过UML图等语言,设计师和程序员的区别就在这里,设计师的设计是肯定能落地成为代码,但是代码太细节会妨碍整体思路。
另外,设计师更强调逻辑性,如果在自己设计的世界中出现逻辑悖论是不可饶恕的,设计层面和代码层面是两个层面,每个层面都靠逻辑保证,代码层面由于依赖遵循逻辑的程序语言,因此不会出现大的逻辑问题,这也使程序员在使用这些语言时,好像不需要严密的逻辑。而设计师则摆脱了语言束缚,但必须自觉接受逻辑束缚。


关于这个问题进一步讨论见帖子:应用架构设计的三个类型
[该贴被banq于2012-05-17 06:46修改过]

2012-05-02 13:52 "@banq"的内容
● 用户知道他们想要什么,他们也能够将需求阐述清楚。 ...

我觉得有些时候,用户也不知道自己想要啥,或者说,他们心里只有个大概,详细的东西根本没有。开发者先做出点东西来,他们才会说“哦,这不是我要的”或者“哦,我觉得应该改成这样”等等。。。