本文是一篇风格轻松的概述Scala语言诞生过程中的各种软件开发运动历史事件的文章。

About the Blogger

agile software development

在文章 Don’t do XP 里, Tobias Mayer 建议人们不要去搞极限编程(XP)。 我和Tobias相知已久，我想他这个问题上错了。 我不知道他在跟谁争论，但他们的有些争论就是“嚼舌根”。我想如果他曾经试过一次XP，那他的言论会更有说服力。 XP并不是一个万能的解决方案，但它确实是一种方案，而且我们知道如何使用它。

作为一个临时的XP支持者，我并不抱怨 “在软件工业中Scrum没有提供很好的开发原则”，我只抱怨这个产业。 如果我们能在这个产业里有效率的工作，那我们也就不会有这场关于方法论的战争了，因为我们的目地就是出产品。 如今当人们把Scrum概念应用到这个产业时，Scrum也不幸被人们使用的混乱不堪。 另一方面，责备XP阻碍了实施方法的进步显然有些牵强。

XP是一种很小的运动，只吸引了一部分人的目光。 XP（第一版）所实现的成果是让大家知道解决一直困扰很多开发团队的无法负担开发工期压力的问题是有办法解决的，而且是在不须求助高人协助的情况下。 它提供了我一套好的实践方法让我们在开发中使用。 当然了， XP 并不能解决世界上的所有问题 ，它并不是对每个人都适用，至少一个原因是你必须对它有相当的认识和研究，这是一般的团队所不具备的。 Kent beck所论述的第一版XP极具有针对性：它的设计目标是让我们控制混乱，拓宽我们软件开发的思路，重新制定研讨框架。

我 想Tobias似乎已经忘了这十年来发生的事情。 其实我们所处的完全是一个理论性的运动，因为XP把推迟代码实现作为论述的中心—— 只需看看与此相关的人，他们是相同的一群人。 他似乎也忘了众多的XP实施建议直接和我们的直观感觉有冲突，特别是和当前的产业发展方向有冲突。

Tobias说这些优秀的开发实施意见传播的如此缓慢，而我要说的是，没有XP，我们估计仍在原地等待。 测试驱动开发一直没有被广泛的接受，甚至连最初的C3小组也没有完全的接受它——直到有一天Kent写出了这本书。 持续反省理论有一小群学院派的人追随，但是这种理论的实践如果没有TDD很好的支持会存在一定的风险情。 我怀疑大多数的团队仍旧不愿轻易重整代码，除非要添加新的功能。 结队编程方式也在滞销，同样，这种方式在TDD的环境中发挥的会更好。 我知道有相当多的Scrum团队都没有找到一套系统的方法理论。 如果说他们需要改进Scrum的实施方法，这是把问题归咎于他们如何使用Scrum和他们的自我组织问题。

最的的一点挑剔。 XP的论著有二版，第二版发布不是很久远，而且里面提到的方法论更加“柔和”。 与这些实践理论相关的一件事情：C3 项目组是在 (Smalltalk/Gemstone) 这样的环境中工作的，落后于大多数我们今天使用的环境。 XP社团里的很多工作都是在增加XP的灵活性，让它能在新的开发环境中使用。 真正让人恐怖的事是这个产业缓慢的发展速度。

英文原文：Do do XP

Steve Freeman 写了一篇 blog Do do XP 来反驳我的这篇文章。

我开始厌倦了和那些坚持认为Scrum离开了极限编程就不再有价值的人的无休止的论战。 Scrum 很好用 — 但前提是实施者必须从基础上理解它的价值所在和实施原则。 你应用Scrum所处的环境条件决定了你在实施过程中应该采取哪些措施。 比如，在教堂里实施Scrum和在软件开发中实施Scrum有着不同的一套实施策略。而这两种情况下的实施措施又和传统的Scrum有不同之处。

极限编程的拥护者动不动就抱怨在软件工业中Scrum没有提供很好的开发原则。 但就目前极限编程被业界采纳的缓慢进度来看，真正应该受责备应是XP的缺少实践措施的问题，XP应该为这种状况负责。

从八十年代到九十年代，随着开发语言的进步和更适合于软件设计，人们开发和测试的方式发生了改变。 在广大的面向对象群体中，有些概念正在缓慢的、但广泛的被人们所接受。例如持续反省、限制责任、测试代码优先（TDD）、持续集成、推迟设计、编码规范、以及结对编程等。 所谓的极限编程 (Kent Beck和他的一些同事所做的) 也就是将所有的这些好的实践方法集中到一起打成一个包，再加上Jeff Sutherland 1993年在Easel公司实践出的Scrum模式。 某种意义上说，这也就有抽象Scrum概念的第一次具体的实现。

这些都很成功。 然而他们的这些实践经验的推广和采纳并没有像他们想象的那样进行。 也许就是因为取了个极限编程的错误名称； 也许是因为主要的、嗓门最大的拥护者非要说这是唯一真理的原因； 也许是因为管理者恐惧这个新出现的异类，暗中作梗反对它； 也许是因为，说到底，XP也不过是另一种开发方法。 我不知道。 我只知道，只有很少的开发团队宣称和承认采用了XP。

然而与此同时，Scrum正在获得强大的发展动力。 并不需要多少华丽的理由，实际情况却是Scrum正在被为数不少的团队接受，正在用它来改进我们软件的开发过程。 反而是XP现在想来分一杯羹。 他们确实很饥饿。

首先，让我把问题说明白。 我十分赞同软件开发团队采用一些已知的实践指导来提高代码质量、生产更高水平的软件作品。 但为什么这么多人不愿意这么做？ 我不太喜欢把十几个任务打个包直接丢给团队，也不喜欢事先指定一种开发方法让他们必须遵守。 那样做很显然违反了“people over process”和自我管理原则。 在好的Scrum实施里，团队成员应根据自身情况找到适合自身的实施策略，这样的Scrum应用过程才是与实际相结合、才有意义。 这才是我追求的进步。 有些Scrum团队一直没有找到很满意的开发方法，这说明Scrum实施方式需要改进，而不是去告诉团队成员强制实施。

我有一个问题思考：如果XP从来没诞生过，有多少团队愿意完全接受所有XP所推荐的方法？ 我相信会有很多。 我相信这些宝贵的开发经验会自然而然的被程序员和团队们采用，对我来说，关心的是经验本身，而不是他们出现的形式。 我从来没有“done XP“，但我显然可以写出高质量的软件。 XP的错误就在于坚持要求全盘接受。 这并不是XP的创始人的初衷，可现在却搞成这样。 很可能就是XP导致了这些好的实践经验不被人接受。 很讽刺，不是吗？

另一个大问题是，XP论述写于12年之前，于此至今已有40多种新的语言诞生。 XP倡导者在向人们推荐12年前的、现在可能过时的经验 — 12年相当于整个软件工业年龄的四分之一。 惊人吧。 让人们去发现适合自己的开发方法，他们将会总结出最有效的开发经验，这远不是几个脑瓜好用的人在上个世纪末能创造的。

我强烈要求Scrum倡导者停止与XP的争吵，我们讨论的应该是软件艺术。 这才是我们在这个领域里急切需要的最终目标。 幸运的是，现在有一个有着自己的manifesto的软件艺术运动正在逐步为人们所关注。 最终，我们可以通过好的软件艺术实践运动重新改革我们这个领域，而不是使用那些修修补补的策略。

开发者们：Don’t do XP。 我们要实现一个通常意义上的指导框架，解决多年来的困扰，构建以人为本的核心基础。让我们重新为艺术而工作。或者从此离开这个行业。

英文原文：Don’t do XP

你也许曾经想过要学习如何开发软件—或只是想临时的写出一个脚本—但不知道如何入手。 幸运的是，现在的互联网上到处都有丰富的学习资源让你能在短时间里成为一个程序员。

因为互联网的出现，使程序员们可以通过它讨论软件开发技术，发布学习指导，以及共享代码实例让其他人可以在线学习。 如果你感兴趣如何才能成为一个程序员，从网上这些大量的优秀的培训资料、学习向导入手将会是个不错的开始。

首要之首：不要急于选择一种语言

新手们有一个常见的错误就是犹豫于判断哪种编程语言是做好的、最该先学的。 我们有很多的选择，但你不能说那种语言“最好”。 我们应该理解：说到底，什么语言并不重要。 重要的是理解数据结构、控制逻辑和设计模式。 任何一种语言—甚至一种简单的脚本语言—都会具有所有编程语言都共有的各种特征，也就是说各种语言是贯通的。 我正在攻读我的计算机学学位，我编程使用Pascal，汇编，和C语言，事实上我从来没有把它当成职业以求获得回报。 我一直在自学编程，工作上用不到它，我使用现有的知识，参考各种文档和书本，学习它们的用法。 因此，不要急于选择何种编程语言。 找出你想要开发的东西，使用一种能够完成这项任务的语言，这就可以了。

根据各种开发平台的不同，有很多不同的软件开发形式可供你选择：从网站应用到桌面软件到智能手机软件到命令行脚本工具。 这篇文章里，我将重点介绍一些很受欢迎的入门教程和资源，它们能帮助你学会如何在各种主流的平台上编程开发。 我先假设你是一个悟性很强的读者，但对于新手，当我谈论程序代码时还是要按照入门级的水平。 因为即使是你自己看一篇编程入门手册，如果发现都能理解时，心情自然会很高兴，这样利于你进一步学习。

桌面脚本

想要动手在Windows里或苹果系统里编程，最简单的方法是从一种脚本语言或宏语言开始，例如AutoHotkey (Windows) 或 Automator (苹果系统)。 如今一些硬件程序员冲着他们的屏幕大喊大叫，说AHK和AppleScript并不是“真正”的编程语言。 也许他们说的是对的—技术上，这些种类的语言只能做一些上层的编程。 但是对于那些只是想来脱盲、想在他们的电脑里实现一些能自动运行的程序的新手来说，这些语言会是一个绝妙的入门入口—而且你会吃惊于它们丰富的功能。

例如，大家都喜爱的Texter就是Adam使用AutoHotkey开发的能独立运行的Windows应用程序，所以说这种脚本语言远不是只能开发小规模脚本软件。 如果你想从AutoHotkey入手，可以参考Adam的指导： how to turn any action into a keyboard shortcut using AutoHotkey（然后，你可以下载 Texter源代码 看看这个功能齐全的使用AHK开发的Windows应用程序的内部结构)。

Web开发

除了把自己约束在特定的编程语言和特定的操作系统上，你还可以在浏览器里开发你的杀手锏程序，让它在互联网上运行，这就是webapp。 欢迎来到奇妙的web编程世界。

HTML 和 CSS：开发网站，你第一件要知道的事情就是HTML(网页就是由它组成的)和CSS(一种让外观更好看的样式标记)。 HTML 和 CSS 并不是编程语言—它们只是页面的结构和样式信息。 然而，在开始开发web应用程序之前你必须要学会如何手工的编写简单的HTML和CSS，web页面是任何webapp的前端显示部分。 这个 HTML 指导 是你入手的好地方。

JavaScript:当你可以通过HTML和CSS构建一个静态页面后，事情就开始变得有趣了—因为到了该学JavaScript的时候了。 JavaScript是一种web浏览器上的编程语言，它的魔力就是能在页面里制造一些动态效果。 JavaScript可以做bookmarklets, Greasemonkey 脚本, 和 Ajax, 所以它是web上各种好东西的关于因素。 学习JavaScript从这里开。

服务器端脚本：一旦你学会了网页里的知识，你就要开始对它添加一些动态服务器操作—为了实现这些，你需要把目光转移到服务器端脚本语言，例如PHP, Python, Perl, 或 Ruby。 举个例子，如果想要制作一个网页形式的联系方式表单，根据用户的输入发送邮件，你就需要使用服务器端脚本来实现。 像PHP这样的脚本语言可以让你跟web服务器上的数据库进行沟通，所以如果你想搭建一个用户可以登录注册的网站，这样的语言正是你需要的。 Webmonkey 是一个优秀的web开发资源网站，里面有大量的各种web编程语言的指导手册。 阅读一下他们的 PHP 初学者指南。 当你感觉差不多了的时候，看看WebMonkey’s PHP and MySQL tutorial 学习如何使用PHP跟数据库交互。 网上最好的要数PHP语言官方的在线文档和函数参考了。 每个知识点上 (例如strlen function这个)都在后面列出来用户的评论注释，这些对于文档的本身是非常有价值的。 （我很喜欢PHP，但还有很多其他种服务器端的脚本语言你们都可以选择。)

Web框架：过去数年里，web开发人员在开发动态网站的过程中不得不一遍又一遍的针对重复遇到的问题写出重复的代码。 为了避免这种每次开发一些新网站都会重复劳动一次的问题，一些程序员动手搭建了一些框架，让框架替我们完成重复性的工作。 非常流行的 Ruby on Rails 框架，作为一个例子，它利用Ruby编程语言，为我们提供了一个专门面向web的架构，普通的web应用程序都能使用它来完成。 事实上，Adam使用Rails开发了他的第一个正式的（而且是叹为观止的！）web应用程序，MixTape.me。这就是 他的如何在没有任何经验的情况下搭建一个网站。还有一些其他的web开发框架包括 CakePHP (针对 PHP 编程者), Django (针对 Python 编程中), 以及 jQuery (针对 JavaScript).

Web APIs: API (应用层序编程接口) 是指不同的软件之间相互交换的程序途径。 例如，如果你想在你的网站上放一个动态的地图，你可以使用Google Map，而不需要开发自己的地图。 The Google Maps API 可以轻松的让你通过JavaScript在程序中引入一个地图到你的页面上。 几乎所有的现代的你所知道的和喜爱的web服务都提供了API，通过这些API你可以获取到他们的数据和小工具，在你的应用程序里就可以使用这些交互过来的东西了，例如Twitter, Facebook, Google Docs, Google Maps, 这个列表远不止这些。 通过API把其他web应用集成到你的web应用里是现在富web开发的前沿地带。 每个优秀的主流的web服务API都附带有完整的文档和一些快速入手的指导(例如，这个就是 Twitter的)。 疯狂吧。

命令行脚本

如果你想开发一个程序，让它读取文字或文件、输入输出一些有用的东西，那么，命令行脚本语言将是个不错的选择。 然而它并不像web应用程序和桌面应用程序那样有吸引力和好看的外观，但是作为快速开发的脚本语言，你却不能忽视它们。

很多的在linux平台上运行的web脚本同样能以命令行模式运行，例如Perl，Python和PHP，所以如果你学会了使用它们，你将能在两种环境中使用它们。 我的学习道路一直没离开Peal太远，我自学Python使用的是这本优秀的在线免费书Dive into Python。

如果成为一个Unix高手也是你学习的目标，那么你绝对要精通bash这个脚本语言。 Bash是Unix和Linux环境下的一种命令行脚本语言，它能够为你做所以的事情：从自动备份数据库脚本到功能齐全的用户交互程序。 起初我没有任何使用bash脚本的经验，但最终我用bash开发了一个全功能的个人代办任务管理器： Todo.txt CLI。

插件（Add-ons）

如今的web应用程序和浏览器都可以通过一些扩展软件来丰富自己的功能。 由于一些现有的软件，例如Firefox、WordPress越来越受到开发人员的关注，插件的开发也日益流行，人们都在说“But if only it could do THIS…”

只要你掌握了HTML，JavaScript和CSS，你就可以在任何的浏览器里开发你想要的很多东西。 Bookmarklets, Greasemonkey user scripts, 和 Stylish user styles这些软件都是用的更普通页面一样的语言写成的, 这几个东西都值得你去研究一些。

更高级的浏览器扩展程序，例如Firefox的扩展，它们可以帮助你很多。 开发Firefox的扩展，举个例子，需要你精通JavaScript和XML（一种标记语言，类似HTML，但具有更严格的格式）。 早在2007年我就写下来 how to build a Firefox extension, 这是我在笨手笨脚的研究网上的一些学习资料后获得的成果。

很多免费的、受欢迎的web应用程序都提供了扩展框架，例如WordPress 和 MediaWiki。 这些应用程序都是用PHP写成的，所以只有对PHP熟悉你才能做这些事情。 这个就是 如何编写WordPress插件。 而想驾驭Google Wave前沿技术的开发人员可以从使用HTML, JavaScript, Java, 和 Python 写小组件和小工具开始。 我写的第一个Wave bot是跟着这个 一个下午时间的快速入门指导开始的。

开发桌面上的Web应用程序

学习编程最好的结果是你在一个环境下学的东西可以应用到另外的环境中。 先学习开发web应用程序的好处就是我们有一些方法可以让web应用程序直接在桌面上运行。 例如， Adobe AIR 是一个跨平台的即时运行平台，它能让你编写的程序运行在任何装有AIR的操作系统的桌面上。 AIR应用程序都是由HTML, Flash, 或 Flex 写成的，所以它能让你的web程序在桌面环境中运行。 AIR是开发部署桌面应用程序的一个优秀的选择，就像我们提到过的 10个让你值得去安装AIR的应用程序。

移动应用开发

能在iPhone或者Android智能手机上运行的手机应用程序的开发如今正呈现井喷之势，所以你也可以梦想一下如何在iTunes应用商店里通过你的天才程序大赚一笔。 但是，作为一个编码新手，直接奔向移动开发所经历的学习曲线可能会很陡，因为它需要你熟悉高级的编程语言，例如Java和Objective C。 然而，你当然应该看看iPhone 和 Android 编程究竟是什么样子的。 阅读这个 简单的iPhone应用开发例子 可以初步认识一下iPhone程序的开发过程。 Android 程序都是由Java写成的，这有一个 简单的视频教程教你如何开发第一个”Hello Android“程序（注：可能需要代理才能看这个视频）。

耐心，刻苦，尝试，失败

好的程序员都有一个不达目的誓不罢休的品质，他们会惊喜于通过长期推敲和失败换来的一点成绩。 学会编程会有很好的回报的，但是学习的过程可能会是饱受挫折和孤独的。 如果有可能，最好找个伴一起陪你做这件事。 想精通编程，这和其他事情一样，需要坚持，反复尝试，获得更多的经验。

这篇文章里的内容就是对那些想通过自我研究达到学会编程目的的新手们的一些重要建议。 编程老手们：我有什么遗漏吗？ 不论你的水平如何，请留下你的想法。

英文原文：Programmer 101: Teach Yourself How to Code

本周在欧洲举行的TheServerSide Java研讨会上，ThoughtWorks的架构师和著名讲演人Neal Ford 指出那些只静止的依赖于一种专门的技术的人会在几年之内被淘汰出局。 他谈到了19世纪的马蹄铁匠，那时候干这种工作看起来是稳定而且有前景的职业，直到有一天科技进步（汽车的出现）导致了整个行业被淘汰。

我对Neal的这些话颇有感受。 当我还是大学教师、教授面向对象编程的时候，我有一个成年学生是个真正的C语言编程高手。 事实上，他的专长是使用Borland Turbo C 3.0。 当他很费力的去领悟C++和Smalltalk和这类语言后面所代表的含义时，他竟然会把这种语言程序加载到Turbo C编辑器里，认为或者是希望Turbo能够对这些不同的语言也能读懂一部分。

这位兄弟认为只要全身心的专注于一个专业就能得到稳定的工作。 三年后，他丢到了工作，而且离开了编程行业。

这个例子很极端，但却是我们会经常碰到的，因为如今的技术日新月异。 这种变化甚至并不一定是跟技术相关的。 我父亲一辈子都是个钢铁工人； 当美国经济上不再需要这种老式的工厂炼铁时他也就失业了。 无论如何，技术上更新的速度快的实在令人害怕。

Neal还提出了何种技术发展趋势将会在将来导致我们被社会抛弃。 他主要点评了那些很新奇的但很实用的能够解决目前出现的问题的一些途径，谈论了那些过去是完全不可能但现在能被人们使用的一些技术，以及一些即将被替代掉或被整合的过时技术。 他认为这波由互联网引起的浪潮混合了多种因素、这种情况我们不可能有机会经历第二回。

我不知道我们是否有能力预测这些变革。 变革当然是在变革之后才能看出来。 当变革触及到我们的生活之前，或者正当时，我们能预测吗？ 我并不这么认为。 我应该可以察觉到这变革正在发生，因为新的技术正被大家所认可，而且新的公司会应用而生， 如果我们留心观察的话。

但我不认为我们单独某个人可以轻易的预测到这些变革都会何时对我们产生影响。 有些世界性的改变对我们的职业没有任何的影响。 而有一些小小的改变就会让我们歇业很久。

那么，你觉得呢？

1. 不要对任何技术爱的过深。 你也许会发现自己依赖某种技术太久了。

2. 如果你告诉自己 “你还有充足的时间 <选择你的语言>, 那你是在走钢丝绳。 千万不要让自己处在这种处境里。

3. 持续不断的往你的知识库里补充新东西。 每年至少学会两种值得注意的新工具、新技术。

4. 千万不要自我觉得是一个无所不能的高手。 永远都会有学不完的知识和应用。

英文原文：Re-Live the Past, or Predict the Future?

我收集各式各样的至理名言。最近我一直在研究敏捷软件开发；有收获吗？下面就是能够指导敏捷软件开发团队的26条核心原则。

• 用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题：“做好一盘菜后你再做下一盘”． 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的，我们设计的功能中总会有一部分会被放弃砍掉，如果提前开发，很可能做无用功。 一次只开发一个用例（或很少几个用例，这根据你的开发团队的大小而定）； 让这个用例功能完整； 让相应的测试用例都能通过； 相应的文稳都补齐； 只有在当前的用例完全开发完成后，才做为一个整体提交到版本库，才进行下一个用例。
• 避免提交一个半成品。 这一点大家似乎都知道，但这条原则必须列入任何一个开发指导里。 能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。 如果系统编译失败，那一定是有人抄近道到了。
• 不要在还没有任何使用案例的情况下设计通用模块。 只有在你知道有具体用例的情况下，你才可以实现一个具体的类，而且你在该类中只应该实现当前该用例需要的方法。 你也许会想到将来这个类会有其它的用途，你可以用注释的方式记录一下，但不要去实现它，只有在有了具体用例后你才可以实现它。
• 一定不要在没有使用例的情况下往类里添加成员方法。 这跟上面一条极其相似，除了这里针对的是数据成员。 开发人员很容易想到：一个‘客户记录’里应该有‘送货地址’的信息，但一定不要在没有任何用例要求这个属性的时候实现这个属性。
• 不要害怕做决定；不要害怕改变以前的决定。 敏捷开发的目的是应对客户需求的不确定。 开发前期你不可能获到全部的信息。 你应该尽可能的拖延做决定的时间，但一旦到了你该做决定的时候，你应该当机立断，让项目向前推进。 你不能说一直等到有了足够的信息才做决定。 相反，你要依赖现有的信息作出最正确们决定。 之后，当有新的信息出现后，不要害怕对以前的决定作出更改。 (老辈人有的称之为触发器，但我称之为随环境而变)
• 不断的了解如何改进系统。 这项工作没有尽头，你应该做好思想准备，持续不断的寻找可以改进的地方，收集各种关于如何找到质量问题、解决质量问题的案例。
• 审查，审查，审查。 敏捷开发可以帮助我们应对需求在将来的不确定，但过去的事情也存在不确定性。 测试工作永远不能停下来。 程序每次运行的表现都要被评审和记录。
• 软件的设计要以人为本，而不是系统。 很多开发人员退而求其次、以技术为中心，让设计为技术服务。 永远不要忘记软件的终极目标是什么，是帮助人们完成工作。
• 测试是产品的一部分。 许多开发人员和经理都认为产品就是你打包给客户的东西，其余的都不重要。 其实测试也应该看作是产品的实际一部分，应该在设计时给予相当的重视，甚至，在很多时候，测试功能也应该同产品一起提交给客户。 （后面说的这部分很多人都不认可，一个内置的能自我测试软件包并不会占用多少额外的资源，但当你需要用到它时，你会发现它的巨大价值。)
• 先写测试用例，后写代码。 测试用例可以用来精确的说明我们的设计需求。 很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。 想想吧，先写测试用例后编码能节省多少时间。 但是：写完测试用例1，然后编写用例1，完后才开始用例2。
• 清理垃圾代码。 很显然，又是一个尽人皆知的道理，但它也必须写入任何的开发原则里，因为它是如此的重要。 查找垃圾代码的工作永远没有尽头，找到它，消灭它。 要去除掉所有的不能给实际用户带来价值的代码。 如果你不能指出某段代码对用户有什么用处，那它很可能就是没用的。
• 培养对集成失败问题立即做出反应的习惯。 你要明白，当集成构建失败时，它会影响项目中的每一个人，所以没有比让核心程序能正确的集成和测试通过更重要的事情了。 我曾经见到过有的团队的集成构建中断几个月都不去管它，因为他们有其他的工作要做。 每个人都在忍受这种情况，但没人采取措施。 我们应该明白，应该广泛的认识到，只要做出一点点工作，整个的团队会因此得到非常大的回报。
• 团队的每个成员都要知道客户的需求。 大型复杂的项目必须要分割到几个独立的团队去开发，然后派发到每个开发人员的手中，但这绝对不能变成程序员可以不明白最终产品的使用用户的需求和目标是什么。
• 把意义相关的东西放在一起。 组织好代码，让高度相关的东西都放在一起，也就是放在一个类里。 这是标准的面向对象设计原则里的封装的概念。 理想情况下，类之外的程序并不需要知道类里面的工作细节。 有些开发人员喜欢把代码放到好几个文件里，这样是为了按另一种方式组织它们：例如把相同的数据类型的放到一起，或按字母顺序分类。 举个例子，有人会把所有的常量放在单独一个包下的一个类里，他们这样做毫无必要，增加了程序的复杂性。 按照指导原则，它们应该按照相关性进行分组，从而减少复杂性。
• 先测试后提交代码。 这个准则能让你确保“永远不要让集成构建失败”的准则。
• 过早优化是灾难之源 这句话是引用Don Knuth的，今天听起来一点不错。 在内核里的代码应该尽力的写好来避免不要的浪费，但针对高于单个方法的级别的优化应该在整个项目测试通过、针对最终实际用户的压力测试用例通过之后才能进行。 仅仅根据静态的代码来判断哪些是影响整个性能最主要的问题的论断往往是错误的。 相反，评审整个系统的运行表现，找出真正影响性能的1%的代码，只针对这些代码做优化。
• 最小化未完成的编码任务的工作包（backlog）。 当开发人员开发一个设计用例时，有的功能会牵涉到所有修改着的但未完全开发完成、充分测试的代码。 把未修改完成的代码保存到本地数天或数星期，这样增加了工作浪费的风险，会出现返工。 想象有三个任务，每个估计都要一天。 如果三个一起开发，并行起来每个都需要3天，这样一累计会有9个’单位’的风险。 如果顺序的开发，一个开发完成后再开发另一个，只会有3个‘单位’的风险。 这个并不符合我们的直觉。 我们的直觉告诉我们，当我们在这种情况下时，我们希望三个一起完成。 但是软件不像盖房子。 小的、迅速的、完整的任务不仅仅会降低我们的认知负荷，也减少了进行中的开发对其他人正在进行的开发的相互影响。
• 不要过度功能范化。 也就是我们所说的 “YAGNI – You Aren’t Going to Need It” 。 程序员在编写一个类时喜欢料想：这个类可能在其它地方其它类中会有其它用途用． 如果这些用途是被当前的用例用到，那这样思考是没错的，但常常开发人员想到的这些用途都是目前不存在的用途，实际上可能是永远不会用到的用途。 (This subject always reminds me of the classic Saturday Night Live skit about the product which was both a floor wax, and a dessert topping.)
• 如果两行代码能完成就不要写成三行。 简洁的代码永远都会给需要阅读这段代码的人带来好处。 但千万不要把代码压缩的难以理解了。 精简的、书写规范的代码易于维护和查找错误，冗长的、太多修饰的代码则相反。 尽可能的简化但不要过度。
• 永远不要按行数多少来评价代码头。 编写某个任务所产生的代码行数会因程序员而异，因编码风格而异。 代码的行数不会提供任何关于程序完成情况和代码质量的信息。 代码质量可以相差200倍之多，这是计算代码行数的方法不能胜任的。 应该计算功能性的用例数。
• 我们应不断的再设计、再分析。 应用这一条时你要非常的小心，因为有些代码很脆弱、难以维护。但不要害怕修改这些代码、让它符合真正的需求。 一个数据成员以前是整数型的，但现在有个用例需要它是浮点型，不要害怕去改变它，只要你按步骤：测试，写文档，布署。
• 删除死代码。 当发现有一大段不能理解的代码时我们习惯的做法是“让死狗躺在哪”。 比如说，我们需要往类里添加一个新方法来替换以前的旧方法，通用人们会保留老方法‘以防不测’。 其实，我们应该花一些功夫去检查看看这个老方法是否还有用，如果没有证据显示它还有用，就该删掉它。 更糟糕的错误做法是把这些代码注释掉，留下一堆注释码。 注释掉的代码一旦发现就该被删掉，不能留到测试时还有、甚至提交到代码库。 添加代码总是容易的，删除代码总是困难的。 因此，一旦发现有可能没用的代码，你应该花点时去确认它、删除它，这样会让代码更加可维护。
• 不要自创新语言。 程序员喜欢使用文本文件来实现功能性的趋动，这样可以使程序变的可配置。 通过配置文件来改变软件行为所产生的后果是不过控的。 XML的诞生促使了一系列的特别的自定义的‘脚本语言‘的出现，人们试图通过文件的配置以让最终用户‘编程’来控制软件的功能、避免重新编译。 这种设计上的缺陷是：软件里的各种操作的准确定义在脱离了具体上下文的特定实现的情况下不可能被准确的定义。这些各式各样的脚本型语言只是对那些对软件代码的内部工作机理有着相关的知识背景的人才会价值。 所以，真正的最终用户是不可能知道软件的内部工作机理的，不可能推理出这些复杂的指令组合会产生什么样的预期结果。 脚本有它的用途，也不应该被抵制，但设计人员必须以非常非常安全的方式使用它们，尽可能使用现有的语言，必免使用新发明的语言。
• 只有当准备好了实现和测试才去确定设计。 我应该有一个总体的认识我们要做什么，应该有个总体架构目标，而不是详细设计、详细的具体方法的实现，只有当开发迭代到一定程度后、足以让我们定下设计细节后才去把它表现成文档。 详细设计只应该包括当前需求用例中需要覆盖的部分。 软件开发中最大的浪费就是你花时间设计出来东西后被告知不需要了，或者是你的设计一开始就建立在错误的假设上。
• 软件是可塑的。 软件不像盖房子，我们可以轻易的改的面目全非。 无数事实表明软件比它的规格说明书善变的多。 而且，软件产品和设计之间的互动明显比规格说明书有效率。 所以，你应该直接实现你的设计，这样客户就能很容易明白你的设计细节。 当发现有问题、要改变设计时，修改软件要比修改文档容易的多。 更重要的是，当客户看到了能运行的程序后，你也就更能搞清客户的需求是什么了。
• 对被检测到的和被报告的异常情况请多花一点时间对其进行详细描述。 程序员一般都非常的懒，抛出异常时只描述错误的表面现象。 设想如果只是作者自己会遇到这种错误，他会记得这种一直使用的错误描述信息是什么意思。 但站在客服技术支持的处境，他们因为这种不准确的、不完整的错误描述浪费了大量时间。 这些信息应该达到让一个刚走进屋里没有任何经验的人能看明白的程度。 客户和客服基本都是对编程不懂的人。

上面这些条目没有特别的顺序。 欢迎对这些我汇总的指导原则进行评论，也许你并不认可其中的几条，也请发表你们意见。

英文原文：26 Hints for Agile Software Development

手机浏览器之间存在很大的差别，主要是因为它们对各种手机操作系统的支持有别，提供的各种功能也有很大差异。 最好的浏览器可以正常的浏览大部分的网站，提供页面缩放和键盘快捷键功能,而其它的一些只能浏览针对移动设备优化过的网站。

同时,很多手机并没有提供你多少选择浏览器的能力,但现在的很多新手机使用了像windows mobile之类的操作系统,它已经内置了好几种浏览器. 如果你的手机是使用symbian s60,那你还可以选择安装自己喜的浏览器.

• 作为一个经验丰富的开发人员，回顾往事，最臭的让你最受折磨的代码是什么样的？也就是说，请指出一种代码，如果你能根除掉这种很臭的代码，那么在你的程序中的大部分设计问题都会迎刃而解
• 我们有如此多的不同的原则和指导来帮助我们去实现好的设计。对于一个新手来说，他应该从哪里开始？哪种代码风味（code smell）或原则，对于一个新手来说，可以最大程度的帮助他们做出好的设计（节省好几年去总结经验）？

尽管字面上这两个问题很相似，但我认为这第二个问题更具有广泛的意义，跟第一个有很大的不同。

不管怎样，这次研讨会都能称得上是一个热闹的会议。我们有不少很厉害的辩手来批判所谓的最臭的代码的味道（最臭的臭弹）：

• Corey Haines 的观点： 重复的代码
• 我的观点： Primitive Obsession (总是使用底层的数据结构/原始的数据类型，而使用经过更高层抽象过的数据机构或其它可以n倍的减少复杂性。这并不只针对面向对象的编程。这指的是缺乏在应该进行抽象的数据层面上进行抽象)
• Matt Van Vleet 的观点：单一功能原则
• Venkat Subramaniam 的观点：避免写代码
• Jim Weirich (他并没有出席这次会议) 的观点： 共生性

我们都认为避免写代码（只有在没有其它办法的时候才去写新代码）是最重要的需要让每个开发人员都认识到的问题。大量的重复的代码，劣质的代码（存在于各种项目中）积累到今天已经无法统计了。在很多情况中程序员根本不喜欢去搜寻一下可以利用的程序，他们只知道自己去写。这就是为什么我们要去以代码行数(LoC)来作为评审代码效率和性能的原因。一般来讲，好的程序员的开发速度会比一般的程序员的速度快20倍以上，因为他们对重复利用现有代码的认识完全不在一个层次上。很多人对 “Not Invented Here Syndrome（简单解释为开发团队不喜欢使用不是自己写的程序，缩写为NIHS）“ 这个说法感到困惑。我个人认为NIHS对于我们这个领域里的进步有很重要的意义。NIHS体现在设计和解决方案层面。Joel 写了一篇很有趣的博客，题为 In Defense of Not-Invented-Here Syndrome，大家可以参考看看。

然而，如果当大家都认为项目里我们必须自己写点自己的代码时候，那么我们最应该提防的一件事情是什么呢？SRP 和 Connascence 真的可以帮你实现高内敛的设计。如果程序不是高内敛的，我们应该很容易可以在里面发现重复的代码（至少是概念上的重复），你也会发现只要在设计上选择正确的方式进行抽象提取就能很好的解决这种问题。所以代码重复和Primitive Obsession实际是相互因果的关系。

据我的经验，我要补充一下，我曾看到过有程序并没有多少的重复，但却非常让人难以理解，这是为什么？所以我要提出，“只要是代码进行了较好的抽象，它就会很容易让人理解和易于推理出其功能”。同样，如果你试图去消除重复的代码，在某一程度上，这里并没有字面上的重复，但是这里却存在一个概念上的重复，那么只有对它进行更高一级的抽象就能有效的解决这个问题。因此我的结论是：回顾往日经历， Primitive Obsession 才是针对低质量设计最大的难题，也就是所说的最臭的臭蛋。

原文英文地址： Biggest Stinkers

标准的压力测试报告只提供黑盒视图（Black-Box View）

当分析下面的压力测试报告时我们只能发现在我们的应用程序的压力达到某个“点击数/秒”临界点时问题出现了。

压力测试结果

我们会发现服务器的CPU很可能跟问题有关，因为它的使用率随着我们产生压强的增多迅速升高，但我们停下来分析问题时，它的使用率也下来了。如果你把这个报告呈给你们的工程师，他们很可能会惊讶他们的应用程序为什么如此的不经压，但他们也没法告诉你是否是应用程序出了什么问题（以及问题在哪）或者是当前版本的应用程序根本就承受不起这么大的压力。

过多的测试迭代在拖累我们

所以可以看出来，我们从压力测试工具上获得的标准测试报告并不能帮助我们分析出问题的根源在哪里。那通常我们是怎么最终找出问题的呢？下面的图例显示的就是我从我的客户那里看到的典型的测试周期。

需要反复迭代测试才能定位产生效能问题的根源

每次测试之后他们都和工程师一起坐下来讨论测试的结果。工程师们试图重现报告中被重点显示的问题。通常这些问题只有在有相当压力的情况下才会出现，根本就没法在工程师的本地安装了debugger工具或profiling工具的机器上重现。可行的办法就是要改进在测试中捕获到的各种数据详细程度。对捕捉信息的改进可以包括收集额外的有用的性能数据，例如CPU，内存，I/O，内存回收事件，数据库统计，… 报告应用程序特殊数据，例如n号订单被处理了，处理队列的长度，处于活动状态的用户会话的数量，… 或者扩展应用程序输出的日志，让它跟踪记录性能信息，例如函数的调用次数，执行了哪些SQL语句，…

当改进完成了之后，测试会再进行一次。如果你很幸运，你会在第一次改进后获得你想要的数据结果。但据我所观察的结果是通常要好几轮改进之后你才能得到能够让你分析出问题出在哪里并且能够用来修正程序的报告信息。这些额外的测试迭代会耗费测试者以及开发人员的大量时间。如果你有独立的测试团队或者你外包了测试，那你或需要额外的开销来应付这些迭代测试。

目标：花最少的时间做更多的测试

理想的目标是去除所有的额外开销，就现状来讲包括在压力测试中改进和分析捕获到的数据的工作量。美国Novell公司就有一个精彩的例子来展示在他们的分布式敏捷开发团队里改进压力测试过程的。你可以在公布的学习案例中了解更详细的信息。

测试中的应用性能管理 可以让你去使压力测试的功效发挥到极致。下图展示了一个真实的压力测试过程是怎样的：

通过应用性能管理避免测试迭代

Yes we can! 让压力测试充分发挥其能力

.这篇博客只是简单的谈到了我在客户哪里遇到的问题的皮毛 – 请查看 Case Study we did with Novell ，其中讲到了Novell公司如何让他们的测试吞吐量提高2-3倍的。过多的测试迭代和对应用的黑盒测试视图妨碍了我们让压力测试发挥更大的功效，应用性能管理可以帮助我们使这个过程更高效。有兴趣的话你可以下载完整版的How to Transform the Load Testing Process ，它里面讨论了更详细的我们所说的问题，同时向我们展示了如何花最少的时间做更多的测试。关键的要素就是让我们对应用程序内部可视化，能够自动的捕捉数据和分析数据。

.欢迎您对这个问题的反馈。

Google 从来都没对人说过在他们的数据中心究竟有多少台机器在同时运行。但在最近在一个 Google 工程师的报告中显示Google计划将会运营多达千万台的服务器。

在关于大规模技术系统的 ACM 研讨会 上Google的创始人 Jeff Dean 是主发言人之一，他讨论了关于公司强大的基础架构上一些技术细节问题，这个基础架构是通过若干个遍布全球的数据中心构成的。

在他的 报告 (由 James Hamilton 提供的链接) 中, Dean 同时提到了一种被称作Spanner的新的存储和计算系统，这种系统将会试图寻找一种对跨越数个数据中心的Google服务进行自动管理的功能。这将包括对整个“机器战队”上资源的自动分配。

Dean 说 Spanner 将会设计成能够适用将来的 “10⁶ 到 10⁷ 台机器”的规模，也就是百万到千万台的机器。 最终目标是建成“自动化的、动态的全球范围内的数据以及计算分布而最小化数据延迟和成本。”

从长期效果来看，这个属于成本管理策略的系统将会解决带宽消耗和电力消耗在不同地区之间的差异的问题。我们之前也提到过，这种在数据中心之间无缝的自由切换的能力将会使对能源的管理很灵活，就像其中的一个“逐月（follow the moon）”策略，它能有效的利用夜间时间减少电力消耗和冷却消耗，在这个应用场景中，虚拟化的工作负荷会在不同的时区里进行切换转移，以此从非高峰使用率的地区获得节省下的资源。

实现自动管理技术的另一个动机是在遇到故障或数据中心停机时产生正确的路由。Google很早就在针对这个目的 开发某种软件 ，最近的几次Gmail宕机事件更增强了这种数据中心之间负载快速转移的技术的价值。

这种自动化技术可以允许Google设置更多的高效能设备，就像在比利时的 无冷却系统数据中心，如果天气温度过高有损害机器的危险，Google 说，他们将会按照需要关掉位于比利时的设备，而将哪里的负载转移到其它数据中心。