我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？
将下列原则应用到你的软件工程中，你会获得立杆见影的成果。
1. 人远比技术重要
你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。
2. 理解你要实现的东西
好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。
3. 谦虚是必须的品格
你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的话）。
4. 需求就是需求
如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。
5. 需求其实很少改变，改变的是你对需求的理解
Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注）。
如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。
你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。
你可以说是新来的开发人员把事情搞得一团糟，但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。
如果你觉得公司不让你与用户充分接触，那只能说明公司的管理层并不是真正支持你的项目。
你可以抱怨公司有关软件工程的管理制度不合理，但你必须了解大多同行公司是怎么做的。
你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念，但是为什么你没先想到呢？
需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。
6. 经常阅读
在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。
每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。
7. 降低软件模块间的耦合度
高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。
你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。
耦合度低的软件可以很容易被重用、维护和扩充。
8. 提高软件的内聚性
如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。
判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。
只有高内聚性的模块才可能被重用。
9. 考虑软件的移植性
移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如java 的宣传口号write once run many ? 译者注）。
即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。
记得从16位Windows移植到32位windows的“乐趣”吗 ？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。
好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。
10. 接受变化
这是一句老话了：唯一不变的只有变化。
你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现（参见“Architecting for Change”，Thinking Objectively, May 1999）
通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。
11. 不要低估对软件规模的需求
Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。
今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。
在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。
在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。
12. 性能仅仅是很多设计因素之一
关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。
但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。
13. 管理接口
“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你应该在开发阶段的早期就定义软件模块之间的接口。
这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后，模块怎样实现就不是很重要了。
从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。
14. 走近路需要更长的时间
在软件开发中没有捷径可以走。
缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。
在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。
你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。
避免走捷径，只做一次但要做对（do it once by doing it right）。
15. 别信赖任何人
产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。
大部分产品供应商希望把你牢牢绑在他们的产品上，可能是操作系统，数据库或者某个开发工具。
大部分的顾问和承包商只关心你的钱并不是你的工程（停止向他们付款，看一看他们会在周围呆多长时间）。
大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计的模型而用自己认为更好的。
只有良好的沟通才能解决这些问题。
要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。
16. 证明你的设计在实践中可行
在设计的时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你的设计是能够工作的。
你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。
17. 应用已知的模式
目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。
一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。http://www.ambysoft.com/processPatternsPage.html收藏了许多开发模式的信息。
18. 研究每个模型的长处和弱点
目前有很多种类的模型可以使用,如下图所示。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。
19. 在现有任务中应用多个模型
当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。
当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。
程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。
20. 教育你的听众
你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。
教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。
另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候（比如UML-译者注），你的团队才能实现真正的合作。
21. 带工具的傻瓜还是傻瓜
你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。
使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。
22. 理解完整的过程
好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。
软件开发是一个很复杂的过程，还记得《object-oriented software process》第36页的内容吗？除了编程、建模、测试等你擅长工作外，还有很多工作要做。
好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。
23. 常做测试，早做测试
如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。
建立一个技术原型供技术评审使用，以检验你的软件模型。
在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。
24. 把你的工作归档
不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。 给每个模型一些概要描述以使别人很快明白模型所表达的内容。
25. 技术会变，基本原理不会
如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。
软件建模技术是需要多年的实际工作才能完全掌握的。好在你可以从我的建议开始，完善你们自己的软件开发经验。
以鸡汤开始，加入自己的蔬菜。然后，开始享受你自己的丰盛晚餐吧。
程序员的10种级别
来源：http://www.javaresearch.org/faq/thread.jsp?column=723&thread=46872
|
发表时间: 2006-02-20 16:22
作者：jshao
头衔: JR元老专家
|
|
程序员的10种级别
第一级：神人，天资过人而又是技术狂热者同时还拥有过人的商业头脑，高瞻远瞩，技术过人，大器也。如丁磊，求伯君。
第二级：高人，有天赋，技术过人但没有过人的商业头脑，通常此类人不是顶尖黑客就是技术总监之流。
第三级：牛人，技术精湛，熟悉行业知识，敢于创新，有自己的公司和软件产品。
第四级：工头，技术精湛，有领导团队的能力，此类人大公司项目经理居多。
第五级：技术工人，技术精湛，熟悉行业知识但领导能力欠加，此类人大多为系分人员或资深程序员，基本上桀骜不逊，自视清高，不愿于一般技术人员为伍，在论坛上基本以高手面目出现。
第六级：熟练工人，技术有广度无深度，喜欢钻研但浅尝辄止。此类人大多为老程序员，其中一部分喜欢利用工具去查找网上有漏洞的服务器，干点坏事以获取成绩感。如果心情好，在论坛上他们会回答菜鸟的大部分问题。此级别为软件业苦力的重要组成部分。
第七级：工人，某些技术较熟练但缺乏深度和广度，此类人大多为程序员级别，经常在论坛上提问偶尔也回答菜鸟的问题。为软件产业苦力的主要组成部分。
第八级：菜鸟，入门时间不长，在论坛上会反复提问很初级的问题，有一种唐僧的精神。虽然招人烦但基本很可爱。只要认真钻研，一两年后就能升级到上一层。
第九级：大忽悠，利用中国教育的弊病，顶着一顶高学历的帽子，在小公司里混个软件部经理，设计不行，代码不行，只会胡乱支配下属，拍领导马屁，在领导面前胡吹海侃，把自己打扮成技术高手的模样。把勾心斗角的办公室文化引入技术部门，实在龌龊！
第十级：驴或傻X，会写SELECT语句就说自己精通ORALCE，连寄存器有几种都不知道就说自己懂汇编，建议全部送到日本当IT产业工人，挣了日本人的钱还严重打击日本的软件业！
其中又以前两级和后两级最为难得，其余级别只要努力，皆有可能达到。
|
|
JAVA高手的基础素养
来源：http://www.javaresearch.org/faq/thread.jsp?column=723&thread=38473
|
发表时间: 2005-10-07 22:25
作者: xuyy_cn
头衔: JR元老专家
|
|
世界上并没有成为高手的捷径，但一些基本原则是可以遵循的。
1、扎实的基础
数据结构、离散数学、编译原理，这些是所有计算机科学的基础，如果不掌握它们，很难写出高水平的程序。程序人人都会写，但当你发现写到一定程度很难再提高的时候，就应该想想是不是要回过头来学学这些最基本的理论。不要一开始就去学OOP，即使你再精通OOP，遇到一些基本算法的时候可能也会束手无策。因此多读一些计算机基础理论方面的书籍是非常有必要的。
2、丰富的想像力
不要拘泥于固定的思维方式，遇到问题的时候要多想几种解决问题的方案，试试别人从没想过的方法。丰富的想像力是建立在丰富的知识的基础上，除计算机以外，多涉猎其他的学科，比如天文、物理、数学等等。开阔的思维对程序员来说很重要。
3、最简单的是最好的
这也许是所有科学都遵循的一条准则，复杂的质能转换原理在爱因斯坦眼里不过是一个简单得不能再简单的公式：E=mc2。简单的方法更容易被人理解，更容易实现，也更容易维护。遇到问题时要优先考虑最简单的方案，只有简单方案不能满足要求时再考虑复杂的方案。
4、不钻牛角尖
当你遇到障碍的时候，不妨暂时远离电脑，看看窗外的风景，听听轻音乐，和朋友聊聊天。当我遇到难题的时候会去玩游戏，当负责游戏的那部分大脑细胞极度亢奋的时候，负责编程的那部分大脑细胞就得到了充分的休息。当重新开始工作的时候，我会发现那些难题现在竟然可以迎刃而解。
5、对答案的渴求
人类自然科学的发展史就是一个渴求得到答案的过程，即使只能知道答案的一小部分也值得我们去付出。只要你坚定信念，一定要找到问题的答案，你才会付出精力去探索，即使最后没有得到答案，在过程中你也会学到很多东西。
6、多与别人交流
三人行必有我师，也许在一次和别人不经意的谈话中，就可以迸出灵感的火花。多上上网，看看别人对同一问题的看法，会给你很大的启发。
7、良好的编程风格
注意养成良好的习惯，代码的缩进编排，变量的命名规则要始终保持一致。大家都知道如何排除代码中错误，却往往忽视了对注释的排错。注释是程序的一个重要组成部分，它可以使你的代码更容易理解，而如果代码已经清楚地表达了你的思想，就不必再加注释了，如果注释和代码不一致，那就更加糟糕。
8、韧性和毅力
这也许是“高手”和一般程序员最大的区别。高手们并不是天才，他们是在无数个日日夜夜中磨炼出来的。成功能给我们带来无比的喜悦，但过程却是无比的枯燥乏味。你不妨做个测试，找个10000以内的素数表，把它们全都抄下来，然后再检查三遍，如果能够不间断地完成这一工作，你就可以满足这一条
|
软件高手是这样练成的
来源：http://www.javaresearch.org/faq/thread.jsp?column=723&thread=39051
|
发表时间: 2005-10-15 00:53
作者：xuyy_cn
头衔: JR元老专家
|
|
中国人大都喜欢用武侠小说来比较软件开发，但是在实战武功中，只有葵花宝典才是最厉害的，也只有掌握了葵花宝典，才能称为“不败”。
但什么才是软件开发的葵花宝典？
让我们先从一些现象出发。我们的前提是，软件开发是一项智力密集型劳动。对于智力密集型劳动，我们观察到的现象是，个体的表现差异很大，团队的表现差异很大，组织的表现差异很大，国家的表现差异很大。这不象体力占主要的劳动，象百米王跑百米的速度也仅比我快50%。但在棋类运动中，一个高手可以车轮战数位低手，而且毫无例外地将他们一一击败！
这些智力运动员表现出的特点是，计算精确而且速度快。其行为很象东方不败。虽然关于葵花宝典的传说很多，但最准确的描述只有一个字“快”。东方不败已经快到了吓人的地步。就象卡斯帕罗夫已快到了深蓝的地步。
有一则关于物理学家玻尔的轶事，有一次玻尔在普林斯顿大学听两个年青教授演讲他们的工作成果。期间玻尔突然发言说，如果照你们的研究算下去，会得到一个很有意思的推论。结果两个年青教授回去计算了两天，果然得出了同样的结论。玻尔是如何做到这样快的？
在软件开发中，我们同样注意到这样一种高手，他们可以每天写出一千行左右的高品质代码。他们可以运用已有的一些软件包，迅速完成一个新的产品。他们可以在很短的时间内，学会一项新的程序语言或是新技术。他们表现出一种神奇的速度。
在武侠小说中，所有的高手都有一些凡人不能企及的表现。象张无忌学太极，用龙爪手击败龙爪手名家；乔峰用太祖长拳击败天下英雄；姑苏慕容以其人之道还治其人之身，令狐冲一剑剌瞎十几双眼睛等等。我认为，之所以他们能做到这样，关键是在于他们快。
快并不意味着不准或品质差。快与品质并不矛盾。
高手的快，其实包含着很高的品质在其中。如果你因为高手的快，就质疑其品质，那就相当于在问：东方不败出手那么快，会不会刺不准？东方不败并不满足于刺死对手，他会在对手身上刺朵花。他把杀人变成了艺术。准确来说，他真正的兴趣不在杀人，而在于艺术。
退一步说，就算东方不败第一击有点偏差，他稍作修正后，马上跟上的第二第三击，也会击中他想击中的地方。在武功差的对手剑还没拨出来的时候，他已杀死对方并刺上了一朵花。
所以真正的软件高手，他并不满足于他的代码能有效地工作了，他认为编程是艺术，并醉心于其中。在低手能写出一个版本的时间里，他已经写出了第十版。其品质当然不可同日而语。就象一个九段棋手，在给定的时间里，他能计算十种可能，并将每种可能计算到100手之后，从中选择一种最有利的下法。低手岂有苟全的机会？
高手写软件总是不停地在重构(refactoring）。高手喜欢迭代式开发。高手说，增量就是打补丁，迭代就是推倒重来。对于软件这种东西，写一遍它可能ok（做到这一点也不容易），写十遍就是一个伟大的产品，再多写一遍它就更伟大些。
高手快的诀窍在于他很熟悉各种东西。高手看书很快，因为每一本新书里，值得他好好看的新技术只有一两章的内容。他能迅速看完，并准确领会这本书的中心思想和价值。而对于一个新手，每句话都是新的，他都需要去理解，每一段例子，他都需要去试。
很少看到一种100%全新的技术或理论。就象java language specification里说的，java没有使用任何新技术，用的都是业界久经考验的技术。对于高手来说，那些技术都是他所熟悉的。自然，很快他就从一个c++高手变成了java高手。如果一个编程新手学java，学两年也不如一个高手学两个月的。高手学新东西快。
高手写代码速度快。统计结果说，人均每人月的有效代码速度大概是300至400行。但那是业界平均生产效率。对于高手来说，这个数字太低了。每天写300至400行是完全有可能的。因为在写代码时，所有知识都已具备，已经没有任何需要他多花时间的事情了。他甚至很少需要debug。
高手重用代码的能力很强，熟悉新的api的速度很快。这也是因为，他曾经使用过很多的api，重用过很多的代码。他知道哪些是可用的，哪些有缺陷。他既过用qt，也用过gtk+，也用过windows api & mfc，也用过awt & swing。新的api对他来说，也是老熟人。
高手喜欢用轻量级的工具，象vi，notepad，最多到ultraedit这样复杂的。高手用这种工具写出很多的东西。这些工具就象东方不败的针。那根针已具有神奇的魔力，有时候它可以当激光枪来用。
对于一些重量级的工具，高手虽不常用，但一经使出也威力大于常人。如果让东方不败用剑，最厉害的剑术名家也会败得很难看。高手其实用过很多的重量级工具，而且深知其优缺点。所以使出来，就会把威力发挥到最大，而把缺陷减少到最小。而低手则不然，总是把缺陷加以大大的发扬而浑不知其精髓何在。就象很多人学用uml、rup、xp、design pattern那样。
高手所学博杂且融会贯通。高手做什么都快，当低手还在一愁莫展的时候，高手已经圆满解决问题，去干别的事去了。
相信你有一点点想成为高手了。但是有一个问题亟等解决，那就是“欲练神功，必先自宫”的问题。这一点其实是有比喻意义的。就是说，你必需抛弃一些世俗的人们很看重的东西。有诗为证：
世人都晓高手好，只是寂寞受不了
世人都晓高手好, 只有名利忘不了
世人都晓高手好, 只有金钱一定要
世人都晓高手好, 天下美女都要抱
世人都晓高手好, 不写代码最最好
高手的武功不是一朝一夕练成的。还记得玻尔那件轶事吗，玻尔回答说，他年青时也计算过很多的问题。在很多计算的基础上，高手能培养起一种感觉。高手不写代码就能做设计是因为他以前写了很多的代码。而且他们会保持写代码，以保证自已的水平不下降。想一想九段高手是如何练成的。最难做到的是能忍受十年磨一剑的寂寞。别人在父母那里撒娇时，他们在一旁用功。十年磨一剑，剑就成了东方不败的针。
在你下定决心要做高手之后，也就是下定决心抛弃那些世俗的追求之后，也就是你下决心忍受那些来自于庸俗的人的白眼、攻击和谩骂之后，你就具备了练成神功的必要条件。
事实上其实你不必一开始就练神功，一开始大家可能是为了钱，房子，汽车，美女才编程序的，然而后来艺术就从中产生了。那时高手就不再关注那些东西了。卓别林曾说过，他开始进入那个圈子也是为了钱，后来艺术就从中产生了。当然，也有人一开始是为了艺术，后来变成为了钱。
所谓三十而立，就是说到了三十，你找到了你的真爱，值得用一生去追求的那种。比如说有的人到了三十认为这一辈子应该赚尽可能多的钱，这也没什么不好，也可以把赚钱本身变成一种艺术，所谓资本运作是也。所以在三十以前，有些私心杂念没什么。三十以后还这样是可耻的。而我，想做一个程序员。
每个人做自己最喜欢的事。这个世界需要程序员，也需要资本运作。所有真正的程序员，他最喜欢的事是编程和他自已。如果他后来去做ceo去了，不再编程，只说明他本来不是一个真正的程序员。
在成为高手的路上，要有热情，要循序渐进，要持之以恒。
要靠自己，书要快快地看。要试图迅速理解其主旨。其实你快快看所接受的信息量，与慢慢看接受的差不多。能明白多少很大程度上取决于你的功底。以后用到再回过头来看。一本对你来说新东西太多的书，不要指望看一次就全理解吸收。就象很多功力不够的人看design patterns那本书一样。慢慢看还不如找到多种 信息来源，都快快看一遍。对于一个完全陌生的领域，只看一本书很远远不够的。
要靠自已，事要快快做。有一个朋友，几年前我介绍他去玩玩linux，他也表示想玩，但他现在还没碰过。他失去了很多机会。
平时要有意识提高自己写代码的速度，其实你一天写15行有效代码，与你写50行有效代码，其品质是差不多的。你应该把那些业界平均水平抛诸脑后，把超越自己做为唯一目标。等到你写了很多各式各样的代码，你的水平就不一般了。一个老师曾向我介绍他的学英语的决窍，他说你去啃原版小说，啃到50本，就和一般人有很大距离了。就是这个理。如果你写得太慢，怎么能写得多？水平怎么能提高？
要靠自己，学很多别人怕学的东西。低手总会说：这么多东西怎么学得过来啊。于是就少学或不学。这样就成不了高手了。高手有非常广的知识面，有很丰富的经验。知道很多低手不知道的事。玩过很多低手听都没听过的东西。
要靠自己，努力满足客户的各种需求。个人技能是在满足客户的各种需求的过程中提高的。比如你喜欢用delphi，客户说一定要用vb，那你就答应他，然后把自己培养成为vb的高手。用户的需求看似**，但对你是一个机会。
怎样才能做到看书快，写代码快，学新东西快，一个显而易见的途径就是将工作并行化。你在一台机器上make时，同时可以在看别的文档和聊天。对于计算机是这样，对人也是这样。如果你只能串行地处理问题，你的速度将提高有限。你的大脑有很大潜力可挖，它应该是一个多任务分时系统。努力减少它idle的时间。搞经济的samuelson被人称为human brain main frame，可见他的大脑有多快。
让你的思维快起来，你就会区别于那些反应迟钝的人。如果你不能让人生的道路变长，就让它变宽。这世界变化快，需要你变得比它快才行。
这样加快并不会让你短命，相反，你有更多的时间来享受生活和锻炼身体。你的生活将更有品质，更丰富，更有意义。面对变化，你将立于不败之地。我们都是和自己赛跑的人，需要跑得比昨天的自己更快。
|
|