基于java技术的软件开发架构总结
在具体的实现中，表现层可为Struts/JSF等，业务层、访问层可为JavaBean或EJB等，资源层一般为数据库。
宏观上的层次就是这样，在具体现实中，有如下几种实现形式：
1， 轻量级实现
表现层使用基于MVC的框架，比如Struts或JSF
业务层使用JavaBean（就是常说的Service）
访问层使用JavaBean（就是常说的DAO）
优点：
轻量级实现，简单明了ü
缺点：
难以无法实现分布式应用ü
以下功能必须通过编程实现ü
事务控制²
资源管理（包括组件的创建）²
线程安全问题²
安全性²
2， 重量级J2EE实现
表现层依然是基于MVC的框架
访问层采用实体Bean实现，如果可能最好采用CMP，实现起来更简洁。此处的实体Bean可以考虑采用本地接口
业务层一分为二，服务控制器可以由会话Bean充当，用来封装业务流程（相当于轻量级实现中的Service），也可以考虑采用本地接口；门面也可以由会话Bean充当（一般来说无状态会话Bean足矣），作为业务层的入口，应该采用远程接口。
优点：
以下功能可由EJB容器自动实现，或通过配置实现ü
事务控制²
远程访问²
线程安全²
资源管理²
安全性²
可以进行分布式应用ü
因为采用了EJB，故部分特征可以由装配人员来配置（比如事务，安全性等），不需要在软件中硬编码ü
EJB组件有更好的重用性ü
可利用容器提供的其他企业级的功能（比如集群，容错，灾难恢复等）ü
可以加入MDB（实现异步通讯）等技术ü
缺点：
开发难度较高ü
如果不恰当的使用实体Bean，会造成效率低下。如果采用CMP，则很多数据访问的操作不能直接实现。ü
缺少良好的开发环境ü
软件可能依赖于具体的EJB容器ü
EJB容器可能很贵，开发软件也可能很贵ü
3， 轻量级和重量级J2EE的切换
如果项目有需求，并有充分的时间，还可以通过在表现层和业务层的交界处加入“业务代表”（JavaBean + 服务定位器实现）来对表现层隐藏对业务层访问的细节(JavaBean和EJB的访问方式显然不同)，只需替换“业务代表”就可以切换轻量级和重量级两种实现。举例说明，一般电话上都有一个P/T开关（脉冲/音频开关），随着开关状态的不同，拨号时电话机会判断是使用脉冲拨号还是音频拨号。
这种架构唯一的缺点就是必须写两套实现代码……
4， 轻量级J2EE实现
访问层通过JavaBean调用ORM框架实现（Hibernate，iBatis等），代码简洁，功能完备（相对于EJB 2.x而言），如果用的是Hibernate，可以忽略底层数据库的差异，如果用的是iBatis，则方便对SQL进行优化。
业务层和访问层依靠AOP框架（如Spring）可以在切面中实现事务，安全性等功能，同时不影响业务代码。如果采用Spring，其中已经内置了事物切面，并可以轻易的与主流ORM框架进行整合，实现声明式的事物管理。当然，更可以使用IoC模式降低组件间的耦合性。
优点：
可以通过AOP框架实现事物、安全性等功能，同时不影响业务代码²
ORM框架比CMP更灵活，比BMP更简洁（相对于EJB² 2.x而言），运行效率也比较高
如果使用Spring，可以用更简单的方式实现J2EE中比较复杂的功能²
无需额外的容器²
ORM和AOP框架可以找到免费的开源实现，降低项目成本（不过也有人认为采用开源项目可能综合成本更高）²
缺点：
非官方框架，缺少文档、技术支持和业界经验²
采用技术太多，学习曲线较高，难以招到合适的程序员（咱们学员可以考虑在这方面下点功夫，呵呵）²
某些企业级的功能轻量级框架还不能实现（或独立实现）-----------------------------------------²
测试、调试均比较复杂²
另类之处：
使用BMP + Hibernate（具体做法为BMP中的持久化方法，比如ejbLoad, ejbStore等都委托给Hibernate实现）
优点：
借助于Hibernate强大的ORM功能弥补CMP的不足（特别是EJB-QL）
缺点：
事物不好控制
不伦不类，容易发生未知的错误（比如Hibernate自身的缓存可能会于容易提供的缓存冲突）
另类之处：
将业务层（也可能包含访问层）包装成Web Services，支持远程调用
优点：
借助于Web Services可以实现松散耦合分布式应用，说的大一点，就是传说中的SOA，呵呵
缺点：
Web Services自身效率不高，无状态，安全性差
当然，即使不分层，也能做出软件来，但我们应该思考怎么做才能最好？如果说分层不好，那么不分层的优势又在哪里呢？？如果说分层有性能的损耗，那么性能损耗在哪里呢？？如果不分层，软件工程思想中的“分而治之”的原则启不受到了质疑？
有人说，分层是为了减少代码量，如果分层是为了减少代码量，那怎么能减少，代码的重用也许会减少一些，但是程序更多的是业务，我们关心的也只是业务，试问分层的意义就是为了减少代码量？
总之我的观点就是：软件分层是必须做的。至于框架，不应该问用不用，而应该问用什么？要选用实践检验过的框架，毕竟实践是检验真理的唯一标准。
二年的J2EE开发之后，我们应该掌握了一些主流的架构模式，总结一下：
宏观上讲，我们采用了分层的架构，将软件分为如下的层次：
第二篇：java技术小总结
Java语 言 出 现 的 背景 、 影 响 及 应 用 前 景
一 、 背 景
最 近 一 年 多 来 ,在 Internet上 出 现 的 特 别 吸 引 人 的 事 件 就是 Ja va语 言 和 用 Java编 写 的 浏 览 器 HotJava。
19xx年 ,SUN MicroSystem 公 司 的 Jame Gosling、 Bill Joe等 人 , 为 在电视 、 控 制 烤 面 包箱 等 家 用 消 费 类 电 子 产 品 上 进 行 交 互 式操 作 而 开 发 了 一 个 名为 Oak的 软 件 (即一 种 橡 树 的 名 字 ), 但当 时 并 没 有 引 起 人 们 的 注 意 ,直 到 19xx年下 半
年 ,Internet的 迅猛发 展 ,环 球 信 息 网 WWW的 快 速 增 长 ,促 进 了 Java 语 言 研 制 的 进展 ,使 得 它 逐 渐 成为 Int ernet上 受 欢 迎 的 开 发 与 编 程 语 言 ,一 些著 名 的 计 算 机 公司 纷 纷 购 买 了 Java 语言 的 使 用 权 ,
如 Mi-croSoft、 IBM、 Netscape、 Novell、 Apple、 DEC、 SGI 等,因 此 ,Java 语言 被 美 国 的 著 名 杂 志 PC Magazine 评 为 19xx年 十 大 优 秀科 技 产 品,(计 算 机 类 就 此 一项 入 选 ),随 之 大 量 出 现 了 用 Java编写 的 软 件 产 品 ,受 到 工 业 界的 重 视 与 好 评 ,认 为 "Java是
八 十 年 代 以 来 计 算 机 界 的 一 件 大 事 ",
微 软 总 裁 比 尔 ·盖 茨 在 悄 悄 地 观 察了 一 段 时 间 后 ,不 无感 慨 地 说 :"Java是 长 时 间 以 来 最 卓 越 的 程序 设 计 语 言 ",并确 定 微软 整 个 软 件 开 发 的 战 略 从 PC 单 机 时 代 向 着 以 网 络为中 心 的 计 算 时 代 转 移 ,而 购 买 Java则 是 他 的 重 大 战 略 决 策的实施 部 署 。因 此 ,Java的 诞 生 必 将 对 整 个 计 算 机 产 业 发 生 深远的 影 响,对 传 统 的 计 算 模型 提 出 了 新 的 挑 战 。
SUN MicroSystem 公 司 的 总 裁 Scott McNealy认 为 Java为 Internet和WWW开辟 了 一 个崭 新 的 时 代 .
环 球 信 息 网 WWW的 创 始 人 Berners-Lee说 : "计 算 机 事 业 发展 的下 一 个 浪 潮 就是 Java,并 且 将 很 快 会 发 生 的 "。看 来 ,使 用 Java已 成 大 势 所 趋 !
MicroSoft 和 IBM 两 大 公 司 都 计 划 在 Internet上 销 售 用 Java 编写的 软 件 。
Apple、 HP、 IBM、 MicroSoft、 Novell、 SGI、 SCO、 Tandem 等 公 司均计 划 将 Java并入 各 自 开 发 的 操 作系 统 ,而 负 责 开 发 并 推 广 Java技 术 的 SunSoft公司 (这 是 SUN下 属的
一 个 子 公 司 ), 将 通 过 颁发 许 可 证 的 办 法 来 允 许 各 家 公 司 把Java虚 拟 机 和 Java的Applets类库 嵌 入 他 们 开 发 的 操 作 系 统 ,这 样 各 类 开 发 人 员 就 能更 容易 地 选 择 多种 平 台 来 使 用 Java语 言 编 程 ,不 同 的 用 户 也 就 可以 脱 离 Web浏 览器 来 运 行 Java应 用程 序 ,这 无 疑 是 很 受 广 大 用户 欢 迎 的 ,也 为 Java语 言 的 应 用 开 拓了极为 广 阔 的 前景 。 (当然 ,各 类 JavaOS之 间 的 兼 容 性 必 须 得 到 重 视 ,好 在JavaSoft已 保证 将 监 督 这种 兼 容 性 )。
另 外 ,由 JavaSoft 推 出 的 完 全 用 Java编 写 的 Internet上 新 型 浏览器 HotJava,比 去 年alpha版 更 为 实 用 ,不 仅 能 编 制 动 态 的 应 用 软件 ,而 且 能 编 制 完整 的 成 套 桌 面 应 用软 件 ,将 来 还 会 提 供 更多 的 能 帮 助 编 制 动 态 应 用 软 件 的 模 块,显 然 ,这 也 是 为 J ava的应 用 提 供 了 有 力 的 例 证 。
今 年 6月 7日 ,由 SUN公 司 和 台 湾 经 济 事 务 部 信 息 发 展 局, 台湾信 息 技 术 研究 所 等 单 位 牵 头 ,成 立 了 一 个 "Java联 盟 ", 参 加 的 有 22个 在 台 湾相 当 著 名 的 计 算
机公 司 ,并 在 台 北 建 立一 个 "Java 开 发 中 心 ",在 新 竹 建 立 一 个 "Java语 言实 验 室 ", 以 掀起 台 湾 开 发 与 应 用 Java 语 言 的 热 潮 。
香 港 则 在 今 年 4月 就 举 行 了 全 岛 的 Java杯 比 赛 ,在 计 算 机界掀 起 了 学 习 Java的热 潮 (尤 其 是 在 大 学 生 们 中 ,出 现 了 一 批 Java迷 )。
有 人 预 言 :Java将 是 网 络 上 的 "世 界 语 ",今 后 所 有的 用 其 他语 言 编 写 的 软 件统 统 都 要 用 Java 语 言 来 改 写 。
二 、 Java 语 言 对 软 件 开 发 技 术 的 影 响
工 业 界 不 少 人 预 言 :"Java 语 言 的 出 现 ,将 会 引 起 一 场软 件革 命 ",这 是 因 为 传统 的 软 件 往 往 都 是 与 具 体 的 实现 环 境 有 关 ,换 了 一 个 环 境 就需 要 作 一 番 改 动 ,耗时 费 力 ,而 Java 语 言 能 在 执 行 码 (二 进 制 码 )上 兼 容 ,这 样 以 前 所开 发 的软 件 就 能 运行 在 不 同 的 机 器 上 ,只 要 所 用 的 机 器 能 提供 Java 语 言 解 释 器 即可 。 Java 语 言 将 对 未 来 软 件 的 开 发 产 生 影 响 , 可 从 如 下 几 个方面 考 虑 :
1 软 件 的 需 求 分 析 :可 将 用 户 的 需 求 进 行 动 态 的 、 可 视化描 述 ,以 提供设 计者 更 加 直 观 的 要 求 。 而 用 户 的 需 求 是 各色 各 样 的 ,不 受 地 区、 行 业 、 部 门 、 爱好 的 影 响 ,都 可 以 用 Java 语 言 描 述 清 楚 。
2 软 件 的 开 发 方 法 :由 于 Java 语 言 的 面 向 目 标 的 特 性 , 所以完 全 可 以 用 O-O的技 术 与 方 法 来 开 发 ,这 是 符 合 最 新 的 软件 开 发 规 范 要 求 的 。
3 Java 语 言 的 动 画 效 果 远 比 GUI技 术 更 加 逼 真 ,尤 其 是 利用WW W提 供 的 巨 大动 画 资 源 空 间 ,可 以 共 享 全 世 界 的 动 态 画面 的 资 源 。
4 软 件 最 终 产 品 :用 Java 语 言 开 发 的 软 件 可 以 具 有 可视化 、 可 听 化 、 可 操作 化 的 效 果 ,这 要 比 电 视 、 电 影 的 效果 更 为 理 想 ,因 为 它 可 以做 到 "即 时 、 交 互、 动 画 与 动作 ",要 它 停 就 停 ,要 它 继 续 就 继 续 ,而 这 是 在 电 影与 电视 播 放 过 程 中难 以 做 到 的 。
5 其 它 :使 用 Java 语 言 对 开 发 效 益 、 开 发 价 值 都 有 比 较明显 的 影 响 。
三 、 工 业 界 对 Java 语 言 的 评 价
19xx年 5月 29 ～ 31日 ,在 美 国 旧 金 山 召 开 了 一 个 全 世 界 Java语言 开 发 者 大 会,(JavaOne Developer Confer-ence),出 席 会 议 的 多 达 6500多 人 ,来 自 工 业界 的 超 过 一 半 ,有人 评 价 说 :"这 是 近年 来 计 算 机 界 最 光 辉 的 一 次 盛 会 ",一 些 工 业 界 的 老 总们 相 当看 好 Java 语 言 ,认 为 它 的 使 用 将 会 引 起 一 场 软 件 革命 。 从 软 件的 设 计 风 格 、 设计 方 法 、 设 计 目 标 到 设 计 过 程 ,都 会 产 生 彻 底 的 变 革 ,"甚 至 会改 变 此 星 球 的 生活 方 式 "。
在 这 次 会 上 ,Java的 创 始 人 之 一 James Gosling 说 :"Java 不仅 仅只 是 applets, 它 能 做任 何 事 情 ",Dta 咨 询 公 司 的 高 级软 件 工 程 师 Rich Kadel说 :"Java 不仅 仅 是 一 种 程 序 设计 语言 ,更 是 现 代 化 软 件 再 实 现 的 基 础 ;Java 还 是 未 来 新 型 OS的核 心 ;将 会 出 现Java 芯 片 ;将 构 成 各 种 应 用 软 件 的 开 发 平 台与 实 现 环 境 ,是 人们 必 不 可 少 的 开 发工 具 "。
由 于 各 界 都 看 好 它 ,因 此 ,各 大 公 司 都 纷 纷 表 示 支 持 Java,Inte l、 Xerox公 司 声 言将 把 Java嵌 入 到 他 们 的 产 品 中 去 。 就 连 华尔 街 金 融 界 也 在 投入 资 金 人 力 用 Java开 发 电 子 贸 易 、 金 融软 件 。
所 以 有 人 说 :"现 在 第 三 方 的 开 发 商 都 团 结 在 Java大旗 周 围了 !",纷 纷 推 出 用Java 开 发 的 各 种 软 件 产 品 ,以 期尽 快 地 占 领 市 场 。
四 、 Java 语 言 的 应 用 前 景
Java 语 言 有 着 广 泛 的 应 用 前 景 ,大 体 上 可 以 从 以 下 几 个方面 来 考 虑 其 应 用 : 1 所 有 面 向 对 象 的 应 用 开 发 ,包 括 面 向 对 象 的 事 件 描 述、处 理 、 综 合 等 ; 2 计 算 过 程 的 可 视 化 、 可 操 作 化 的 软 件 的 开 发 ;
3 动 态 画 面 的 设 计 ,包 括 图 形 图 像 的 调 用 ;
4 交 互 操 作 的 设 计 (选 择 交 互 、 定 向 交 互 、 控 制 流 程 等 );
5 Internet的 系 统 管 理 功 能 模 块 的 设 计 ,包 括 Web页 面 的 动 态设计 、 管 理 和 交互 操 作 设 计 等 ;
6 Intranet(企 业 内 部 网 )上 的 软 件 开 发 (直 接 面 向 企 业 内 部用户 的 软 件 );
7 与 各 类 数 据 库 连 接 查 询 的 SQL 语 句 实 现 ;
8 其 它 应 用 类 型 的 程 序 。
java初学者入门诀窍 新手必看
一、重视接口
在面向对象早期的应用中大量使用了类继承。随着软件工程理论的不断发展，人们开始意识到了继承的众
多缺点，开始努力用聚合代替继承。软件工程解决扩展性的重要原则就是抽象描述，直接使用的工具就是接口。接口近年来逐渐成为Java编程方法的核心。另一方面，就应用而言，大部分开发是建立在规范基础之上的，不需要自己建立复杂的继承关系和庞大的类。因此读懂规范和用好规范已经成为应用程序开发人员的首要任务，Java各项规范的主要描述手段就是接口。
二、了解网络编程
Java号称是最强的网络编程语言，但是大多数应用程序开发人员是从来不会自己开发什么底层的网络程序的。需要做只是了解原理就够了。网络机制的实现是靠平台实现的，除非自己开发平台，否则是不需要知道socket怎么实现，怎么监听访问的。因此在这方面花太多的功夫就偏离了"将来的应用开发是在成熟的平台上展开，而不是自己从底层开发平台"这一假设。
三、多线程需要理解机理
很多Java程序员热衷于多线程程序编写，认为是对逻辑能力的挑战。其实在大量应用中根本就不需要编写多线程程序，或者说大多数编写应用程序的程序员不会去写多线程程序。这是因为多线程机制都内置到基础平台当中了。程序员应该了解的是多线程原理和多线程安全，这对于今后准确地把握程序是至关重要的。例如JSP中编写到不同的位置对于多个用户环境的安全影响完全不同，又如着名的Super Servlet是每一个访问作为一个进程，但是每一个页面是一个线程，和Servlet正好相反，对程序的性能和安全的影响有天壤之别。
四、学好集合框架
Java描述复杂数据结构的主要方式是集合框架。Java没有指针，而是通过强大的集合框架描述数组、对象数组等复杂的数据结构。学好这些数据结构的描述方法对于应用程序编写，特别是涉及到服务器方、3层结构编程至关重要。程序员在这个时候不能再用诸如数据库结果集之类的结构描述数据了。由于很多语言没有这么强大的集合框架体系，很多初学者不知所措，更不知道拿来做什么用，因此应该引起足够的重视。
五、掌握静态方法和属性
静态方法和属性用于描述某一类对象群体的特征，而不是单个对象的特征。Java中大量应用了静态方法和属性，这是一个通常的技巧。但是这种技巧在很多语言中不被频繁地使用。理解静态方法和属性对于理解类与对象的关系是十分有帮助的，在大量的Java规范中，静态方法和属性被频繁使用。因此学习者应该理解静态方法和属性。Java在方法和属性的调用上是一致的，区别只表现在声明的时候，这和c++是不同的。
六、例外捕捉
Java对例外捕捉的强调是空前的，它强迫程序员用显着的与逻辑方法完全不同的方式描述例外捕捉，对于程序描述的完整性和严谨性有很大的意义。c++也有类似的机制，但是我们看到很多c++程序员并不习惯使用这些机制。Java的初学者应该充分学习好这种例外捕捉机制，养成良好的编程习惯
关于《Java封面》一些感想
今天正好看了一篇文章 《Java封面》 ,初次一看，觉得这个貌似很这个说的完全都不靠谱啊，再一看，原来是20xx年写的，然后在看看作者，发现原来是 硅谷创业教父 Paul Graham写的，联想到之前看到他写的一本书《黑客与画家》，突然能够明白为什么他这么认为java前途了。
java语言是在 19xx年发明的，当初只是为了做一些机顶盒相关的应用，设计的也比较简单。那个时候java并不出名，java之所以比较火爆，就是因为互联网的发展，是由于当初的在浏览器里面能够运行java编写的小程序applet,你想想，那个时候互联网才刚开始发展，能够在网页上面运行动画，是多么牛逼的东西，由于当初java非常火爆，导致javascript 这门语言，想和java搭上关系，其实完全和java一点关系都没有，当初我学习javascript的时候，我一直好奇的是，这门语言完全和java没有关系，干嘛启用这么一个名字。
由于互联网的快速发展，微软出了asp的网页编程语言，记得当初我走B/S道路的时候，就是因为学习了asp这一门语言，发现能够做出东西来产品，比当初学习c和c++只能够写出hello word 这样的编程语言相比，它有趣多了。这个时候java也出了相关的网页编程语言jsp,然后慢慢的推出java三个平台，j2me,j2ee,j2se,分别定位移动平台，企业平台，客户端平台。
我初步觉得 Paul Graham 之所以当初对java有如此的认识，其实和当时所处的时代有关。当初的互联网刚刚起步，社会对互联网的认识才刚刚开始，当时的网速也不快，大多数复杂的企业应用都是采用的C/S模式，还没有慢慢步入B/S模式，而目前java主要运用都是在企业软件里面，现在大多数企业应用都是建立在B/S模式上的，所以说还是互联网成就了java.
现在来看看，作者当时的很多想法，应该是错误，
比如说着说：真正的标准是不是需要推广，相反，现在的标准之争原来越频繁，很多IT大佬在左右的IT编程语言的发展。一个标准推出的好处就是减少重复和浪费，就像操作系统，如果只有一个标准，大家都按照这个标准做，就不会出现为每个厂商就做一个操作系统软件，造成极大的浪费，幸好互联网定义了http标准协议，否则我难以想想互联网是什么样的。
Java的目标太低：我看了黑客和画家，作者是一个典型的geek主义者，认为程序员是一个对技术要求很高的职业，要有喜欢挑战的精神，是一个典型的个人主义者。而java太简单。但是相反，随着IT技术的发展，对编程的要求不在那么高，只需要受过一个普通教育的人也能够开发出来很好的应用的人，编程只是一个实现功能的方式，要求越简单越好，越简单生产效率越高，而简单的东西才能流传的更久和更广。 Java 动机不纯：这个我觉得真的没有什么好说的，对付微软很正常，如果有市场就行，微软还不是最后出了。net来对付java.开始java只是为了解决机顶盒问题的，后来发现java的这种设计思想非常不错，可以解决很多问题，最大的好处就是跨平台。慢慢的就往更多的领域发展。
Java 有太多维护人员：java被一个委员会所维护，其实也不叫维护吧，这个委员会（JCP）只是规划java的未来的发展方向以及给java本身添加一个功能，我觉得java最大的特点就是 定义了一个功能，但是不管这个功能是如何实现的，只要满足功能的规约。所以我觉得学习java最大的一个特点就是规范，你会发现一大堆规范，最常见的就是 java虚拟机规范，规范主要是讲解要做什么，限制是什么，产生什么结果等等，并不关心怎么实现。
官僚作风太重：这个比较有意思，仁者见仁，智者见智吧。java的确会有一大堆规范，比较不适合 geek,但是比较适合软件这个行业。如果有一大堆规范，那么每个人都会按照这个规范去做，每个人写出来的程序差不多，对于大型IT企业是很喜欢的，毕竟替代一个程序员的代价很低，大家的思想都差不多。
后面的几点我觉得都有点牵强，但是从作者的观点也可以看出来 对于码农的认知是不同。至少看完了《黑客与画家》，我发现作者是有强烈的黑客情节的（hack the problem），作者对于程序员的认识和现在对于程序员的认知应该是不同的。其实这个也是我最近在思考的一个问题：程序员的价值是什么。随着软件开发行业越来越公开化，开源世界的影响越来越大，程序资源也越来越多，很多功能的实现都有特定的开源帮助我们来实现，我们可以随时拿来用，以前我们的思维是如何实现这个功能，那么现在变成有没有类似的解决方案可以拿来用，程序员原来越偏向一个程序组装者或者解决方案者，那么程序员新的价值在那里 ?
十八年开发经验分享（一）学习篇
很偶然的写了一篇博文“十八年开发经历小结”，本来打算只是简单回顾一下自己经历。结果没想到被CSDN放到了首页，反映也还可以，感兴趣的可以访问我在CSDN上的博客，点击这里，或者访问我在博客园上的博客，点击这里。既然我写的东西还有人愿意看，于是我就萌发了再写一个系列的文字的想法。从第一次在CSDN上获得帮助，第一次在CSDN上帮助别人，一直到现在，期间帮助和被帮助已经很多很多次了。我认为专利和知识产权是独占并被保护的，但是经验和知识是应该分享的。为了这十八年来的帮助与被帮助，为了我写的文字还有人愿意看，我想写出这个系列来，与各位同行分享自己的经验，共同进步。这个系列的内容主要来自个人的实际经历，我不想谈一些什么经典或者范例的东西。我觉得自己体会到的东西和同行分享才更有意义，也更具有实用价值。同时我相信写出这个系列的文字，也是我对自己经验的一个认真的回顾和归纳，这一定是很有裨益的。
作为本系列的第一篇，想谈谈程序员的学习问题。之所以第一个要谈的问题就是学习，是因为我觉得这个问题最重要，也是最让相当一部分程序员比较犯愁发憷的问题。本文如果能给这部分程序员带来一点帮助
或者启发，那么目的就达到了。学习问题在那篇小结中写了一小段，这次可以相对较为详细的谈谈这个问题了。
既然要谈学习，那么首先需要明确一个问题，我们打算学什么？这里先对这个纷繁世界中的知识做一个分类：
A.教材上的知识
这部分内容来自计算机专业的课程教材。也有可能会涉及一部分来自其他相关专业或者相关课程的内容。
B.编程语言
每一个程序员只有在会使用一门语言的情况下才有可能从事开发工作，所以学习并掌握一门语言是最低要求了。
C.SDK
光有一门语言是不够的，从事任何实际的软件开发都需要一个类库或者开发包才可以完成。比如C语言中的库函数，C#中的.NetFramework类库，Windows的API等等就属于这个范畴。
D.开发工具
以如今的情况来说，没有开发工具理论上也是可以开发软件的，但效率就是一个问题，所以掌握并使用一个开发工具完成开发任务应该也是一个最低要求。
E.领域知识
软件总有用户，于是开发这些用户使用的软件，那么程序员就需要了解用户所在行业的知识，至少需要知道一些基本的必须的知识。还有一部分的内容也划分为领域知识，比如从事Photoshop这类软件的开发那么图形相关的知识就必须了解一些，从事工控软件的开发，那么对控制方面的知识也要有所了解。
以上的分类是在本文中我对知识的理解，一个程序员知道这些知识后从事一个软件的开发应该是没有问题了。下面分别来讨论一下这些知识的学习问题。
一．教材知识的学习
做为一个已经从业的程序员来说，我不认为计算机专业的所有专业课程（包括专业基础课，我在读大学的时候还有这个说法）都是有用的。实际上对于大部分程序员来说，只需要很少的一部分知识就足够了。这些知识主要由三门课程组成：数据结构，编译原理，操作系统。对于大部分的程序员来说，其他课程的内容不是没用，而是在实际工作中用不上。
数据结构这门课程的重要性，可以理解为是程序员的圣经，怎么如何形容其重要性都是不过过分的。这门课程中需要掌握的内容，我个人观点如下：
1. 掌握所有线性数据结构的知识，比如表，栈，队列等（广义表可以不作要求）
2. 二叉树的基本操作和基本使用
3. 图中需要知道遍历和了解最短路径算法，以及相关的一些概念
当然对于某些程序员来说，这是不够的，因为从事的具体的软件开发工作会有不同的要求。但是对于大部分从事MIS软件开发的程序员来说，这些知识够了。掌握这些知识可以有两个层面的要求。第一个是完成足够的习题，从而可以熟练的答题，第二个是能够在实际工作中使用数据结构描述实际的事物。做到这两
点要求应该说不算太高，注意多加练习就可以了。目前来说这门课程的经典教材也不少，相信只要按部就班的学习完就是合格的了。
编译原理这门课程主要是学习方法和思想而不是课程中的知识本身。因为毕业出来能从事编译器开发的人实在是太少太少了。这门课程需要掌握了解的东西不多，我个人的观点主要是以下几个：
1. 确定有限自动机和非确定有限自动机的使用
2. 词法分析程序的实现
3. 语法分析的方法
自动机在实际应用中的体现就相当于是状态转换图，这个工具非常的重要，希望能够务必掌握。我们在开发EntityModelStudio时，设计界面交互部分的内容就是先设计出状态转换图然后再写代码的，否则直接开发的话就会面临开发失去控制的风险，同时重构和维护也会相当麻烦。所以这个工具极其强大，非常实用。另外提一下，非确定有限自动机，这个工具的能力和确定的有限自动机是等价的。但是由于它的不确定性，更符合人的自然思维习惯，从而在某些设计场合相对会方便很多。这一点是很实用的，也是很吸引人的。 掌握词法分析程序的实现，可以大幅度拓展开发能力和思考能力。这部分东西理论上描述可能比较麻烦，但是实际使用时还是很容易上手的，所以非常值得学习一下。语法分析程序不需要掌握了，毕竟开发编译器的机会是微乎其微的。但是相关的方法和思想希望能够了解，这可以帮助程序员用电脑的思维来思考问题。
操作系统需要掌握的东西只有两个：
1. 五大管理的基本方法，尤其是涉及内存管理的策略
2. 线程或者进程的同步技术
操作系统是复杂的，但是教材中介绍的这些管理方法相对来说是简单易懂很多了。这一难一简之间体现了基本知识的重要性，基本知识在实际开发中的应用的广泛性。好好的体会，就可以明白用简单方法解决复杂问题的技巧。线程进程的同步，这个就不用多说了，大家都知道它的作用，如果实在不想掌握的话那我也非常愿意相信你的理由一定是充分的，否则你绝对不会那么做。
最后我想强调的是，无论你如何看待这些知识：可能觉的没用，可能觉的太难，可能是不感兴趣，但是如果你想做程序员的话，那么请你务必最大可能牢固，最大可能熟练的掌握它。
二．编程语言
对于一个程序员来说，一般需要掌握2,3门语言是基本的，并且学习一门新的编程语言也是基本功级别的能力，所以这部分主要谈谈快速学习一门新的编程语言的方法。我学过的语言有这些（这里编译器和语言的概念等同了并且不按先后次序）：Foxbase，C，C++，汇编，Visual C++，Delphi，FoxPro，VB，C#。就我个人的体会来说，这些语言可以分为三种类别：非面向对象的，面向对象以及支持可视化设计的。 这三种类别的语言有一些共同的内容，而这些内容也是我们在学习一门新的编程语言时首先需要知道的，可以说是关键的知识点。这些内容大致如下：
1.常量，变量，数组，不同的数据类型
这部分需要掌握常量，变量，数组的定义，初始化，不同数据类型的使用。数组中元素的读写，作为参数如何定义，作为返回值如何定义。有些语言还支持数组大小的重新定义。
2.函数（或者叫子程序）
函数如何定义（比如参数和返回值），如何调用（这里存在异步调用和同步调用的问题），全局的还是非全局的。
3.流程控制
分支结构：if语句，if else语句，switch语句；循环结构：for语句，while语句，do…while语句，有些语言可能是Loop。
4.最基本的输入输出和文件操作
最基本的输入输出语句可以帮助你在学习语言的过程中完成简单程序的练习任务，比如：输出到控制台，dos操作系统中输出到屏幕等等。文件操作也要知道，至少以后写个程序生成日志文件就会了。
以上内容在学习一门新的编程语言时，希望能首先掌握，这能让你很快的入门，并尽快使用新语言写出代码。另外还可以关注一下其他方面的内容，比如：
1.了解语言的新特性
这个阶段只需要了解，不需要掌握，记住有这些新特性，在需要用的时候想起它们就可以了。
2.了解一下帮助文档中，该语言的所有关键字
这部分内容有可能让你发现一些很有用的东西。
好了，知道这些内容差不多一门新的语言就算入门了。当然还有其他很多东西，但是这些内容可以在具体开发中遇到时再去找例子就可以了。下面谈谈这些语言的差异。对于面向对象的语言来说，需要知道面向对象三大特征：封装，继承，多态在具体的一门编程语言中是如何表达的或者等价表达的。对于支持可视化设计的语言来说，还需要知道如何设计窗体，以及常用控件的使用。按照这个方法，从一门已经会的编
程语言到学习另一门新的编程语言应该是比较快的。对于还在大学中学习的人来说，我的建议是C++或者Pascal中的一个，VB或者C#中的一个或者其它可视化开发语言中的一个学习一下。如果可能学习一下汇编是最好的。
三．SDK
掌握一个SDK才能使程序员在掌握一门语言的基础上进行实际的开发，如果仅仅是一门语言那是不够的。所谓SDK举例子来说就是Foxbase的命令和函数，C的库函数，C++的类库（比如微软的MFC），Windows的API，.NetFramework，这些都是我所说的SDK。程序员可以根据自己的实际开发需要，有选择的学习相关的内容。我的建议是，可以先google，然后查文档，一般的问题都可以很快解决的，慢慢的也就逐步掌握了。比如说我不知道C#如何使用线程，那么我就用google查找，关键词是“C# 线程”，然后从结果中找到需要的内容。很多时候结果中的代码是可以直接使用的。然后再去看一下MSDN的帮助文档，了解一下相关的类和方法的说明，这样这部分的知识就可以认为是掌握了。下次使用时就知道怎么用了。我的C#就是这么入门的，大概google问了二三十个问题左右。
另外一个建议是买一本书学习也是可以考虑的，这也是一个不错的方法，只是买到好的书需要缘分。就我个人来说，绝大部分的情况下是看电子书，直接从网上下载的。
四．开发工具
除非你只用独立的文本编辑器写代码，并且用命令行编译，否则你一定需要一个开发工具，尤其是一个带IDE的开发工具。对于你使用的开发工具而言，需要了解的基本内容如下：
1. 项目或者工程的创建，属性修改，打开关闭等基本操作
2. 具体开发时的环境设置
3. 项目中的文件组织及管理
4. 常用功能的使用，比如：编译，执行，断点设置，代码跟踪，调试信息输出，实用的快捷键，调试时变量查看，查找/替换等等
5. 从帮助文档中了解IDE的新功能。因为这些功能有可能对你是非常有帮助的。
6. 帮助文档的获取
如果有自己的使用习惯的话，还可以了解一下如何定制IDE环境以满足自己的开发习惯。首先了解这些内容可以帮助你相对快一点适应一个新的IDE。
五．领域知识
一个从事技术工作的程序员需要了解与技术不相干的领域知识，确实有点无奈。但是在具体的开发中，不了解这些知识就无法更好的理解用户的需求，也无法更好的完成开发任务以及与同事领导的沟通。所以这个步骤是重要的必要的，有时候有可能还会带来更严重的后果。在有些项目中如果不能很好的了解这些领域知识，项目中的成员有可能会被替换掉，我个人就有过这样的经历。所以这里特别列出来强调一下。 差不多这些知识应该够用了，下面再提几个额外的内容，这几点虽然和开发不是太直接相关，但是确实也很重要。它们是英语，数学，读源代码和读书，有余力的程序员可以尽量提高这几方面的水平，这是很有用的学习途径和方法。对于英语而言主要是读和写，这样就可以阅读英文资料并用邮件，论坛或者聊天工具和老外沟通。由此获得的帮助是非常显著而高效的。这里要说明一下，微软论坛上的回复的质量非常之高。
对于数学我的理解主要是三个部分，都是很具体的：
1.中学里学过的知识
这部分知识很重要，这是我们用简单方法解决复杂问题的基础，同时使用的几率也非常高。如果全部忘记的话，建议多少复习一下，或者用到的时候回顾一下。
2.离散数学
我需要承认在开发中直接使用离散数学知识的场合我一次都没有遇到，但是如果没有离散数学的知识，那么我就无法思考，很多问题就无法解决。
3.组合数学
这门课程属于研究生级别了，相对难度会大一些。我的观点是你不需要全部掌握，知道一部分就可以了，比如：鸽巢原理，母函数，以及常用的计数方法和技巧。尤其是技术方法这部分在问题的分析简化，工作量的评估，算法设计以及软件测试方面都有非常实用和具体的应用价值，是很值得掌握的。是否可以使用这部分知识，在实际工作中表现出来的效果至少相差一个等级。
一个好的源代码具有不可估量的价值，潜心学习一下可以让你从一个门外汉变成一个开发老手，所以注重培养从读源代码学习编程知识的能力。我的体会是，阅读源代是一个非常有效（有用并且高效率）的方法来提高自己的开发水平或者解决实际问题的能力。我第一次认真学习的源代码来自当初的程序员大本营。一个例子是实现Visual Studio 6.0中Workspace的界面，另一个是如何实现给主菜单加入图标。两个例子大概花了我一个半月的时间并且写了几篇心得，记录下学习的内容。应该说收获很大。再比如，下一个版本的EntityModelStudio中会加入代码编辑器，这个支持语法高亮和行号的编辑器就是在读懂开源代码后我们自己独立重新开发的。在阅读源代码的时候希望能注意两点：
1. 最好能配置好环境可以单步跟踪代码，这样理解代码的速度和效果会好很多。
2. 快速的定位那些自己想看的代码。这里建议可以使用IDE提供的查找功能，看文件名，类名等方式来定位。如果实在不行，考虑注释代码，来快速定位。
第四个内容是读书，阅读是学习的一个最基本和最重要的途径。在这里我不想列出任何需要阅读的书目，这是因为当下流行的所谓经典或者著名的开发书籍我读得很少，所以也说不出体会。我看过的书都比较老了，比如：
1. BorlandC++4.5使用及开发指南
这是我的C++的教材，C++部分先后看了不下6次
2. 一本19xx年发行的软件工程的书，这是我第一次接触软件工程
3. 代码大全第一版，我觉得第二版没有第一版好
4. 用于面向对象的设计和分析方法，这是美国哥伦比亚大学的一个教授写的。是清华大学原版教材中的一本，非常好，是OOD的绝好教材。
目前有印象的就这些，以后想到了再补充吧。其他读过的书还有很多，都是具体的编码的书就不再一一列举了。有些书需要仔细阅读的，比如讲设计，讲方法的书，有些书需要很快的浏览完，比如讲具体编程的书。我的体会是，一本几百页的书，你应该花1,2小时就能过一遍，最好是20分钟到40分钟就能过完。在实际开发中，用到的时候再看书，查找需要的内容。如果你需要花很长一段时间全部学完一本书的话，那么你看的第一本书可以这样，否则我觉得你的学习方法就有问题了。至少一本书中不可能所有的东西都是你马上要用到的，你没有必要立刻学习，所以应该学会快速阅读的技巧。当然这是个人观点，取舍对错自行判断吧。
你不能寄希望于一次就能买到一本理想的书，也不能希望在一本书中学到自己需要的所有内容。遇到一本好书是需要点运气和缘分的。我的总体感觉是，外国知名出版社的图书的质量明显好一些，还有台湾一些出版社的图书也还不错。建议大家可以买一些绝对知名和权威的书籍，这样相对风险会小一些。对于那些书名为XXX大全，XXX宝典，精通XXX，XXX权威这样的书，我是很不看好的，当然这是自己的看法，仅供参考。
最后说一下不要学习的东西，这是在本文发布前刚发现的问题。几天前在群里聊天，一个人说想解析暗黑的通信协议，然后做外挂。我对这方面很不在行，但是这明显是一个非常耗费时间，难度也非常大的事情。我在这里给出的建议是，一个职业的程序员需要知道自己的价值，自己的知识和精力应该花在能够创造实际价值的地方。不要仅仅出于爱好或者热情去做一些成本很大的事情，与其炫耀自己的能力，不如踏实的做好本职工作。如果实在想做可以作为业余爱好，适可而止。
好了这次就写到这里了，感觉还是有点仓促。再次声明以上内容都是一些个人的看法，限于本人的经历和知识面，不妥或疏漏之处在所难免，希望同行们能指出来，让我也提高一下。下一篇的题目暂定为“问题解决篇”，主要介绍如何在工作中使用这些知识解决实际问题的方法和心得。
成功的软件开发思维导图
这是惊人的，当一群人站在白板上，抓住一些标记和启动心智图。他们认为新的实验解决一个棘手的问题。他们找到更好的设计解决方案的软件特征。他们确定重要的测试用例，否则有可能被错过。心智图做魔术。 如果你的软件团队并未用尽心智图来帮助计划的主题，设计方案，建立一个测试策略，或写用户文档，它值得你花时间学习如何简单地你可以开始。
心智图的特点，主题，史诗
尝试踢了你的下一个主要特征或主题的心智图。找到一个空间，一个大白板。经营专家聚集在一起，最终用户，程序员，产品经理，业务分析，测试，专家数据库，系统管理员，每个人谁将参与在提供或使用的软件。如果你的项目的地理分布，替代网络白板，允许实时并行协作和投影仪或巨大的监视，以及良好的语音和视频连接。
如果一个产品或其他利益相关者已经知道什么是需要的特点，她可以准备一个白板提前为起点。这可以节省时间，帮助集中讨论。白板可以很容易地改变，使每个人都感到自由修改建议。
这是一个白板（下）从主题策划团队进行了讨论。该产品拥有了广泛的心灵地图提前时间。他用彩色编码显示的用户界面功能，其他受影响地区等系统中文件，和未来可能的功能，我们应该记住。
有这么多的信息已经可以，会有一个快速启动。我们很快确定我们需要考虑其他领域，如基础做提前的时间，发展的需要，和审计要求。我们讨论每一个分支的心灵地图反过来，添加或删除节点。约一小时后，每个人都在发展和客户团队共享一个广泛和深刻理解所涉及的工作，提供必要的功能。
主题需要改变的一个基本组成部分，我们的数据模型。我们认为这将是困难和危险，而我们估计的故事只是部分“工作”13个故事点。
在会议结束时，一个开发商正在研究心灵地图，并有一个突然的风暴。他想出了一个简单的方法来实现新的模型，并将它在右上角的白板。带大小的故事从13下降到三点。他确信他将不会有，集思广益，如果我们不使用心灵地图可视化的工作，我们需要做的。
我们称这种心智图在未来几个冲刺为我们提供故事为主题。我们检查了该节点的工作已经完成，所以我们可以一眼看出有多少工作是左。它帮助我们留在轨道。客户的满意，我们释放到生产成品。
心智图测试功能或主题
我发现心智图是特别强大的援助在测试计划。这个过程是类似的心智绘图软件的功能。理想的情况下，让所有的人在一起，但集中讨论测试：我们如何知道我们提供所有需要的功能？对于这个问题，我们如何知道我们所想到的所有功能，用户需要吗？表达测试用例和场景节点和关系的心智图是一个伟大的方式扩大测试的想法。
一个有利于使用心智图是一个时机问题。它可以很难找到利益相关者的时间为多个会议。测试人员可以表达他们的测试思想与心灵地图，然后审查它与开发商，业务专家，与其他项目团队成员。甚至当心灵地图只是“有点”，有助于开发小组成员（其中有些是善于抽象思维没有视觉艾滋病）很多用户反应最佳视觉线索和图纸。这可以帮助他们理解的关系–，顺便说一句，帮助他们兴奋的软件建设为他们服务。
心智图可以帮助你考虑额外的功能测试，如可用性，安全性，性能，和稳定。工艺画脑图面关系，否则可能仍然隐藏。不同的用户可以使用不同的特点以独特的方式。你可以开始你的探索性测试与心智图。 视觉线索的心智图帮助确定所需资源。一个新的主题可能需要新的测试环境。硬件和软件是必要的？你将如何得到或生成测试数据？主题策划是最好的时间来思考如何测试应该是自动的，什么是需要完成。 我的团队尝试不同的心智图媒体。在白板上绘图是最有效的脑力激荡。下图显示一个测试样本主题地图。我们收集的问题，开发人员和业务专家的董事会以及。每天早上，我们回顾一天的活动和问题的测试的心智图。
但是，虽然我们一直在拍照的白板和张贴在我们的团队，这是有时很难找到一个心灵地图从先前的版本或迭代。我们开始再现白板心智图在网上，协同心智图工具。我们使用颜色编码和图标的跟踪测试，因为它开始，标志着“绿色”测试。心灵地图给即时视觉图片的项目的进展。
心智图法在较低的水平
当我们深入到细节的用户故事，心灵地图帮助代表不同的情景和排列进行测试。我们可以评估的测试可以做到在原料药或服务水平，而且必须是在图形用户界面的水平。我们集思广益，最简单的方法测试业务逻辑以及用户体验。心智图可以帮助我们创造更多的途径探索软件。
测试者可能心智图story-level测试个别个案，但我发现它是好的工作对。
审查所产生的测试案例和战略与客户和开发商。与更高级别的脑图的过程，思维导图提供最大的价值，帮助我们充实的每一个细节特征和用户故事。它有助于保存信息通过图片的心智图在白板纸，或链接到心智图做线上心智图产品。
在我的经验中，心智图是一个伟大的方式，把测试用例验收测试驱动开发或规范的例子。在我目前的团队，我们尝试用思维导图的需求和测试案例的形式为每个用户故事的小例子。然后我们把那些可执行的，但仍然可读，测试使用rspec。
在我最后的团队，我们测试颜色编码节点在线地图跟踪测试进展每个用户故事。我们出口了心灵的图片，地图和连接到用户的故事文档。这些是有用的，如果出现奇怪的行为，特别是如果问题是年后的新特点是。思维导图成为一个有价值的知识基础。
探索
我发现记住地图特别有用当我探索出一套软件，我不熟悉的。这里的一个例子，从我第一次上的测试会议。上（或者，更常见的是，周末）测试是测试机会合作测试一个应用和交换技术和理念。我们这届是测试tinyurl.com。
我的搭配戴伦麦克米伦，专家测试在英国我们决定开始集思广益的测试案例共享心智图，使用网络浏览器的心智图工具。当我们进行测试，我们更新了心智图图标显示的通过和失败的测试，增加了新的测试，我们认为他们，并注意到了什么，我们知道我们测试，和问题，我们有。这里是由此产生的心智图：
心灵地图帮助我们组织我们的测试，我们去。它也帮助我们确保我们没有失去任何想法，多个地区的应用探讨。另外，它保持了历史，使我们很容易解释我们所做的其他参与者在de-brief部分的会议。
最近，对开发团队搭配我尝试创建一个框架，验收测试驱动开发（又名规范的例子）。我们选择了一个用户故事，我们要拿出例子的理想和不受欢迎的行为，并把这些可执行的测试，帮助开发人员知道什么代码。 我们首先把规格的故事为节点的心灵地图。心智图使我们注意到之间的关系不同的组件与行为。我们写测试用例，其中简要说明的先决条件，行动，和预期的结果。我们使用这些测试用例的测试脚本，使用rspec-based框架。
这里的一个例子。一个测试案例在我们的脑海地图：“把一个有效的面板，验证得到的回报只是一个面板。”测试用例脚本读取：“{ one_panel_in_stored_layout response_lists_that_panel；}。这是很容易理解的。每个snake-cased短语源自我们的心智图的测试用例是实际测试的代码执行的自动化测试。
以供将来参考
也许最大的价值思维导图给我们是他们的方式促进合作。他们帮助我们产生想法不可能想象。视觉代表软件的功能要求和试验情况，有助于我们了解组件之间的关系和行为。心智图是有用的，太，当我们需要改变的特征，或当我们只是想更好地了解它是如何工作的。他们给了一个“大图片”的主题，用户的故事，或测试计划。
该设备所需的心智图是简单的。可能性的创造性使用颜色编码，图标，图片都是无止境的。
如果你创造心智图在白板纸，他们拍了照片，并让他们可以在你的团队的维基。一定要联系他们的功能测试文件。确保他们可以很容易地发现，后来。你会惊讶你可以从心智图年后它被创建。
理解Java应用服务器的七种武器
在意识到软件架构的重要性后，应用服务器必然成为程序员的一件必不可少的“武器”.对应用服务器技术的透彻理解可以为程序员提供认识软件架构的更大的空间，这种方式影响着软件工程学文化。它接下来会用一些有用的工具来武装现代的IT人，提升价值链。
本文标题中出现的数字七只是能够让我们同时记住的条目数量--我不希望给读者的压力过大。
第一种武器：信心？？理解应用服务器并不困难
某些技术创造自己的传奇的方法是很有趣的。我还记得自己在作为程序员时处理包含源代码注释（例如“不要放入此处”或者稍微文雅一点“此处危险”）的产品。我们感觉非常复杂的代码是不可管理的。应用服务器也成了相似的情况，人们毫无理由地恐惧的领域。在市场上，很多雇主把人们对于应用服务器的应用知识作为强制性的工作要求。实际上应用服务器并不是很复杂。例如，Sun微系统公司在自己的基于J2EE的应用服务器中包含了大量的文档信息。你甚至于可以免费java它，并在一个很基本的windows XP专业版计算机上运行那些优秀的示例。
Sun的教程记述了大量的代码示例，演示了J2EE和该公司的应用服务器产品的优势和易用性。阅读这些文档是有价值的，因为它为我们洞察这种极其重要的软件技术的工作情况提供了入口。Sun的竞争者还有BEA、IBM和开放源代码应用服务器JBOSS.
BEA甚至于把应用服务器作为它的“透明计算”的第一步。它具有面向服务的架构的优点，在面向服务的架构中，我们可以利用旧的和新的应用程序来简化不断增长的敏捷型组织对服务的需求。BEA的观点是可能出现一种情况：公司改变它们的IT系统和业务流程可以像从一个应用程序中剪切数据然后粘贴到另一个应用程序中那样简单。其要点在于这种努力是基于应用程序服务器技术的。
很明显，应用服务器是成熟的软件工业中的重要元素。它们内容丰富，并且依靠集中的应用程序管理，允许数据的集中存储。这种技术是可以使用并且不难理解的。
第二种武器 平台性？？应用服务器是一种软件平台
应用服务器趋向于减少企业需要的中间件数量--因为它们是中间件！与包含了防火墙的windows类似，应
用服务器可能吸收一些现有的中间件产品所扮演的角色。这是因为应用服务器自身就是用于软件部署以供多个客户端使用的平台。在应用服务器中使用的软件有截然不同的生命周期，包括：
开发者建立应用程序或组件
包装成可部署的元素
部署在应用服务器平台上
被最终用户使用
在再次部署中由开发者更新特性或修补
应用程序达到使用寿命后期的时候收回
在很多情况下，它与“正常的”应用程序软件的管理方式是不同的。这一点对于多层分布式软件系统尤其突出（在这种情况下客户端用户与后端服务器应用程序交互操作）。应用程序服务器与多层软件应用程序套件之间最主要的区别在于，应用服务器提供了大量的软件包装支持。换句话说，应用服务器为很多领域（例如线程管理、数据库连接、网络访问等等）提供了运行时（runtime）支持。应用服务器中的这些设施都是自由使用的，但是在传统的软件套件中，它们一般要求人们手动编写代码来实现。
简单的说，应用服务器有效地分割了主机平台与应用程序软件的业务逻辑。通过提供对软件的大量支持，
应用服务器技术允许软件设计者和开发者将精力集中在解决自己特定领域的问题上。适当地使用应用服务器技术可以减少软件开发的费用。
在上面的软件生命周期中，我们把标准的应用服务器工具（例如基于ant的工具）当作专用工具来使用。其它的一些与J2EE应用服务器部分绑定的应用程序还包括：
管理控制台
部署工具
调试工具
J2EE兼容性检测程序
管理控制台用于管理应用服务器上执行的软件，例如激活/不激活、列举组件等等。部署工具用于为应用服务器环境准备软件。调试工具用于辅助解决那些发生的问题。J2EE兼容性检查对于新软件的作者来说是非常重要的，因为J2EE组件与标准的java类是不同的。
Sun的文档表明应用服务器软件产品的生产事务是可以在专家之间进行分工的。程序员编写和测试源代码，接着把这些源代码传递给部署人员。部署人员准备并包装软件供我们在应用服务器上使用。在这个时候，软件可能被传递回程序员以供调试和集成java。另一组专家可以检测该软件的J2EE兼容性。其要点是一个或多个称职人员可以执行这么多不同的复杂的事务。
数据集中管理器对应用服务器下运行的应用程序拥有更大的控制权。这意味着企业中运行的软件可以在同一个平台上集中地管理和部署。在某些方面，应用服务器技术使我们“后退”到了大型机时代的软件部署情形。反对的观点认为这种模型使客户端不需要寄宿和执行大量的代码，但是在客户端上执行比在一个或多个应用服务器上执行的效率更高；同样，由于带宽的迅速扩大，带宽的约束力也逐步缩小。
第三种武器 技术传承？？应用服务器是基于组件的
J2EE应用程序遵循广泛采用的面向组件的方法。它们被分割成运行在客户端或服务器上的应用程序。客户端寄宿应用程序和applets,服务器寄宿java小服务器程序、JavaServer页面和企业级JavaBean（EJB）技术。
可以在应用服务器上部署的主要的组件文件类型有：Web档案文件（WAR）和企业级jar（EAR）文件。客户端应用程序都被打包成JAR文件。我们可以把组件准备好，在Sun应用服务器上部署它，而大多数准备工作是在向导的帮助下或使用工具（例如部署工具、asant和管理控制台等等）来自动地完成的。
应用服务器技术的面向组件的特性与软件工程文化的趋势是一致的。有趣的是，软件架构的演化在描述给定架构的软件元素的时候趋向于不使用组件这个单词。作为代替的是，在某个组件不仅仅是运行时实体的时候，推荐使用元素来描述它。应用服务器技术是否需要更多的架构细节也是很有意思的。
第四种武器 团队工作？？应用服务器提供了软件协同工作的能力
J2EE的根基之一是XML,它日益成为粘合各种应用程序的“胶水”.在网络管理领域，由于XML允许我们简单地定义服务并把它们转换为软件，从而显得光芒耀眼。XML作为改善软件（特别是寄宿在应用服务器上的软件）之间协同工作能力的一种途径，其重要性还会不断增加。
J2EE还提供了对数据库事务的支持。使用ATM取钱就是事务的一个例子。如果在事务的过程中出现电力中断或网络故障，你不希望帐号多次记入贷方，除非你中了彩票（哈哈）。因此，事务支持是应用服务器基础构造的一个重要的元素，它在J2EE中占据着重要的位置。
第五种武器 想象力？？应用服务器是高度抽象的
我经常在想，软件从业人员提升价值链的最好办法就是使用抽象事务。我们不是在分散的和有限的事务上孤独地工作，而是找出不太明确的抽象事务。抽象事务的例子包括建立存储备份策略、定义某个重要的应用程序特性的需求等等。
抽象事务是很大的挑战，它强迫大脑分而治之。应用服务器为运行在它上面的软件使用了一个相当抽象的模型。例如，J2EE允许你的软件访问后台的数据库，用这种方法提供了抽象的支持。它同时还考虑资源情况，隐藏了特定数据源的复杂性。
第六种武器 独立性？？J2EE与Sun的应用服务器是独立的、截然不同的
这是一个很基本的观点：J2EE本质上是一个高级的API,但是它的确包含了一些在应用服务器环境之外运行部件。其中一个例子是XSLT,它允许我们把传统的数据转换为XML,反之亦然。
J2EE的重要性还在持续增长；有些软件架构专家甚至于把J2EE作为21世纪软件工程文化首要的改造部分。它与环球网在90年代改变软件工程文化的情况类似--这也是花费精力了解J2EE和相关技术的另一个原因。更深一层的原因是微软和Sun目前在让它们的产品协同工作方面积极地合作。
第七种武器 发展？？应用服务器：软件未来之窗
应用服务器对企业中的软件集中执行的能力是强大的、引人注目的。它可能使IT业对已部署的软件的控制能力提高了一个很高的层次。当主要的软件组件基于应用服务器的时候，我们可以应用体系结构方面的品质属性，例如安全性、可修改性和可靠性。
这样，J2EE和应用服务器技术无疑会成为软件未来的桥梁。它还符合软件架构专家和面向服务的架构典型。
结论
不要害怕应用服务器技术！即使很便宜的PC也可以寄宿高级的软件套件（例如Sun的J2EE和它的应用服务器产品）。当然你也可以使用开放源代码的。其要点是这种技术越来越流行，同时越来越易于使用。
通过使用这种技术，你将了解软件工程文化的发展趋势，并会看到某些重要工作的产物。每个人都在谈论Web服务，但是都没有使用和建立自己的例子那么全面。即使企业级JavaBeans、Servlets和其它的J2EE技术也是如此。使用J2EE免费评估版本或类似的产品可以很容易地实现所有这些事务
JAVA虚拟机加载类的方式解析
虚拟机加载类的途径
1、由 new 关键字创建一个类的实例
在由运行时刻用 new 方法载入
如：Dog dog ＝ new Dog（）；
2、调用 Class.forName() 方法
通过反射加载类型，并创建对象实例
如：Class clazz ＝ Class.forName（“Dog”）；
Object dog ＝clazz.newInstance（）；
3、调用某个 ClassLoader 实例的 loadClass() 方法
通过该 ClassLoader 实例的 loadClass() 方法载入。应用程序可以通过继承 ClassLoader 实现自己的类装载器。
如：Class clazz ＝ classLoader.loadClass（“Dog”）；
Object dog ＝clazz.newInstance（）；
三者的区别：
1和2使用的类加载器是相同的，都是当前类加载器。（即：this.getClass.getClassLoader）。3由用户指定类加载器。如果需要在当前类路径以外寻找类，则只能采用第3种方式。第3种方式加载的类与当前类分属不同的命名空间。另外，1是静态加载，2、3是动态加载
两个异常(exception)
静态加载的时候如果在运行环境中找不到要初始化的类,抛出的是NoClassDefFoundError,它在JAVA的异常体系中是一个Error
动态态加载的时候如果在运行环境中找不到要初始化的类,抛出的是ClassNotFoundException,它在JAVA的异常体系中是一个checked异常
Class.forName与ClassLoader.loadClass区别
Class的装载包括3个步骤：加载（loading）,连接（link）,初始化（initialize）.
Class.forName(className)实际上是调用Class.forName(className, true,
this.getClass().getClassLoader())。第二个参数，是指Class被loading后是不是必须被初始化。
ClassLoader.loadClass(className)实际上调用的是ClassLoader.loadClass(name, false)，第二个参数指Class是否被link。
Class.forName(className)装载的class已经被初始化，而ClassLoader.loadClass(className)装载的class还没有被link。一般情况下，这两个方法效果一样，都能装载Class。但如果程序依赖于Class是否被初始化，就必须用Class.forName(name)了。
例如，在JDBC编程中，常看到这样的用法，Class.forName("com.mysql.jdbc.Driver").
如果换成了getClass().getClassLoader().loadClass("com.mysql.jdbc.Driver")，就不行。
com.mysql.jdbc.Driver的源代码如下：
Java代码
1. // Register ourselves with the DriverManager
2. static {
3. try {
4. java.sql.DriverManager.registerDriver(new Driver());
5. } catch (SQLException E) {
6. throw new RuntimeException("Can't register driver!");
7. }
8. }
原来，Driver在static块中会注册自己到java.sql.DriverManager。而static块就是在Class的初始化中被执行。
所以这个地方就只能用Class.forName(className)。
对于相同的类，JVM最多会载入一次。但如果同一个class文件被不同的ClassLoader载入，那么载入后的两个类是完全不同的。因为已被加载的类由该类的类加载器实例与该类的全路径名的组合标识。设有 packagename.A Class ，分别被类加载器 CL1 和 CL2 加载，所以系统中有两个不同的 java.lang.Class 实例： <CL1, packagename.A> 和 <CL2, packagename.A>。
漫谈Java理念的转变与JVM的五大优势
本篇文章是EngineYard公司官方博客在11月底更新的一篇文章，原文标题叫做《J is for JVM: Why the ‘J’ in JRuby?》(J是JVM，为什么JRuby要用J？)。EngineYard是一家以Ruby技术为核心的云计算服务供应商，而今年在吸纳了从Sun脱离的两位JRuby核心开发者之后，似乎开始计划将重心转移到JVM平台的JRuby上。本文由王玉磊编译，原译文标题为《深入分析：JVM的优点与缺点》。让我们看看JVM有什么好，吸引了这么多语言去投奔它。
当Java最初诞生的时候，它可以说是其他语言的进化版。不仅因为Java很简单，而且这一进化的语言还是一个可以运行第三方硬件字节码的虚拟机。它还是垃圾收集站，从而令存储管理和内核转储(core dump)不再是麻烦。当然还有它相当全面的类库。虽然它没有什么惊世的新性能，但它把许多语言的优点基于一身。
本来Java是一个简单独一的语言，但是Sun在长期运营Java的过程中出现了很多错误，比如将语言与runtime合用一个名字，从而使得用户在识别JVM语言项目如Jython、JRuby时难以从思想上隔离Java。最主要的是这样对runtime很不公，因为Java Virtual Machine (JVM)有很多自己的独特之处。 缺点
没有一种技术是完美的，JVM也不例外。如果你工作在一个没有Java语言配置的设备上，JVM便无用武之地。JVM为其他语言提供了基础，但JVM最初不是为这个理念设计的。比如我们作为分配对象来维护我们的堆栈时，通常我们会直接操作实时堆栈并添加我们维护所需的其他字段，除此之外再没有控制堆栈的更好的方法。
还有，当我们创建一个Ruby Fixnum时也很麻烦，我们把这些值用一个Java对象包装。Ruby的C implementation不过只是传递tagged ints，因为没有包装他们就不会符合各种列表，所以Java 基元(Java primitives)也不会切割它。
顺便说一下：JVM的启动时间也挺长。
那些为JVM编写高性能代码的开发者会觉得经常被JVM的black box特性所折磨，一旦你加载你的字节码，你就觉得像是摇动老虎机的游戏手柄一样忐忑，不知道结果如何，black box就是意味着不可知。 优点：
Hotspot
对于初学者来说，尽管Hotspot有些神秘，但是性能方面它确实很棒，因为动态建模(dynamic profiling)是优良性能的捷径。HotSpot从运行应用中采样数据，从而可以优化代码，进而得到良好性能。它相当于以模仿人工的方法进行优化。在程序运行的开始，Java代码仍然解释执行，但HotSpot引擎开始进行采样(Profiling)。HotSpot引擎可以集中精力来对HotSpot代码进行深度优化，从而使这部分代码的执行更加迅捷。因此当Hotspot优化时，它为优化设立了一层保护来确保优化的基本原理有效;但当这层保护失效时，优化就会很慢。
这里是Hotspot在使用中的一个演示：
在图表中我们运行了一个Mandelbrot Generator很多次，然后测绘它每次生成的时间。你会看到JRuby
1.4.0明显比Ruby 1.8.7以及1.9.2preview2表现更好。如果只看JRuby的起点，会发现比1.8.7慢，但当Hotspot运行后时间曲线迅速下降。
这里有个有趣的始建波动发生在循环6那里：实际上那是因为Hotspot的动态反优化启动。然后时间波动回到原来状态，优化结束。
Hotspot已经被全世界的开发者和拥趸支持了近十年，Java 4, 5, 6之间的提升让人印象深刻。每一次它的升级，性能都会有很多提升，它真是的是JVM的一大利器。
垃圾回收Garbage Collection (GC)
Java开发者花费大量时间来调试、测试、提高他们的VM，单是Garbage Collection的开发和维护就持续了15个年头，由此可见它的性能!而且JVM发布了多个垃圾回收器，所以这样一来即使加载的负荷超过了JVM中一个Garbage Collection，JVM也还可以允许你使用其他的Garbage Collection。因此，你可以自己调整任何你所使用的Garbage Collection，使之符合你的应用。
各种各样的回收站发挥着不同的作用。它们全部是压缩过的，所以不必担心存储的问题。它们都是增量型的(incremental)以缩短GC停滞的时间;它们还是分代的(generational)，所以短时对象(short-lived object)回收得更快。有些是并行的，从而回收工作可以在多个核上分开运行;甚至还有同时发生的Garbage Collection，这样就没有了停滞时间。JRuby可以免费得到这些，现在的Java 7以及Java 6的u12，甚至还有一个新的G1回收站。
关于GC和JVM还有两个很巧妙的地方，从中可以获悉GC运行虚拟化和信息的情况。第一个是-J-verbose:gc flag，从中可以得到回收事件发生的时间、数量以及花费的时间，这可以让我们获悉垃圾回收器处理工作负载的好坏状况：
你可以记录这些事件并且计算出清理垃圾所需的总时间，还可以计算出你加载的工作负荷是否超过了回收器的能力，这可以帮助改变你的设计并通过调节堆栈大小来适配回收器。
第二个是通过jconsole查询JVM状况。Jconsole可以从许多角度查看系统，而且有一个很棒的memory tab来展示GC的运行状况，如下：
在右下角你可以看到绿色的框格，从中可以看到不同的生成占存储的多少。比如说你看到一个近乎满的survivor 生成，那意味着慢的满GC收集时刻，那么意思就是说这个应用可能不是很健全。
移植性
无论是GC还是Hotspot都可以用在任何Java可用的地方。比方说，JRuby可以运行在其他平台上，Rails应用就可以运行在IBM主机上的JRuby上，而且这台IBM主机运行的是CP/CMS。
实际上，由于Java和OpenJDK项目的开源，我们正在看到越来越多的平台的衍生，因此JVM的移植性也将越来越棒。
成熟
JVM已有超过15年的历史，在过去的这些年里，许多开发者为它做出了许多贡献，使得它的性能一次又一次地提升，让JVM变得更加稳定、快速和广泛。
覆盖面
JRuby和JVM上的其他语言项目已经被开发者所承认，一个典型的例子是invokedynamic
specification (aka JSR292)。JSR越来越配合新的语言，JVM已不再是Java一个人定制规则。JVM正在构建成为类如JRuby等项目的优良平台。
还有一个MLVM(multiple language VM)项目，好比是新特性的清算机构，是一个许多企业应用的开发者试图添加应用的地方，而这些应用正是他们想在JVM中看到的。而且JVM开发者互相协作、彼此影响，无疑这有利于JVM新特性的诞生。
这些细节都可以看到JVM正在关注开发者的需求，扩大他的覆盖面。
总之，JVM已经成为技术界越来越稳定的产品，Oracle/Sun的合并以及其他可能的商业闹剧都不会影响这一点。许多技术大鳄级公司(如Oracle、IBM、HP、SAP)已经为编写JVM的中间软件花了如此多的钱以至于在下个十年里他们可能不会再为JVM的发展做太大的贡献。
在学校教学Java是有争议的
读：本文来自 reay z 的编译投稿，英文原文《Teaching Java in school is just as controversial as an interview with Justice Gray》写于20xx年7月，原文中某些观点，现在看来可能不妥。另外，译文中有些不妥之处，伯乐在线已改进。以下为全文。
今天我读了一篇好文，这是对纽约大学计算机科学教授 Robert Dewar采访的一篇跟进文章。我等您读完再继续说。读完了？好的，现在我们能好好交流下了。我必须说，我完全同意 Dewar 教授对当今毕业生的主要观点。（自爆下，我拿到了华盛顿大学的计算机和软件系统学位，但我在学校主要用C++ 。） 他的一个主要观点是Java有很多库。从上文中引用Dewar博客的一段话：
“如果你去商店买本关于Java的书，你会发现在1200页中，有300页是关于Java语言，有900页是讲各方面库。 用Java，你是可以很轻松地快速做东西（但不是很仔细）……故而你是可以用最少知识匆匆拼凑做东西， ”他说。“但对我来说，这不是软件工程，倒像是某种“干耗级别”（consuming-level ）的编程。”
首先他说的对，Java强大的原因之一就是它有很多库。还有 PHP、.Net 和 Perl 也有很多库。当然他们都不能用来驱动飞机或者火箭发射。但他们用在电子商务、管理公司、守护私人健康数据 、运行军队的装备和建立无用的社交网站。那么问题是什么？是不是Java不再是商业世界的流行语言？（当然不是）。是不是Java不是适宜用来教学生学习编程的语言？（当然不是）。是不是我们没有用正确的方法教计算机科学。因为你在看这个博客，所以我假设你是想知道这个答案的，所以我的答案是：
我们并没有用正确的工具来教正确的东西。
允许我稍微解释一下：
计算机科学太难了，所以只有带点神经质的书呆子才能掌握。
CS（计算机科学）这个专业吓倒了不少人。计算机很吓人，计算机很复杂，计算机是给那些盯着命令行一整天的神经质呆子。这是我从学其他非 CS 专业的人那里听来的全部。
除数学、化学、物理专业的人，才需要上 CS 课。
当我在学校的时候，有很多学科拿毕业证需要读过入门编程（在华盛顿大学那是CSE 142 和后续 CSE 143 ）。当我上高中时，我通过社区大学的running start项目读了相当于 CSE 142 的课程。那门课是用C++，通过一年的学习，我获得了相当于 CSE 142的学分。所以我解放了大学一年级，闲了一年。那门课有挑战性，但并不过分而且那门课只有20-25人参加，所以每个人都有很多机会从教授那里得到个人辅导。 我选了 CSE 143 在我上华盛顿大学的第一年（那是19xx年，所以现在可以算出我的岁数了）而且在那时那门课用的是C++。我当时已经懂C++了，但那门课对我来说依旧颇具挑战性。我想起当时我们的第一次考试，满分100分我考了44分，但仍然高于平均分。有很多人放弃了那门课。还记得我们的一个项目陷入 dll 地狱，没有一个人能让这代码 Build 和链接。连助教也无法让它运行。我的朋友Kevin，他是CS
的高年级学生，他也无法让它运行起来。教授最后让我们交上来我们所有的东西，即使他不能编译和运行。这几乎让我讨厌计算机。这让很多学生说，靠，这糟透了，然后放弃这门课。
这正是Java试图解决的问题
Java没有“dll地狱”。有一个良好支持Java的IDE。它是免费的。它能运行在所有的平台上，并且不需要为此改变代码。语法很友好。它有很多库，你能用那些库里的类来实现大多数数据结构和算法，例如
linked-lists, b-trees, heaps, hashtables等等还有常见的搜索、排序算法。现在学生只需要关于代码和如何让代码运行起来。像过去那样，鼓捣编译器使其运行和担心编程环境的情况，没有了（或最少化了）。如果一个学生喜欢用代码来解决问题，他们也许会选择这样做而不是被调试编译工具和IDE弄得无比沮丧。大学应该首先让CS看起来不那么恐怖，我认为Java可以做到这一点。
Java是如何至少导致了10个新问题
第一个问题是如何用Java教学生。Java有100000个不同的库，并不意味者你必须使用他们。而且大多数库都是用Java写的，难道不是吗？所以这是第一个问题：当你开始教数据结构和算法时，你必须实实在在地教它们，你不能简单第让学生用那些库去建立程序。也许教哈希表的一个好例子就是展示 Java
HashTable的类，写一个程序来从一个HashTable中存取值。现在，自己写一个 HashTable类实现Map接口，并且输出实现。重复这样做以学习其他的数据接哦股和算法。喔，问题解决了。
所以既然学生学了Java，我们可以用Java做任何事，是吗？
不是的。你不能教Java里的所有东西。你只能教Java里的一些东西。我曾上过一个50%课堂内容是教Java的操作系统课，这么做是因为演示多线程概念用Java比C++更简单。但这并不意味着我不会用C++中多线程编程，而是在Java中debug它更简单一些，这可以让我专注于其他事情上。同样，在我们必须
实现的虚拟文件系统的文件 IO 上，Java通过操作实际的文件 IO 让虚拟文件系统实现更容易，但是我们只有一个超大文件，而且在这个文件中有我们的inodes和数据，我们必须建立一个“文件”实现，它模仿读写我们的超大文件。再说一次，在不需要关心格式化实际硬盘驱动和与之互动的情况下，帮助我理解概念。这是重点：
Java允许你专注于问题的解决，而不需要关心工具和编程环境。如果专注于概念不依靠工具和编程环境，那么Java是一个好的选择。
通过一个对你来说很难管理内存的编程语言，来学习内存管理
这估计是Java作为一个学习工具最大的问题。作为一个开发人员，你必须对机器如何操作东西例如内存或者其他东西有深刻的理解。在Java中你完全不需要关心内存，所以这使得Java不是一个合适学习内存管理的工具。像C那样的语言真是一个最好的学习工具，因为它必须手动地做任何事情。实际上，我认为理解内存如何运作的最好方法，是去你能实际上看到地址模型和它们之间不同的地方。这帮助我理解指针，胜过任何其他的东西。这带领我们到：
这无法学习机器语言，除非通过一个真实的机器
Java是一个虚拟机，但我们想要理解真正的机器。计算机如何运作，背后原则的知识很重要，特别是当一些东西往坏地方发展的时候。在你离开学校后的职业生涯中，你也许并不会再使用汇编。你未来也不会写驱动或者编译器。但如果你正在用这些工具（我认为编译器也是一种工具），理解他们如何工作很重要，否则它们一旦不工作时，你将不能找出原因。你需要通过真正看到硬件如何工作来学习它。你需要能真正这几一个相对简单的逻辑线圈。你需要知道这些线圈如何用来组装一台计算机。这些东西并不难如果教的好的话。汇编语言是关于硬件和软件接口的，所以学好它很重要。我学了motorola68000汇编，它比 x86汇编简单，但还是很好地演示了指针。现在我知道：
1
2 int a = 5
3 int * b = a
4 int* b = 5
5
的区别，在机器内部这是由汇编命令表达的。这帮我理解内存如何工作，而且这使我写出的程序不会发生内存泄漏。
但是，这些东西在教育系统中消失了
我（和很多人）认为Java是一个好的面向对象语言。很多人有一个或二个星期来完成关于多态的作业。这很酷，但你并不理解继承。他们不会教你为什么用继承和如何正确地使用它。他们不教任何东西关于模式、重构，或者简单地教授一些用对象编程的内容。我认为这些本应该被教的内容是很重要，很多大学毕业生因为不曾被教这些东西而不具备这些知识。我认为Java是一个好的工具去教这些东西。
还有测试
没有人教如何测试代码或者甚至如何使代码可测试。我并不是在讲运行应用程序并检查输入和输出。我在将单元测试，整合测试和自动化测试。知道必须测试和单元测试很重要是远远不够的。你需要理解累死test doubles, test automation等类似的东西，和如何写代码使之能单独被测试。Java是一个很好工具做这些。 其他一些东西
你如何建立一个大项目？如何自动化建立？如何管理源代码？分支是什么？有很多东西是有经验的程序员认为理所当然的，但我们必须在一些地方学到这些东西。也许我们在经历了这些问题后明白了这些东西，或者在工作中其他人告诉我们。这需要在学校就开始。别专注于一个特别的技术，而是要学习这些概念和了解这些概念为什么重要。代码在这种课堂中并不是最重要的，你可以使用你想用的任何语言。但是，记得这门课的目地是管理代码，而不是写代码，所以别给学生制造代码上的难题。用一些已有代码，做细微改动，迫使学生用版本管理工具，去改变构建过程，去考虑更复杂的东西。
最后的想法
很多大学坚持Java，因为很多学生已经知道它，这是最小公分母。如果你想让你学生从世界程序员的最小公分母中出来也没问题。程序员的一个重要技能就是学习新语言。这有助于在科技更新中保持劳力竞争力。如果你只教Java，那么问题将会是你的学生将没机会快速掌握一门新语言。
所以我的解决方案是：
●使用本学科最适宜的语言教授课程。入门课程应当教些能让程序编译并运行的东西。Java是一个理想选择，但 C# 也可以。入门课程的重点是编程的入门，而不是如何鼓捣编译器的入门。
●每个学生应该被要求在校时用最少4种编程语言。其中之一应该是汇编，其中之一还应该是面向对象编程语言。HTML不是一种编程语言。
●传授如何编写出色代码。漂亮的代码不等于带注释的代码。这需要强制在每门课中执行。但这本身就是一个门具体课程中执行，并且最好是学生生涯开始之初尽快执行。课程内容应覆盖设计模式、OO设计的原则、单元测试等等。
●要求学生在通过入门课程后，在每堂课中都使用版本管理工具。大学应该提供学校的vcs给每个同学。这并不像听起来那么困难。
●编译器、硬件、操作系统课程应该是强制的（有时候，其中部分并非需强制）。在硬件课程的最后一个项目中，我曾写过一个反汇编程序用汇编语言。这很难，但并非不可能。班上每个成员至少能收获能工作的东西。我的反汇编程序，也能正确地反汇编自身。
●学生应该被强制与同班的其他人合作。合作可以包括一起工作，但也可能包括代码审查（code review）和结对编程。
●永远不要在全班面前强制 review 一个学生的代码，除非那个学生同意这么做，但匿名代码审查和在私人场合review都是可以的。我知道这在商业世界是不必遵守的，但我们在学校，而且我们并不想疏远学生。我认为这是一个折中策略，我们将仍可以传授代码审查的价值，并引导学生，并且不让学生有要放弃这个课程的念头。
●所有课程都应该落实到写一些代码。
●在课堂上，教授/教师应该至少提供一块漂亮代码，用于演示。这有助于学生去阅读漂亮的代码。这同样有助于学生阅读糟糕的代码，并知道它不好在哪里。
最后，如果你是一位教授、大学管理人员或者其他相似的，如果你想要与我细谈关于这个主题，我将很高兴在任何时间与你聊聊。我谈了这么多，是因为我热烈地相信这很重要，我将会尽一切力量去让计算机科学教育变得更好。如果你正在读这些，我建议你也将这作为优先做的事情。去和你本地的大学谈谈，给你的教授写邮件，去当地学校，特别是高中和社区大学演讲，鼓励学生去计算机科学系。除非你做点什么，否则你是不会知道你对别人的影响力有多大。
为了更好校对这篇译文，费了不少时间，尤其是原文标题中提到的 Justice Gray（法官葛雷），搜索好久，才找到他所涉及的有争议案件，就是一件美国排华案件，即：1893年冯越亭诉美国案。
简要摘编：1892年制定的吉尔里法案，是美国有史以来对华人最严厉的法案，其他国家的移民都不须带任何身分证明文件，但在美华人必须申请居民许可证并随身携带，若未携带就会被认定是非法居留而被逮捕，需先服一年苦役后，再被驱逐出境。
此案一出，立即受到华人社会的反对，中华会馆（ Six Companies ）呼吁华人不要去注册，认为此法案是违宪的法案，没有法律效力，这个种族歧视的法案违反了美国宪法的权利宣言（ Bill of Rights ）。与其缴费注册，不如把钱集资打官司。
冯越亭是 1879 年到美国的劳工，没有入籍，是居住在纽约市的合法永久居民，没有任何回国定居的计划。冯越亭响应中华会馆的号召，拒绝按照侮辱人身的种族歧视法律去注册。由于没有注册证，美国宪兵在没有逮捕令的情况下不经过正当程序就逮捕了冯越亭。
中华会馆请律师为冯打官司，认为吉尔里法案违宪，一直上诉到最高法院。 但最高法院大法官以五票对三票判决冯越亭等败诉。这五票中，就有 Gray 的一票。他认定吉尔里法案有效，并称“美国是一个主权国家，有权利排斥任何人、任何种族，并将之驱逐出境。” ——摘编自《美国华人法律史》
英文原文：Jeff Tucker ，译文由 reay z 编译并投稿于伯乐在线。伯乐在线也欢迎其他朋友投稿。提示：投稿时记得留下微博账号哦~
对九个超级程序员的采访
这篇访谈源自20xx年，最先发布在波兰程序员 Jaroslaw “sztywny” Rzeszótko (AKA “Stiff”) 的博客上。但是这篇博文现在找不到了。非常感谢他能授权我重新发布这个博文。
在一个炎热无聊的下午，我突发奇想。我想通过电子邮件的方式对那些我非常感兴趣和非常敬重的程序员问10个问题。准备这10个问题我只花了5分钟，这些都是我个人想问他们的问题，所以，我基本上没想太多要问他们什么。最后两个问题和编程没有什么关系，我就是想问题这些人的一些兴趣爱好。另外，不是每一个人都想回答我的，这是我第一次做“访谈”，所以，我犯了一些错误，一些问题没有得到回答。不管怎么样，我得到了很多很有意思的内容，所以，这对我绝对是一次很有意义的经历。
并不是每一个人都回了我的邮件，也并不是每一个人都同意回答我的这些问题，也许在我发布这篇文章后我会得到那些回答，但是我已经迫不及待想把这些东西发布了，所以，我可能会更新这篇文章（更新：20xx年3月8日，我收到了Bjarne Stroustrup的回信）
– Jaroslaw
介绍
? Linus Torvalds - Linux kernel 作者。
? Dave Thomas – “Pragmatic Programmer”(注：douban) 和 “Programming Ruby”(注：douban) 以及其它
一些优秀书籍的作者。 你可以在 这里 读读他对编程的一些想法。
? David Heinemeier Hansson – Rails Framework 作者- 一个目前最新最热的Web开发框架。他的blog在
这里. （陈皓注：他也是37signals的领导人之一）
? Steve Yegge – 他可能并不那么知名，但是他给了很多有意思的回答。他有一个很火的关于编程的 blog，
他也是游戏 ”Wyvern” 的作者。（陈皓注：他最火的是去年在google+上对google和amazon的吐槽，06年他应该在google了）
? Peter Norvig – Research Director at Google, 知名的 Lisper，AI书的著名作家，个人主页。 ? Guido Van Rossum – Python 发明者。
? Bjarne Stroustrup – C++发明者， 个人主页。
? James Gosling – Java 发明者。
? Tim Bray – XML 和 Atom 规格说明书作者之一 个人博客 。
Q 1: 你是怎么学编程的？是从学校里学的吗？或者你没有上过学:) ？
Steve Yegge
在我17岁的时候，我在HP的计算器中用他们的RPN 栈语言自学编程的。在这之前，我尝试过学习编程一两次，但都没有学成。HP 28c 和 48g 的科学计算器是一个很牛的东西，而且还有不错的文档。我搞了一本3D图形的书，并很费力地把其中的Pascal语言转成RPN栈语言，并用48g写了一个3D的线框图渲染图。运行的还不错，在我买了PC和Turbo Pascal之后，我开始认真地学习编程。在我进入大学计算机科学专业之前，我已经是一个不错的程序员了。
我在华盛顿大学拿到了计算机科学学位，这绝对是有价值的，所以，我建议所有的程序员都应该得到计算机科学专业的学位。
Linus Torvalds
我没有在学校里学过编程，我在主要是读我自己想读的书，或是就直接去编程 (一开始在 Commodore VIC-20 学编程， 然后是 Sinclair QL上编程)。
当然，我觉得上大学非常有用。我没有去一个工科大学，我上了赫尔辛基大学，这是一个比较偏理论的大学，所以，那里的教育并没有那么多的编程的东西（编程只是很少一部分），这里大多数的课程都倾向于教一些基础概念的东西，如：复杂性分析。看上去很无聊，甚至有点浪费时间，但是我还是觉得这些课有用，我对大多数课都还比较enjoy。所以，我觉得我可能在这些方面是一个比较好的程序员。
David Heinemeier Hansson
我学编程是从用HTML做我的第一个网页开始的。那时，我想当我的网页能动态地显示一些内容，所以，我选择了ASP和PHP。在做完这个网页后，我知道了怎么去编程，于是我开始我的计算机科学和商业管理学位的学习。
Peter Norvig
我是从高中和大学课程中学编程的，但是我还是觉得我自己学得更多。
Dave Thomas
我是在高中学编程的。我完全地迷住了，我对编程爱得无法自拔，然后，我开始挑选那些提供软件开发课程的大学。最终，我去了伦敦大学的帝国学院。第二年我就开始学习软件开发的课程了，那绝对是非凡的，学生和教员在一起工作把教材做得更好，每一个人都可以从中学到很多。这些课程给了我难以置信和非常雄厚的软件开发背景。我在那里读到了博士，最后去创业了。
关于“我是怎么学编程的”这个问题，我的回答是“我现在还在学编程”。我认为好的程序员一生都在学编程。这并不是去学一门语言或是一个代码库，好的程序员会对他们的编程技艺一年又一年地精益求精。
Guido Van Rossum
我去的那个大学有一个大型主机和很多不同的计算机课程。这对我很重要。
James Gosling
起初，我是自学的。在我去上大学之前，我就找到了一份程序员的工作。但是我很高兴我去了大学，在那里有很多乐趣，最终我学到了博士。
Bjarne Stroustrup
我先上的是Aarhus大学， 然后是 剑桥大学(Cambridge)，这两个大学教了我很多很有用的东西，这些东西为了以后的工作打下了基础。另外，我对编程和钱的关系学得非常好——知道了真实世界的问题，正确性，维护性，准时交付，等等，这些比教育可能更重要。
Tim Bray
我本来想去做一个数学老师的。但是，那个学数学的大学要我去学几个计算机的课。
Q 2: 你们觉得对程序员最重要的事是什么？
Steve Yegge
沟通能力（写和说）。除非你可以让你的想法更有效率地传递出去，否则你不可能做得比编程更多的事。程序员应该疯狂地阅读，锻炼写作能力，参加一些写作培训课程，甚至锻炼在公开场合演讲的能力。 Linus Torvalds
It’s a thing I call “taste”. 有一件事，我把它叫做“品味”。
我倾向于不从熟练程度来评判那些和我工作过的人。这些人能非常艰苦地写出很多代码，但是我想从他们对别人的代码的反应做出评判，这样我们就可以明白他们自己写的代码怎么样，知道他们使用的方法怎么样。他们对别人的评判还告诉我，他们是不是有好的“品味”。是这样的，如果一个人没有“好的品味”，那么他一般不会很好的评判他人的代码，他自己写的代码通常也不会很好。
哦，这并不只是唯一的事。还有一件事，尤其在开源项目里，那是他是否有能力能和别人进行简单的沟通，告诉别人他要干什么，怎么干。这个能力可以告诉别人为什么你干的事是非常重要的，并不是所有的人都有这个能力。
也就是说，有一些人可以写出很不错的代码，但他们并不一定能解释这些代码，他们也并不一定有好的品味，但是代码可以运行得不错。有时，你需要另一个人（有那种不错的品味的人）把他的代码转成更好的形式。也就是说，任何一个程序员都需要那种可以用清晰的代码来解决复杂问题的基础能力。 David Heinemeier Hansson
很强的对有价值的事的感觉。你可以问问自己这个问题你有没有这种能力：我现在做的这个事值不值得做？很多程序员浪费了如大海一样的时间去做一些无意义的事。
Peter Norvig
我不觉得只有一个，如果要我说一个的话，我说是“专注”。
Dave Thomas
热情。
Guido Van Rossum
你的问题很难回答啊:-) 我猜，如果程序员会在早晨煎个鸡蛋做早餐，那真是无价的能力。
James Gosling
自我激发。你需要全身心地投入到你要做的事中。
Bjarne Stroustrup
把事想清楚的能力：程序必需要能清楚地理解问题并能清楚地表述解决方案。
Tim Bray
能为自己的直觉提供证据的能力。
Q 3: 你是否认为数学和/或物理是一种很重要的编程技能？为什么？
Steve Yegge
数学有很多的分支和程序员相关，他们是“离散数学”和“具体数学”。这些分支包括的学科有，概率论，组合数学，图论，归纳证明，和其它有用的东西。我会鼓励所有的程序员都去学习离散数学，无论能学多少，因为这总比什么都不懂强。
对于传统的数学，我也不经常用，但是我需要的时候这些数学知识会很管用。例如，在我之前的工作中我就用到了微积分。我需要估计每个小时中某服务的高峰时间的流量负载，所以，他的负载是跟着太阳走的就像一个正弦曲线一样。最简单的方式就是把每个小时的负载曲线给整合起来。如果我不知道微积分，我就不知道怎么更为准确地估计。
当年我在开发我的Wyvern游戏的时候，我的平面几何的知识对我非常有帮助。而且经常使用代数和线性代数的知识。但我很少在工作中使用三角学或微分方程，微积分同样也很少。
我想说，简单的数学基础让我的技能比一般程序员好过5%到10%。如果我了解更多的数学，我确信我会比今天做得更好，所以，我每周都会花几个小时学习数学。
我喜欢物理，我还在学习物理，我会花我一生去理解量子力学。但是我个却没有发现物理对我的程序员工作有多有用。当然，如果我从事一些和物理相关的工作，可能会有用，例如：3D游戏编程，或是某种物理特性仿真。
Linus Torvalds
我个人认为有很强的数学背景是一件好事。但我不确信物理是不是这样的，但是我深信懂数学的人会让你成为一个更好的程序员。这些智力模型都是相通的。
David Heinemeier Hansson
根本没用。至少对业务编程和Web应用来说没用。但是数学可能对一个人的写作有很重要的帮助。 Peter Norvig
是的。很多相法都是从数学来的：归纳，递归，逻辑，等等。
Dave Thomas
也许吧。但老实说，我没见到过懂这些学科和好的程序员有很大的相关性。
然而，我见过有音乐背景和好的编程技能有很强的相关性。我不知道这为什么，但是我怀疑大脑中的某个区域可以让人即可以写出好的音乐，也可以写出好的代码。（Guido Van Rossum
数学，当然（对于一些学科是很重要的，我不关心微分方程，但是代数和逻辑学是很重要的），物理，我不觉得对编程技能有关，当然物理在其它很多地方很有意思。
James Gosling
当然！数学教会了我逻辑和推导……让我有了一双懂分析的眼睛。当我们分析算法的时候，数学是无法被取代的。
Bjarne Stroustrup
这要看程序员自己和项目性质了。以前的数学很有用，物理一般，但是学好物理是是学习应用数学最好的一条路。
Tim Bray
对我来说，在我的编程生涯中我从来都没有用过大学里教的数学。
Q 4: 关于编程，你们认为接下来的大事是什么？X-Oriented编程，Y语言，量子电脑 ？
Steve Yegge
我认为Web编程会逐渐变成最最重要的客户端编程。而对于原来传统的客端端编程都会被废弃，如： GTK, Java Swing/SWT, Qt, 当然，所有的和平台有关的东西，例如 Cocoa 和 Win32/MFC/等。
当然，这不会一晚上就发生了。这会在第一个十年内缓慢地发生，而在第二个十年内，Web Apps最终会胜利。工具，语言，协议，和浏览器技术都会进步得非常快，并会完全超出你今天能干的事。每一年都会向前进一步，而从今天开始，我会最终决定把我所有的应用开发全部切换到基于浏览器的应用。（陈皓注：我也是这么认为的，参看《来信，创业，移动互联网》）
微软和苹果最终不愿意这个事发生，所以，触发这个事的第一步会是一个开源的浏览器（如：Firefox）开始到了支配市场的地位，然后会出现某种Firefox的杀手级应用（这种杀手级应用可能会像iTunes一样，所有的人都会用它，只需要下载Firefox）
Linus Torvalds
我并不认为我们会看到一个“大的跳跃”。我们只会看到很多的工作帮助我们把那些沉闷辛苦的工作变得更简单——会有一个更高级别的语言，也许把简单的数据库集成到语言中来会是其中最主要一个。
例如，我个人相信“Visual Basic”在编程方面比“面向对象”做得更多。当然，人们都在取笑VB是一个很烂的编程语言，并且人们在谈论OO语言都十多年了。但我还觉得不是这样的，Visual Basic 不是一个好的语言，但是我觉得VB那简单的数据库接口比OO更重要。
所以，我认为会语言有很多的改进，并且，硬件的改进会让编程更容易，但我并不期望会有巨大的生产力或是革命性的改进。
至少，你不会开始搞真正的AI的东西，我也不认为真的AI会变成某种你不需要编程的东西。 David Heinemeier Hansson
我从不试图预测未来。我也不相信命运一说。最好预测未来的方式就是去实现未来。
Peter Norvig
大规模的分布式处理
Dave Thomas
下一个最牛的事会被再下一个最牛的事所掩盖，然后再被再再下一个所掩盖，再再再下一个所掩盖……。这是一件没完没了的事，所以，我并不会试图去找最牛的事，因为这会让人们忘了那些最真实的问题：把基本的东西做对。我们要让用户更满意，专注于交付有价值的东西，自豪于我们做的事。一个程序员可以使用很多工具把这些事做得更好，而不是去追逐时尚和流行。
Guido Van Rossum
对不起，我没有那么多水晶球。我CGI被发明了5年后预测过它 :-)
James Gosling
有两个事是我现在最关心的，那就是要对付并行和复杂。
Bjarne Stroustrup
我不知道，我也不愿猜。
Tim Bray
不知道。
Q 5: 如果你有3个月学一个相对较新的技术，你会学什么？
Steve Yegge
我的确有3个月的业余时间，我准备学一下 Dojo (http://dojotoolkit.org) 和高级 AJAX 及 DHTML。我会通过开发一个相当牛的Web应用来学习他们。Dojo 真的酷，并且我确信它会越来越好。
Linus Torvalds
嗯，我真的很爱做 FPGA（可编程芯片），但我部是太忙了而不是坐来来开始学习。我喜爱和硬件打交道：很明显这个原因是因为我最终在做操作系统，因为操作系统（除了编译器）基本上都是在和硬件打交道，但我没有真正地自己去设计和做一个硬件。
David Heinemeier Hansson
Mac 的 Cocoa 编程
Peter Norvig
我想把 Javascript 学得更好，当然也想学 flash.
Dave Thomas
如果“新”是对于我来说，那么我会去学钢琴课。
如果“新”是说技术，我猜 我会选择学习某种和为残疾人服务的有关的技术。
Guido Van Rossum
单板滑雪。
James Gosling
搞点有乐趣的东西，我会学习最新的3D渲染技术。我可能会写一个光子映射渲染器。
Bjarne Stroustrup
3个月只有很少的东西你可以学，我觉得你只能参加某个成熟领域的培训。
Tim Bray
安全，加密，数字签名，身份标识，等等。对我来说，从没学过这些东西对我来说是个很大的问题。 Q 6: 你们觉得如何让一些程序员可能有超过其它程序员10倍或100倍的生产力？
Steve Yegge
我想你应该考虑一下为什么不是让所有的程序员都一样牛。托马斯爱迪生有一句关于天才的名言也许会给你一些启示。
Linus Torvalds
我真的不知道，我想，一些人之所以更牛是因为他们可以专注于那些重要的事，而更多的只不过是在应付。那些我所知道的真的很牛的程序员从很年轻的时候就在做事了。
David Heinemeier Hansson
把难题变简单的能力。
Peter Norvig
把整体问题一次性放入大脑的能力。
Dave Thomas
他们关心他们做的事。
Guido Van Rossum
大脑结构基因不同。
James Gosling
他们知道他们要做什么，他们不并不急于仓促行事。他们有他们要做的事的整个蓝图。
Bjarne Stroustrup
首先，缺少足够的职业培训，或基础不够。其次，这些人要即聪明（那种可以把事情想清楚，直达核心的能力），又有经验，并有使用工具的知识。编程需要把理论和实践结合起来 – 并不是使用没有实际业务的知识。
Tim Bray
令人惊讶的思维改变。
Q 7: 什么工具是你的最爱（操作系统，编程/脚本语言，文本编辑器，版本管理，shell，数据库，或其它没它你活不了的工具），为什么不是别的？
Steve Yegge
操作系统： Unix! 我用Linux，cygwin，和 darwin。你无法打败那些高效的工具。每一个程序员都应该学习使用/bin和/usr/bin下的所有命令。
脚本语言：Ruby。我几乎对所有的重要的脚本语言都很熟悉： Perl, Python, Tcl, Lua, Awk, Bash, 和一些我忘了的。但是我太懒了，而Ruby是目前所有脚本语言中最简单的，它应该是天堂制造的。
编程语言：没有一个我喜欢的，我觉得所有的编程语言都很扯。我倾向于Java，因为它很强，可跨平台，有多不错的工具和类库。但是Java未来会进化或是灭亡，Java还没有好到可以永远保持其领先地位。 文本编辑器：Emacs，因为这是迄今最好的编辑器。
版本管理：SVN，Perforce更好一些，但是也很贵。
Shell脚本： Bash, 因为我太懒了去学一个更好的。
数据库： 当然是MySQL，没有之一。
其它：我发现GIMP是无价的，但也是令人恼火的。我用这个东西好几年了，但什么也没干，但是我没它活不了。很讽刺吧。Firefox 越来越是我最重要的工具。如果让我去用IE和Safari，我会有严重的窒息感。 注：所有的这些工具 (Unix, Emacs, Firefox, GIMP, MySQL, Bash, SVN, Perforce) 都有一个共同点：他们是可扩展的。例如：他们都有可编程的API。伟大的程序员知道怎么编写他们的工具，而不只是去使用。
Linus Torvalds
实际上，我最终也没有用过几个工具，而我却花了一些时间让这些工具为我工作。最大的事是我自己写了个操作系统，我也自己写了个版本管理系统（git），我用的文本编辑器是 micro-emacs – 最终我也定制和扩展了它。
除了上面三个，其它的东西，我深度关心我的邮件阅读软件，我使用“pine”，并不是因为它是史上最好的邮件阅读软件，因为我习惯了，用它我会有最低限度的大惊小怪。
David Heinemeier Hansson
OS X, TextMate, Ruby, Subversion, MySQL. 这些组合让我很快乐。我希望那些有好的品味的专注于重要的事的工具。
Peter Norvig
我不喜欢那三大操作系统 – Windows, Mac, Linux。我喜欢 Python 和 Lisp. Emacs.
Dave Thomas
在使用Linux10年后我转到Mac平台有两年多了。Mac并不见得有多好，但是它不需要很牛的技术，也不需要经常维护，这让我可以让我更专心得使用它。
我并不是一个单一工具的信仰者，我喜欢换来换去的，这样可以让我有更多的经历。现在，我使用 OSX, Emacs, TextMate, Rails, Ruby, SVN, CVS, Rake, make, xsltproc, TeX, MySQL, Postgres, 还有一堆高效的小工具。没人知道我明年会用什么。
Guido Van Rossum
Unix/Linux, Python, vi+emacs, Firefox.
James Gosling
这些天，我在用 NetBeans. 用它可以干我想干的所有的事，清洁，简单和高效。这是最好的我永远要生活在其中的环境了。
Bjarne Stroustrup
Unix, sam (一个非常简单的文本编辑器), 当然，一个好的C++编译器。
Tim Bray
我喜欢 Unix-like 的操作系统，像 Python 和 Ruby 的动态语言，像Java的静态语言（具体说来是Java API） Emacs, 还有, bash, whatever, NetBeans.
Q 8: 你最喜欢的编程书是什么？
Steve Yegge
大哥，这个问题太难了。也许是”G?del, Escher, Bach: an Eternal Golden Braid” (作者Hofstadter)？虽然这不是严格意义上的编程的书，如果你要明确意义上的编程书，那么可能是 SICP (mitpress.mit.edu). Linus Torvalds
嗨。这两天我在读一些小说，或是非计算机读物（老的但是有用的 “The Selfish Gene” 作者 Richard Dawkins)。
如果要问我编程的书，我脑子里只出现了唯 一一本真正的经典的编程的书 Kernighan & Ritchie 的 “The
C Programming Language”，因为这本书太牛了，可读性强并且很短。考虑一下你想学到这世上一门最重要编程语言，并且它很要很薄，而且还有可读性，这真是一个奇迹。
也就是说，其它我很喜欢的书并不是编程的，而是关于计算机结构和硬件的。那显然是 Patterson & Hennessy 的计算机结构的书，但是我个人也许更喜欢 Crawford & Gelsinger 的 “Programming the 80386?，这是我在开始写Linux时用的书。
相似的原因，我还喜欢 Andrew Tanenbaum 的 “Operating Systems: Design and Implementation”. David Heinemeier Hansson
我喜欢 Extreme Programming Explained 其摒弃了一般的编程实践，我还喜欢 Patterns of Enterprise Application Architecture 其出众地说明了抽象和具现的平衡。
Peter Norvig
Structure and Interpretation of Computer Programs
Dave Thomas
这关系到你所谓的“最喜欢”，也许我最喜欢的是IBM的 “IBM/360 Principles of Operation.”
Guido Van Rossum
Neil Stephenson的 Quicksilver.
James Gosling
Programming Pearls 作者Jon Bentley.
Bjarne Stroustrup
K&R.
Tim Bray
Bentley的 Programming Pearls
Q 9: 你最喜欢的和编程无关的一本书是什么？
Steve Yegge
只能是一本吗？这不可能。有太多太多我喜欢的书了。
我这个月读过最喜欢的书是 “Stardust” (Neil Gaiman) 和 “The Mind’s I” (Hofstadter/Dennet).
我最喜欢的作者是 Kurt Vonnegut, Jr. 和 Jack Vance.
Linus Torvalds
我在前面说过 Dawkins的 Selfish Gene。在小说方面，有很多很多我enjoy的，但是几乎没有我特别喜欢的一本。我一般不会重读一本书，我的选择总是会变。我可能更喜欢科幻小说，如：”Stranger in a Strange Land” 作者 Heinlein，这是我青少年时期最喜欢的书，但现在并不是我喜欢的了。
David Heinemeier Hansson
1984, George Orwell.
Guido Van Rossum
Neil Stephenson 的 Quicksilver.
James Gosling
Guns, Germs & Steel 作者 Jared Diamond
Bjarne Stroustrup
我没有固定喜欢的书。目前是 O’Brian 的 Aubrey/Maturin 系列。 Tim Bray
One Day in the Life of Ivan Denisovich
Q 10: 你最喜欢的乐队/演奏家/作曲家？
Steve Yegge
喜欢的风格：古典音乐，动漫原声音乐，电脑游戏音乐
喜欢的作曲家：Rachmaninoff, Chopin, Bach
喜欢的演奏者：David Russell (古典吉它), Sviatoslav Richter (钢琴) 喜欢的动漫音乐： Last Exile, Haibane Renmei
Linus Torvalds
实际上我并不太喜欢音乐，但是当我听音乐的时候，我一般听经典摇滚乐，如： Pink Floyd ，Beatles ，Queen 和 The Who 乐队。
David Heinemeier Hansson
我喜欢很多风格。 Beth Orton, Aimee Mann, Jewel, Lauryn Hill. Actually, 所有的这些都可以归到 Girls with Guitars ;).
Guido Van Rossum
Philip Glass.
James Gosling
我喜欢听民歌: Christine Lavin, Woody Guthrie, Pete Seeger…
Bjarne Stroustrup
乐队: The Dixie Chicks. 作曲家: Beethoven.
Tim Bray
看我的博客吧。
补充说明
我之所以发现这篇文章，是因为我读到了 Jeff Atwood 的这篇名为 “Linus Torvalds, Visual Basic Fan” 的文章，这篇文章指向了 “STIFF ASKS, GREAT PROGRAMMERS ANSWER” 这篇文章，但是链接已坏了，
然后，我搜了一下也没有搜到这篇文章。然后我去了 archive.org 搜了一下，并找到了这篇由 Jaroslaw Rzeszótko 写的博客。
因为这篇博文现在找不到了，所以，我想我应该重新把它贴出来，这样其它人可以读一下这篇有意思的文章。所以，我向原作者取得了授权，再次感谢 Jaroslaw
《疯狂的程序员》经典语录~~句句真理
1.要么做第一个，要么做最好的一个。
2.什么是鸡肋课？就是每个人都在自己课表的这门课旁边标注一个“可旷”或者“选修”。
3.什么程序优化啊，都抵不上有钱，有钱就是最好的优化。说什么“效率就是金钱”，其实“金钱就是效率”。
4.中国人和外国人很大不同就在于外国人总想热衷于第一时间把自己的新发现公布出来以此向广大人民群众展示自己的水平。中国人往往喜欢把自己的新发现阴在心里，自己偷偷垄断享用。唯恐被第二个人知道。公布出去，相关部门肯定马上解决。
5.所谓好的病毒就是要：“持续时间特别长，波及范围特别广，破坏力特别大。”
6.能进别人系统偷东西，那就是小偷；能进别人系统又不偷东西，那就是黑客。
7.当你不是黑客的时候，总说：“我是个黑客”。当你真正成为黑客的时候，你往往会说：“我不是黑客”
8.程序员是值得尊敬的，程序员的双手是魔术师的双手，他们把枯燥无味的代码变成了丰富多彩的软件……
9.指针，是C语言最复杂的东西，也是C语言的灵魂
10.正如美女都不在大街上逛一样，高手根本不在群里混。美女去哪里了？多半在私家车里，高手去哪里了？多半在写程序。
11.所以说做程序员，要做就得做高手，做什么都不重要关键的是做成牛人。成了牛人就不一样了，掌握公司的核心技术，老板感随便让你走人吗？你一周随便去一个公司或者创业，对他都是极大的压力。
12.一个人静静的坐在电脑前写大卖的感觉，那是什么感觉？那就是武林高手闭关修炼的感觉。
13.天空一声巨响，老子闪亮登场。
14.资本家啊，精于成本计算。难道就没想到雇佣十个劳动生产率为0的人，就算雇佣车成本是10。也顶不上一个劳动生产率为1，雇佣成本为10的人，因为前面的那10的成本可是完全打了水漂啊。
15.巴依把阿凡提喊来想奚落他，问到：“一边是金钱，一边是道德，你选择什么？”阿凡提想都没想立刻回答：“要钱！”巴依哈哈大笑：“你阿凡提原来也是个俗人呀！如果是我，我会选择道德。”阿凡提回答：“对呀，尊敬的巴依，人缺什么就会选择什么！我选择钱，是因为不缺道德，缺钱，而您选择道德，正好说明您有的是钱但是缺德呀！”
16.所以从某种意义上说，电影好不好看，并不是电影本身好不好看，而是跟谁看。
17刘备只懂一个道理：老婆如衣服，兄弟如手足，衣服断尚可续，手足断安可续？所以，说实话，在你最困难的时候，兄弟才是最可靠的，兄弟才永远不会抛弃你。”
18.一本好书，就像高级武功秘籍一样，哪怕只从里面领悟个一招半式，功力提升起来都是惊人的，眉超风学的那半生不熟的九阴真经就是证明。
19.所以练武功和写程序一样，不在乎你修炼了几十年还是几百年，也不在乎你少林武当娥眉拜了多少门派，关键是你有没有把一门武艺炼到出神入化的境界。学武艺，最忌讳总想着去追求大而全，你要明白，其实只需要“打狗棍法”这么一招，就足够你掌舵丐帮，受用终生。
20.记住，女人都是假的，狗才永远不会背叛你，狗是唯一爱你比爱自己还多的东西。
21.我觉得疯狂没什么不好，十九世纪初，当时的科学理论认为凡是比空气重的东西都不可能长时间飞行，所以他们认为莱特兄弟是疯子。可最后疯子赢了，正因为有他们这些疯子，今天我们才能坐飞机，才能放卫星。疯子都是不要命的，怕死的怕不怕死的，不怕死的怕不要命的，所以疯子的力量大啊！在我看来，程序员只有一种――疯狂的程序员。
22.提升功力大低有两种方法，一是自己不断写代码，不断完善，不断把自己的代码写好，二是看牛人的代码。牛人的代码实在太高深了，一句看似平凡的语句，也许背后都蕴含着惊天地泣鬼神的智慧。现在你看不出什么端倪，等十年八年之后，你猛然醒悟：啊，原来大牛的代码竟是如此博大精深！
23.我就是看不惯你那读书人的样，经常做出一副搞技术天底下最大的样子。技术再好又如何啊？归根到底还不是要到市场上来，这就是所谓的“科学技术转化为生产力”
24.对男人来说钱什么都不是，但是你没钱，你就失去了让她了解你的机会。对女人来说漂亮什么都不是，但是你不漂亮，你就失去了让他了解你的机会。
25.现在的女人面临的最大的敌人是啥？不是别的女人，她们最大的敌人是电脑。搞IT的就不说了，他们的女人起码有80%很想砸电脑。其他行业的呢？要是男人迷上了游戏，迷上了上网怎么办。所以女人们，现在就得考虑：如果有一天，我们必须和游戏一起争夺男人，我们该怎么做？
26.人不怕被识破也不怕丢脸，怕就怕被当场识破和当众丢脸。
27.大四的招聘会，如果我也参加，但不是去参加招聘而是去招聘人，那该有多好
28.你要是交了很多钱，你就是上帝，就是VIP。叫你VIP实际上是叫你VERY IMPORTANT PIG ！为啥？因为你老给人家送钱，所以你就是VIP。
29.虽然说“顾客就是上帝”，现在好多顾客也确实在付过钱后把自己当成了上帝。东西验收是你签的字，钱我也拿了，老子现在就是上帝！
30.本来大学生就能解决的却一定要让研究生来解决，这叫“对工作重视”；本来一个人就能做的却一定要让三四个人甚至一个小组一起上，这叫“人多力量大”。
31.人就是如此，哪怕你某一方面牛上天了又如何？你还不是有不懂的地方。比尔?盖茨不会拍戏，张艺谋不会唱歌，周杰伦不会写程序。
32.男人，最重要的是什么？一定要信守自己的承诺。如果你没把握做到，最好就不要去承诺，你什么也不承诺，至少别人不会看不起你。
33.禅宗里有段名言，说我们在修炼禅宗之前，山脉就是山脉，河流就是河流；我们在修炼禅宗的时候，山脉不再是山脉，河流不再是河流；等我们修炼完禅宗后，山脉又复为山脉，河流又复为河流。
34.为了追求“幸福”，不得不放弃自己的梦想，回到现实中来，回到自己一直鄙视的庸俗中来。
35.力的作用是相互的，你打别人有多疼，自己的手就有多疼。与其大家都疼，还不如最开始就不要下手打。
36.写程序并不是一辈子都只是写代码。IT这一行是相当广博的，不管你是男的还是女的，不管你技术是初级、中级还是高级，你都能在这行中找到你自己合适的位置。如果你真的用心了，它带给你的会是一生的回报。
37.你知道国际象棋三原则是什么吗？
Careful，Careful，Careful。
38.“现在，最重要的是，我们要好好研究一下如何才能把技术变成钱，否则，我们就永远只是IT界挖沙的民工。”
39.找个好工作就像找个林志玲般性感漂亮的女朋友。一份优越的白领工作，在很大程度上是用来向别人炫耀的。
40.男人的工资，和女人的年龄差不多。没钱的时候，最忌讳别人追问自己的工资待遇。可男人的工资，又和女人的年龄不一样。女人要是年轻，别人问她年龄，她自然敢大方地回答。男人的工资呢？要是高了，还是怕别人追问。
41.“疯狂的程序员”绝对不是靠狂妄和拼命的程序员，而是能够脚踏实地、持续努力的程序员。一个程序员真正做到了这两点，技术上去之后，唯一能够限制他的只有想像力，到那个时候，才算“疯狂的程序员”，这种程序员啊，才能令竞争对手无比恐惧。
42.技术其实还是我们最需要的东西，以前我们没有过硬的技术，所以疯狂地追求它。现在呢？有了一点技术，便觉得技术不那么重要。如果这样放任下去，等到我们失去技术的那一天，一定会后悔莫及的！
43.永不放弃！永不放弃又有两个原则，第一个原则是：永不放弃！第二个原则是当你想放弃时回头看第一个原则：永不放弃！
一道月薪3W的java面试题
1. 智商测试开始：小明和小强都是张老师的学生，张老师的生日是某月某日，2人都不知道张老师的生日。 2.
3. 生日是下列10组中一天：
4.
5. 3月4日3月5日3月8日6月4日6月7日9月1日9月5日12月1日12月2日12月8日 6.
7. 张老师把月份告诉了小明，把日子告诉了小强，张老师问他们知道他的生日是那一天吗？
8.
9. 小明说：如果我不知道的话，小强肯定也不知道。
10.
11. 小强说：本来我也不知道，但是现在我知道了。
12.
13. 小明说：哦，那我也知道了。
14.
15. 请根据以上对话推断出张老师生日是哪一天？
16.
17.
18.
19.
20.
21.
22.
23.
24.
25. 1.小明说：“如果我不知道的话，小强肯定也不知道”。
26. 这句话的潜台词实际上是：“我应该猜对了，如果我猜错的话，小强肯定不知道”。但小明还是不确定自己究竟猜对没，需要小强来印证。M取什么值能让小明这么说呢？显然6和12不可取，如果M为6或12，N就有可能是2或7——小强凭2或7一个数字就能得知张老师的生日。则M只可能是3或9，而N只能在1、4、5、8中取值。
27. 如果M是3，N可以取三种值，结果成了“如果小明不知道，小强有可能知道（2－4，3－8），也有可能不知道（3－5）。”，在这种情况下，小明说“如果我不知道的话，小强肯定也不知道”是不符合事实的，小明不足以如此自信的这样说。
28. 如果M是9，则小明就知道N只能是1或者5。此时，小明的猜测正是N=1，而N究竟是不是1，小明也不确信，如果N不是1而是5，则就出现了小明说的“如果我不知道的话，小强肯定也不知道”。至此，实际上小明已经知道了，结果只有两种情况，只等小强来确认N是不是5。
29.
30. 2.小强说：“本来我也不知道，但是现在我知道了”。
31. 小强说“本来我也不知道”，验证了N确实不是2或者7；同时，小强也知道了“M不是6或12，M只剩下3和9可取”。若N是5，则小强应该说“本来我也不知道，现在我还是不知道”。根据第一节的推断，N=1，所以小强才能说“本来我也不知道，但是现在我知道了”。
32.
33. 3.小明说：“那我也知道了”
34. 小明就等着小强的一句话了，不管小强怎么回答，小明都会知道正确答案。如果小强说“我还是不知道”，那么小明依然可以知道“只有N=5会让小强茫然”，因此答案是9月5日；如果小强说“我知道了”，那么就必然是9月1日。
35.
36. 其实，自始至终，小明都是明白的，他只需要小强说句华验证他的猜测，对小明而言，是个非A即B的选择题。因此，按照题目本身的故事发展线索，小明的第三句话是可以不用的，很多人推导的时候却用上了这个条件——那样就有点像做数学题了
Java的秘密 使用全屏幕模式
也许用到的机会很少，但JDK还是为我们提供了这个的功能。像许多软件中的打印预览功能，还有某些文本编辑器中为了获得更大的编辑画面，也用到了全屏幕模式，如果你有兴趣写一个像ACDSee这样的软件，使用全屏幕模式可以让用户看到更大的图片画面。
什么时候会用到全屏幕模式？
也许用到的机会很少，但JDK还是为我们提供了这个的功能。像许多软件中的打印预览功能，还有某些文本编辑器中为了获得更大的编辑画面，也用到了全屏幕模式，如果你有兴趣写一个像ACDSee这样的软件，使用全屏幕模式可以让用户看到更大的图片画面。
如何使用全屏幕模式？
关键是java.awt.*里面的两个与显示设备有关的类：GraphicsEnvironment和GraphicsDevice。 GraphicsEnvironment为Java应用程序提供了特定平台的 GraphicsDevice
对象和 Font 对象集合。这些GraphicsDevice可以是各种本机和远端机器的资源，如屏幕、打印机或者是Image Buffer,甚至是Graphics2D绘图方法的目标对象。
而GraphicsDevice就是指特定的图形环境了，如屏幕和打印设备等。这样，我们就可以用
GraphicsDevice来操纵屏幕了。GraphicsDevice提供的setFullScreenWindow()方法就是设置全屏幕用的。 由于GraphicsEnvironment的构造器是受保护的(protected)，我们不能直接构造一个
GraphicsEnvironment对象来获得GraphicsDevice对象。幸好它提供了
getLocalGraphicsEnvironment()方法，用来获得一个GraphicsEnvironment实例：
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
有了GraphicsEnvironment可以调用getDefaultScreenDevice方法获得当前的屏幕设备了： GraphicsDevice gd = ge.getDefaultScreenDevice();
自己动手体验一下
有了上面的简介，写一个实例来体验一下吧：
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class FullScreenTest
{
public static void main(String[] args)
{
GraphicsEnvironment ge =
GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice gd = ge.getDefaultScreenDevice();
FullScreenWindow myWindow = new FullScreenWindow(); if ( gd.isFullScreenSupported() )
gd.setFullScreenWindow(myWindow);
else
System.out.println("Unsupported full screen.");
}
}
class FullScreenWindow extends JWindow {
public FullScreenWindow()
{
this.addMouseListener(new MouseAdapter() {
public void mousePressed(MouseEvent evt) {
quit();
}
});
}
public void quit()
{
this.dispose();
}
public void paint(Graphics g)
{
g.setFont(new Font("Arial",Font.BOLD,30));
g.setColor(Color.RED);
g.drawString("这是全屏幕模式",100,100);
}
}
用户接口设计的20个原则
世界级图形设计大师 Paul Rand（保罗·兰德）曾经说过：“设计绝不是简单的排列组合与简单地再编辑，它应当充满着价值和意义，去说明道理，去删繁就简，去阐明演绎，去修饰美化，去赞美褒扬，使其有戏剧意味，让人们信服你所言……”，由此可见，设计绝非轻而易举之事，优秀的设计更是难上加难。Joshua Porter博客当中的一篇文章——《Principles of User Interface Design》，文章中列举了20大UI设计原则，看完之后，觉得挺受启发，于是试着将其编译，希望能够给广大设计师——特别是刚入门的初级设计师，提供较好的学习机会。全文编译如下：
1.清晰度是首要工作
清晰度是界面设计中，第一步也是最重要的工作。要想你设计的界面有效并被人喜欢，首先必须让用户能够识别出它？让用户知道为什么会使用它？比如当用户使用时，能够预料到发生什么，并成功的与它交互。有的界面设计得不是太清晰，虽然能够满足用户一时的需求，但并非长久之计，而清晰的界面能够吸引用户不断地重复使用。
2.界面是为促进交互而存在的
界面的存在，促进了用户和我们的世界之间的互动。优秀的界面不但能够让我们做事有效率，还能够激发、唤起和加强我们与这个世界的联系。
3.保护和尊重用户的注意力
我们在阅读的时候，总是会有许多事物分散我们的注意力，使得我们很难集中注意力安静地阅读。因此，在进行界面设计的时候，能够吸引用户的注意力是很关键的，所以千万不要将你应用的周围设计得乱七八糟分散人的注意力，谨记屏幕整洁能够吸引注意力的重要性。如果你非要显示广告，那么请在用户阅读完毕之后再显示。尊重用户的注意力，不仅让用户更快乐，而且你的广告效果也会更佳。因此要想设计好的界面，保护和尊重用户的注意力是先决条件。
4.让界面处在用户的掌控之中
人类往往对能够掌控自己和周围的环境感到很舒心。不考虑用户感受的软件往往会让这种舒适感消失，迫使用户不得不进入计划外的交互，这会让用户很不舒服。保证界面处在用户的掌控之中，让用户自己决定系统状态，稍加引导，我想你会达到你希望的目标。
5.直接操作的感觉是最好的
当我们能够直接操作物体时，用户的感觉是最棒的，但这并不太容易实现，因为在界面设计时，我们增加的图标往往并不是必须的，比如我们过多的使用按钮、图形、选项、附件等等其他繁琐的东西以便我们最终操纵UI元素而不是重要的事情。而最初的目标呢？就是希望简化而能够直接操纵……因此在进行界面设计时，我们要尽可能多的了解一些人类自然手势。理想情况下，界面设计要简洁，让用户有一个直接操作的感觉。
6.每个屏幕需要一个主题
我们设计的每一个画面都应该有单一的主题，这样不仅能够让用户使用到它真正的价值，也使得上手容易，使用起来也更方便，在必要的时候更容易进行修改。如果一个屏幕支持两个或两个以上的主题，立马会让整个界面看起来混乱不堪。正如文章应该有一个单一的主题以及强有力的论点，我们的界面设计也应该如此，这也是界面存在的理由。
7.勿让次要动作喧宾夺主
每个屏幕包含一个主要动作的同时，可以有多个次要动作，但尽量不要让它们喧宾夺主！文章的存在是为了让人们去阅读它，并不是让人们在Twitter上面分享它。所以在设计界面的时候，尽量减弱次要动作的视觉冲击力，或者在主要动作完成之后再显示出来。
8.自然过渡
界面的交互都是环环相扣的，所以设计时，要深思熟虑地考虑到交互的下一步。考虑到下一步的交互是怎样的，并且通过设计将其实现。这就好比我们的日常谈话，要为深入交谈提供话由。当用户已经完成该做的步骤，不要让他们不知所措，给他们自然而然继续下去的方法，以达成目标。
9.外观追随功能（类似于形式追随功能）
人总是对符合期望的行为最感舒适。当其他人、动物、事物或者软件的行为始终符合我们的期望时，我们会感到与之关系良好。这也是与人打交道的设计应该做到的。在实践中，这意味着用户只要看一眼就可以知道接下来将会有什么的动作发生，如果它看上去像个按钮，那么它就应该具备按钮的功能。设计师不应该在基本的交互问题上耍小聪明，要在更高层次的问题上发挥创造力。
10.区分重点
如果屏幕元素各自的功能不同，那么它们的外观也理应不同。反之，如果功能相同或相近，那么它们看起来就应该是一样的。为了保持一致性，初级设计师往往对应该加以区分的元素采用相同的视觉处理效果，其实采用不同的视觉效果才是合适的。
11.强烈的视觉层次感
如果要让屏幕的视觉元素具有清晰的浏览次序，那么应该通过强烈的视觉层次感来实现。也就是说，如果用户每次都按照相同的顺序浏览同样的东西，视觉层次感不明显的话，用户不知道哪里才是目光应当停留的重点，最终只会让用户感到一团糟。在不断变更设计的情况下，很难保持明确的层次关系，因为所有的元素层次关系都是相对的：如果所有的元素都突出显示，最后就相当于没有重点可言。如果要添加一个需要特别突出的元素，为了再次实现明确的视觉层级，设计师可能需要重新考虑每一个元素的视觉重量。虽然多数人不会察觉到视觉层次，但这是增强设计的最简单的方法。
12.恰当的组织视觉元素，减轻用户的认知负荷
正如注明设计师John Maeda在其著作《Simplicity》中所言，恰当地组织视觉元素能够化繁为简，帮助他人更加快速简单地理解你的表达，比如内容上的包含关系。用方位和方向上的组织可以自然地表现元素间的关系。恰如其分地组织内容可以减轻用户的认知负荷，他们不必再琢磨元素间的关系，因为你已经表现
出来了。不要迫使用户做出分辨，而是设计者用组织表现出来。不要迫使用户自己去把问题搞明白，设计师应当直接在
13.色彩不是决定性的因素
物体的色彩会随光线改变而改变。艳阳高照与夕阳西沉时，我们看到的景物会有很大反差。换句话说，色彩很容易被环境改变，因此，设计的时候不要将色彩视为决定性因素。色彩可以醒目，作为引导，但不应该是做区别的唯一元素。在长篇阅读或者长时间面对电脑屏幕的情况下，除了要强调的内容，应采用相对暗淡或柔和的背景色。当然，视读者而定，也可采用明亮的背景色。
14.循序展现
每个屏幕只展现必需的内容。如果用户需要作出决定，则展现足够的信息供其选择，他们会到在下一屏找到所需细节。避免过度阐释或把所有一次展现，如果可能，将选择放在下一屏以有步骤地展示信息。这会使你的界面交互更加清晰。
15.内嵌“帮助”选项
在理想的用户界面，“帮助”选项是不必要出现的，因为用户界面能够有效地指引用户学习。类似“下一步”实际上就是在上下文情境中内嵌的“帮助”，并且只在用户需要的时候出现在适当的位置，其他时候都是隐藏的。
设计者的任务不是在用户有需要的地方建立一个帮助系统，把发现用户需要的义务推诿给用户，让用户去在帮助系统中寻找他们问题的答案。而是应该确保用户知道如何使用你提供的界面，让用户在界面中得到指导并学习。
16.关键时刻：零状态
用户对一个界面的首次体验是非常重要的，而这常常被设计师忽略。为了更好的帮助用户快速适应我们的设计，设计应该处于零状态，也就是什么都没有发生的状态。但这个状态不是一块空白的画布，它应该能够为用户提供方向和指导，以此来帮助用户快速适应设计。在初始状态下的互动过程中会存在一些摩擦，一旦用户了解了各种规则，那将会有很高的机会获得成功。
17. 针对现有问题去完善界面
人们总是寻求各种方案去解决已经存在的问题，而不是潜在的或者未来的问题。所以，不要为假设的问题设计界面，我们应该观察现有的行为和设计，解决现存的问题。这确实不是件能够让人兴奋的事情，但却是最有价值的事情，因为一旦你的用户界面愈加完善，会有更多的用户愿意使用你的界面。
18.优秀的设计是无形的
优秀的设计有个古怪的属性，它通常会被它的用户所忽略。其中的一个原因是这个设计非常成功，以至于它的用户专注于完成自己的目标而忽略了自己面对的界面，用户顺利达成自己的目标后，他们会很满意地退出界面。但是作为设计师，这可能会有点不公平，当我们的设计很优秀的时候，我们不会受到很多阿谀奉承。当然，优秀的设计师不会去介意这些，因为他们心里明白，满意的用户往往都是沉默的。
19.多领域学习，借鉴其他学科
视觉、平面设计、排版、文案、信息结构以及可视化，所有的这些知识领域都应该是界面设计应该包含的内容，设计师对这些知识都应该有所涉猎或者比较专长。不要看不起这些知识：要从中获取许多值得学习的东西，以此来提高你的工作能力。设计师的眼光要长远，要能从看似无关的学科中学习，比如出版、编程、装订、滑板、消防甚至空手道。
20.界面的存在必须有所用途
在大多数设计领域，界面设计成功的要素就是有用户使用它。打个比方，一把漂亮的椅子，虽然精美但坐着不舒服，那么用户不会选择使用它，它也就是失败的设计。因此，界面设计不仅仅是设计一个使用环境，还需要是创造一个值得使用的艺术品。界面设计仅仅能够满足其设计者的虚荣心是不够的：它必须要有用！ 做一个合格的软件架构师
软件架构师是为开发团队服务的，而不是反过来。
软件架构师是指导者，也是学习者。
软件架构师是代码守护者。
软件架构师在混乱的时候引导秩序，在模糊的时候指引方向，在争议的时候做出决定。
软件架构师编写系统最核心的代码，并且深入的理解系统。
软件架构师在公司创造高效的沟通环境。软件架构师阅读的代码远超他写的代码，并能超前发现问题。软件架构师要有前瞻的技术和产品思路。软件架构师用于承认错误，更不沾沾自喜。软件架构师善于赞扬开发团队并为完成任务而自豪
程序员们如何成为一个软件架构师
的确没想到随手写的东西有那么多的回复，不管怎样还是挺高兴的。在这里谢谢大家的关注了。其实做了
这么多年的技术脑子里总会跳出很多的想法，但很少有时间静下来仔细地思考思考，写写博客也算是一种自我归纳和总结吧。
“软件架构师”这个名词也不知是什么时候进入我的脑中的，不过一直就很疑惑，总觉得和软件的Team Leader之间有些纠缠不清。不过以我的观点来看，软件架构师除了没有行政上的职责以外，与Team Leader也并无二致了，也就是一个软件团队的核心设计者和决策人。作为一个软件团队的领头人，架构师应该具备哪些能力、素质和经验呢？
我可以把一个软件研发工作者的从业经历大致划分为3个阶段
第一阶段是新手期
这个阶段的典型特征是容易被新技术的华丽外表所迷惑。当在网上看到一种新技术的介绍或者心得，立即产生了大量肾上腺素的分泌，干什么都想用一用，如果这时有人跟他说你的这项工作用这个不合适的话，要是性子急的人估计就直接开始骂娘了，性子缓些的也会想尽理由说服你使用这个新东西，实在没办法的话，吃不下东西睡不着觉也想另找个地方用一下。
新手时期的程序员对需求和应用环境的掌控能力还不强，但却往往信心爆棚地认为自己写的代码有多么优雅高效。当问题出现时，大多数人的反应就是：“怎么可能！在我的机器上运行的好好的！”。不管看了多少书，学习了多么高效的算法，实际的工作中需求和环境始终是变化万端的。其实我也很不明白为什么那么多的技术类书籍往往都带有或多或少的炒作成份，往往夸大某方面的优势，而对缺点却往往一带而过，同时，相对思想算法讲解、技术介绍类的书籍，针对具体项目研发实例进行技术选型讲解的书真的少之又
少，或许这也从侧面反应了写书人很多，真正做研究的却很少吧。
新手期程序员的不成熟还体现在团队表现上，当一个问题提交给新手，当跟踪别人的代码段时，经常会丢手不管，还理直气壮地说“我这块没问题”，殊不知问题都没有查清楚，你又怎知不是你的问题呢？在团队研发中，我一向坚持入口点解决问题的原则，只要问题的入口点在你这里，就必须全程跟踪查到底，问题查出来了，再通知相关人员进行程序修正。团队的程序员虽然分工不同，但每个人必须对他人的程序和算法有清楚的认识和了解，因为大家是在同一个环境下工作，虽然代码有分工，可是操纵的却是相同的设备和资源。独善其身在团队开发中是最要不得的想法。
第二阶段是中级程序员阶段
这个阶段的程序员对技术、和工具的选择已经审慎了很多，可以根据具体的需求来选择需要采用的技术，可以写出详细的需求调研报告并提出设计方案，优点、缺点分析得清晰明了。在应用层面也有较强的全局理解力，在团队中也具有相当的协作能力，因此具备较强的解决问题的能力。
中期的程序员虽然在应用层面上已经相当严谨，但在系统层面的掌控力却并不强。应用系统也并非独善其身，她和网络环境、使用方法、硬件环境、操作系统、地点、时间等等诸多因素有着千丝万缕的联系。在少量用户的中底端研发中，如越来越多的呈几何级数增长的信息管理系统中，系统掌控力并非必须的能力。但在一个高端高并发量，被大量应用于不同环境的软件产品，系统掌控力就是不可或缺的能力。这种能力我认为大部分取决于知识面，工作越多，经验越丰富，就越能对不同的应用环境有着敏锐地感觉和判断。
大多数中阶段程序员限于行业，对语言的依赖还是很强，比如搞信息系统的和搞单片机的、搞网络、路由
器交换机的，由于系统层面不同，专精和对语言的理解都不甚相同。
第三阶段是高级程序员/分析师/架构师阶段
进入这个阶段的前提是多年的工作经验，广阔的知识面和对系统底层到高层的全面认识，已经使其进入了无语言无工具的层次。也就是能任何清楚地感知每种编程语言的优劣、使用范围、编码禁忌，对一个大型工程能有最全面的了解，在选择语言和确定技术方案的时候不会被自己对语言或技术工具的偏好（或者根本已经无所偏好）所影响，真正明白了其实别管是神马语言、神马技术，归根到底咱们的对象还不是CPU、内存、硬盘和网络，该做的事情一件都不能少，所谓的技术框架是对初级程序员用的，真正高级了不研究个清楚透彻都不敢让你进来。即使对同一种语言，在不同的操作系统中，如Visual C++和Unix C、AIX XLC、GNU G++等等的区别，以及不同版本之间的区别也了如指掌。这个阶段很难达到是由于对操作系统层面的清晰了解，相信一个初级程序员一路走来，大部分工作都是在Team Leader的规范和引导下完成的，每人都必须做好自己的工作，虽然在应用层面必须顾全大局，但系统层面的问题相对就难以接触了。如果不是对技术有着强烈的渴求和一定的综合能力，系统层面的工作经验将很难与你有缘。这就好比一个当外科医生的，其实做手术并不像很多人想象中那样难，一般看个几次，基本上也就差不多了，如果得到机会实际操作一下，不单是可以积累大量的经验，自信心方面的收获也是无法估量的。但是，动手术责任重大，机会不是人人都有的。技术工作者其实还是很幸福的，毕竟工作经验的取得相对于当医生还是容易的多。
高级阶段一定需要有团队的开发和管理经验，一个软件团队好比一个乐队，每个人对曲目的理解都不同，虽然司职不同的乐器，没有指挥家也会弄得一团糟。软件团队的每个人对语言、业务、能力的理解都不一样，交流方式也有别，同时他们操作着相同的系统和资源，如果Team Leader不做好规划，后果肯定可想而知。丰富的经验和敏锐的触觉神经足以判断出团队成员的编码风格和技术选择偏好，能以足够的经验和
理由说服其抛弃自己的感情偏好，从而很好地完成自己的工作。这种能力有点类似于行政的管理，但实际上却是有明显的不同的，这种管理基于的是实际的丰富经验和充足的理由，绝对不可以将行政管理中的排队观念带入，如果2个人意见相左，就必须争论，争不下去了回家想清楚理由再争，甚至直到时间来证明一切，不能说这次你听我的，下次我听你的，技术工作是绝对的，最好的、最适合需求的方案永远只有一个，如果你觉得“都可以”，只能说对行业和需求还没有吃透。
高级程序员是经常会对需求说“No”的人，对行业的深入认识和对系统及应用全局的把握能力使他具有真正指导用户的能力，规范用户的工作、思想并用计算机这个工具真正对行业产生引领作用。高级架构师能深入认识管理和技术的关系，管理上出现的问题一定要在管理上解决，工作经验不多的用户或者程序员往往会把管理上产生的问题抛给软件系统，导致系统越来越复杂，维护成本迅速增长，而管理上的问题却依然存在。但有一个现状是，往往用户提需求都直接提给负责程序的程序员，小公司估计直接就和程序员联系了，大点的也由一个其实并不怎么懂技术的所谓“客户经理”协调转发，而并非经过设计师和架构师的同意，因为他们可能现在已经在研发别的项目了。那么用户的需求是否合理，是否符合当初设计的初衷，往往初级的程序员并不知晓或有不同理解和偏好。虽然这也是实际情况所限，很难做的更好，但这也造成了很多系统的持续发展力很低，而许多用户也处于信息不对等的弱势地位，也只好将就算了。
最后，技术和社会是紧密联系在一起的。社会的进步发展决定了需求和技术的发展，一个对技术发展有着敏锐感觉的架构师必须对社会有着深刻的认识。一个良好的团队必须有新老交替才能不断进步，老人要舍得带新人。“要让一部分人先富起来，然后先富的带动后富的，最终达到共同富裕。”这是我们上学时学到的话吧，不过要是先富的尽想着向前看，根本没把后富的放在眼里，那这个团队也好、社会也好，也就没多大的持续发展力了。其实我倒是认为现在真正的大富豪还是有不少知民间疾苦的，顶层的和基层的都还能了解屁民们的生活，不了解的是中间层，他们整天生活在富庶小康的温床，经常会提及一些好高骛远、
不切实际的想法，而对那些为底层人民谋福利的事情嗤之以鼻，甚至讽刺为“用先进的技术做愚蠢的事情”，目的仅仅是为了哗众取宠和彰显自己的远见卓识。
先写到这里了，其实我自己也在为成为一个真正的架构师而奋斗，一家之言，难免有所偏差，不过还是那句话，“我们一直在努力”。