想象
想象如果没有需求。你的尝试就会觉得容易。
只要几行代码，你就能到达天空
想象所有的人们，为今天而编写代码
想象没有时间进度，做起来也不会太难
没有该死的项目截止日期，也没有人监督你
想象所有的人们，手牵手一起编写代码
你也许会说我是个极端分子，但我并不是唯一的一个
我希望有一天你能加入我们，充满乐趣编写许许多多的代码
想象一下口头文档，我怀疑你是否能做到
不需要UML 视图，只需要从一个人到另一个人的语言传递
想象只需要重构，如同在沙滩上玩耍
你也要说我是个极端分子，但我不是唯一的一个
我希望有一天你能加入我们，充满乐趣编写许许多多的代码
这是非程序员第49期的文章爱丽丝漫游用例奇境里引用的一段歌词，出处在Songs of the Extremos ,很有意思的软件之歌，如果知道原曲旋律，唱起来一定很爽口....比如> The Long and Winding Thread...
回到xProgrammer上，今天看了若干期，在差不多开始厌倦于那些枯燥，抽象，充斥各种莫名术语，行文干巴巴或纠缠不清的文案时，突然看到爱丽丝漫游用例奇境这一篇，妙趣横生，感觉蛮不错的。
爱丽丝说：“我无法断定哪种情况更加糟糕：陷于‘分析瘫痪’当中，还是在理解需求之前直接跳到编码部分。我多希望有一种介乎两者之间的简单方法啊。”
也许爱丽丝的问题并没有一个彻底的解决方法(没有银弹:P），或者没有人能将解决方法描述的尽善尽美，至少，在CMM/RUP...等貌似重型方法论大行其道，XP/“代码即设计”的极端回应之后，终于有人开始如何思考有效的缩短“做什么”和“怎么做”之间的间隙了。
PS:RUP是否重型方法论，其实也是有争议的。在xProgrammer的37期，有一篇七步搞死RUP,嘟嘟囔囔的痛斥瀑布，宣扬迭代，给RUP申冤，认为在RUP中引入瀑布思想，过度和不适当的设计，误解RUP，才使RUP冒出BAD SMELL。以下为搞死RUP七步简单笔记：
第一步:加入瀑布思想
有些东西应该象建造房屋那样去构建设,但软件不是
初始化阶段探索少量但重要的需求(10%)获得范围,风险尺度,
大部分需求是在细化阶段探索,此阶段迭代的构建体系结构和解决技术风险
迭代周期长度是2~6周.迭代方法允许我们边学边走.固定成本问题
第二步:将RUP作为重型的，预见性的过程去应用
重型过程的特征是刻板,繁琐,形式化而缺乏人性化
RUP并非重型和预见性的,其本意是使用轻量,敏捷和适应性的过程精神
适当创建RUP活动和工作
不存在所有迭代的详细计划
第三步 避开对象技术能力
对于技术领域来说,熟练的对象技术开发人员和采用RUP或者任何过程,后者是相对次要的因素
蓝领工人理论并非所有项目都通用
第四步:低估适应性迭代开发
应该在组织和项目层次上拥抱变化,
迭代开发的思想是要在只完成了部分需求和设计的时候,快速开始编程,这样做是为了得到实际的反馈
迭代开发的核心是基于反馈进行调整
开发者和客户是合作伙伴关系
开发人员不理解系统要做什么->加强需求管理
复杂的控制流或难以理解的行为->加强用例管理
技术方案是否新颖或复杂-> 进行体系结构优化设计
第五步避开深谙迭代开发的顾问（如果项目有顾问的话）
第六步:轰轰烈烈的采用RUP
形式主义，填鸭式的推行RUP
第七步采纳（以RUP名义的）错误的建议
一沙一世界 一花一天堂 掌中握無……
网络编程技术、多媒体技术、PC应用技术
