Browsed by
标签: 软件开发

Kent Beck 谈单元测试和持续部署

Kent Beck 谈单元测试和持续部署

文章来源

2010年7月2日,Roy Osherove 和 Kent Beck 在 blog.typemock.com 进行了一次对话,话题涉及单元测试(Unit Testing),JUnit Max(Kent 开发的一个单元测试的 Eclipse Plugin,不免费),和面向初创企业的精益方法(Lean Startups)。

单元测试和 JUnit Max
作为软件开发方法学的大师、极限编程XP的创始人、敏捷宣言的创始人之一,Kent Beck 一直在努力最大化地利用单元测试的价值,他说一些程序员仍然认为单元测试并不是他们的工作,但是单元测试确实能够提高软件的质量。目前他正在开发 JUnit Max,这是一个 Eclipse plugin,每当程序员保存一个 Java 源文件的时候,JUnit Max 就会运行测试并报告反馈信息。测试中的错误将会如同编译错误一样被报告给程序员。JUnit Max 的核心思想是测试错误应该和编译错误一样被 IDE 报告给程序员,程序员不需要额外的菜单选项或者运行其他的工具来运行测试。特别是那些经常失败的测试,对于程序员来说是非常有价值的反馈信息。在测试驱动开发(Test Driven Development – TDD)中,我们重复着这样一个循环:“编写一个‘失败’的测试(Failing Test)” – “编码实现功能以便让测试通过”,随着开发的深入,测试越来越丰富,测试能够反馈给程序员的信息也越来越多,它们可以帮助程序员找出那些需要改进的代码。JUnit Max 能够缩短这个循环的周期,因为它更为频繁地运行测试和提供反馈。Roy 问道:“当你一个人编码的时候,你是否严格地遵循 TDD,即一定要先写测试,然后写实现代码。我个人发现这并不是一件容易做到的事情,特别是当一个人编码的时候。” Kent 回答:“视情况而定,有时候并不需要死板地遵循 TDD,比如当我在做一些探索性或者说实验性的编码时,并不需要写测试,因为我只是想尝试一下某些功能和特性。”

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (12 人打了分,平均分: 3.50 )
Loading...
参透软件开发的本质 – Uncle Bob Martin 推荐的经典书籍

参透软件开发的本质 – Uncle Bob Martin 推荐的经典书籍

数量级25(10^25)是 Uncle Bob 在 RailsConf 演讲的主题。如果你用一台 PDP 8( 1960年代的计算机)和 Mac PowerBook 做比较的话,你会发现 Mac PowerBook 比 PDP 8 快8000倍,有6百万倍大的内存,11000倍的耗能,1500倍的容量等等。如果将这些0累加起来,很容易达到10^25。在过去40年里,我们的硬件计算能力获得了10^25倍的提升,而作为软件开发人员的我们并没有利用这些计算能力来提升多少我们的软件开发能力。没错,我们是写了不少的代码,但是它们基本上都是一些顺序语句,if 语句,和 while 循环等,没有什么新鲜的东西。你可能会说面向对象是新东西呀,但是那只是另外一种组织顺序、选择和迭代等语句的方法而已。除我们现有的编程语言之外,如果有新的编程语言能够产生并创造新的“微积分学”,从而将软件开发提高到一个新的高度,将会是一件非常令人期待的事情,因为顺序语句,选择语句和迭代等最终将成为历史。

Uncle Bob 认为以下四本书是软件开发人员必须阅读的,并由他自己来排名。

1. The Structure & Interpretation of Computer Programs 计算机程序的构造和解释 (By Harold Abelson & Gerald Sussman)

书中使用的是 Scheme 语言(Lisp 的一个变种),此书的内容曾经是 MIT 计算机系的一门课程,当然现在已经不是了。

2. Structured Programming 结构化程序设计 (By Edsger W. Dijkstra)

相信软件专业的同学们都上过此课程,我们的启蒙书籍。这本书讨论了 go to 是怎样的邪恶,同时也讨论了面向对象。对比一下今天我们视为 best practice 的测试驱动开发(TDD),go to 在过去也曾经是 Fortran,Cobol 等语言的核心。

3. The Annotated TURING (By Charles Petzold)

Uncle Bob 令人尴尬地忘记了这本书的名字,他自嘲说自己从来记不住这本书名。但是此书在他的推荐列表中列第三位。

4. Clean Code (By Robert C. Martin)

Uncle Bob 本人的大作。

我的一位同事将这位 Uncle Bob 视为软件开发领域中的上帝,Uncle Bob 这位大师在当下各类编程语言和平台层出不穷的时候,在我们为该学什么语言买什么书举棋不定的时候,推荐给读者这几本经典,也许是煞费苦心地想让我们参透软件开发的本质吧。不过会不会也是因为我们都在慢慢变老,许多旧的东西如今又变成了新鲜有趣的事情啦?(出自采访记者之口)

文章来源

好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 3.60 )
Loading...
Richard Feynman, 挑战者号, 软件工程

Richard Feynman, 挑战者号, 软件工程

源文:链接  (本文主要根据挑战者号的问题,以及Richard Feynman那对NASA严厉的批评报告,批评了不适当的“自顶向下”的设计方法,并总结了一下软件工程和其它工程的相通的一些观点。翻译水平有限,欢迎指正)

Challenger Crew

佛罗里达州,美国东部时间1986年1月28日上午11时39分,挑战者号航天飞机 执行为期6天的STS-51-L 任务,在发射后,其右侧固体火箭助推器(SRB – Solid Rocket Booster)的O型环密封圈(用于连接两节助推器)失效,泄漏出来的热汽达到了5000华氏度,直接蒸发了O型密封圈,并灼烧了毗邻的外部燃料舱,在几秒钟内,外部燃料舱出现结构连接失效,空气的动力迅速分解了航天飞机。在而航天飞机上升72秒以后,助推器脱落,导致航天发飞向侧面滑出。几乎在引航员 Michael J. Smith 发出”Uh oh” 的同时,整个航天飞机完全解体,片刻,航天飞机内部发生爆炸,所有7名宇航员罹难。 那时的我还只是一个小孩,我从电视下方滚动的新闻条目知道了这一惨剧。

在那个时候,火箭助推器工程师曾经警告过这个O型环可能存在问题,但可惜的是,NASA的管理层忽略了这个问题。Challenger Explosion美国总统里根委派罗杰斯委员会对事故进行了调查,调查成员包括著名的物理学家Richard Feynman。其不羁的态度和直来直去的方法和罗杰斯委员会的风格形成了鲜明的反差。主席罗杰斯,一个政客,评论Feynman是一个“真正的痛苦”。最后,在委员会提交的报告中,Feynman反判的观点几乎被清除了出去。并且,Feynman曾被主席威胁过要把他的名字从报告中完全除掉,但最终,他们还是同意在报告中加一个附录,但只是个人观点—— Appendix F – Personal Observations on Reliability of Shuttle

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 4.00 )
Loading...
怎样做一个 Program Manager

怎样做一个 Program Manager

我个人认为,这是一篇不错的文章,虽然我不是Program Mananger,但是我几乎在做着和这个职位很相似的工作。在这里,我把这篇文章推荐给所有的程序员,我相信,这篇文章会让你明白,只有技术是远远不够的,因为没有Program Manager这个角色,程序员们只不过一些手中拿着利器却不知所措的散兵游勇。我希望我的导读和原文能给所有的程序带来启示。

原文在这里:
“How to be a program manager”
http://www.joelonsoftware.com/items/2009/03/09.html

09meeting-thumbnail这篇文章的作者叫Joel Spolsky,在Microsoft做过Program Manager,这篇文章非常值得一读。下面是我给大家做的一个导读:

首先,他讲了两个人,一个是负责WYSIWYG 字处理的天才级的Program Manager——Charles Simonyi,第二个是上世纪80年代的负责Mac OS上的Excel项目的程序员Jabe Blumenthal,他发现了程序员和市场人员的代沟,Marketing的人很难通过把MBA-Speaking翻译成实际的Feature,并且,有太多的和编码不相关的工作,比如说,和用户交谈,运行usability测试,Reivew竞争者的产品,并且得冥思苦想怎么能让事情变得更简单,而我们的程序员通常来说即不具备这样的时间,也不具备这样的能力。于是,Jabe开始了他的Program Manager的生涯。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (6 人打了分,平均分: 2.33 )
Loading...