posts - 156, comments - 211, trackbacks - 0, articles - 6

2007年12月8日

有一位网友,今年大二,询问我怎样才能成为技术高手. 我并不确定如何定义所谓的技术高手, 但是既然问到我, 便列举一下可能相关的事实.

首先请明确以下事实:
A. 挣钱能力和技术能力相关,但不成正比。
B. 他人的信任与信赖和技术能力无关。
C. 泡妞能力和技术能力可能负相关,请谨慎面对。

   没有人知道未来是什么样子. 也没有人能够保证自己永远都是技术大潮中的弄潮儿. 如果你只是担心知识的老化, 担心能否长期的保有一份工作. 那么只需要不失去别人的信任,越来越熟练的做好本职工作就可以了。任何工作中当时用到的知识永远都只是很少的部分,只要别人给你机会重新学习,你的人生经验就会是你最宝贵的财富。

   大二的小孩不要每天尽整些没用的东西。认真学好自己的专业课。做软件开发并不需要什么高深的知识,但是接受知识传承,得到全面教育的时机却是一去不回的。

   不要怕学得多,更不要自以为学得多。我在学校的时候,横扫图书馆的哥们并不少。

    读了书并不意味着懂得了道理。用自己的语言能否讲述学过的内容?能否用个简图勾勒Unix内核的结构?学过一门语言到底它有什么不同,能否勾勒发展的脉络?你学过的东西并不是你的东西. 你既无法消费它,也无法贩卖它. 在书本以外你是否真的意识到这些知识的存在性? 最重要的问题是, 你创造的东西在哪里?

    读书开始的时候半知半解是正常的。这就如同张无忌背七伤拳经,总有一天你会懂得,只是需要不时的去回味。数学典籍中经常有这样的说法,本书内容是封闭的,只需要某某领域知识,但是掌握它需要数学成熟性。成熟是需要时间的。

    读书不是以数量取胜。一个领域中类似的书只要细读一本,完整的读下来,读的时候多方参照,做简短的笔记。读一些原始的文献,读大师的原著。尽量选用英文的经典教材。懂一点学科的历史,知道什么是文化。了解一些学术界的八卦,吹牛的时候多一些谈资。
     
    学习任何一个领域都需要深入, 需要掌握大量的相关细节, 因为只有这样才能够不再被细节问题所干扰, 而集中精力于真正的思想核心.  

    拳不离手,曲不离口。连Knuth老兄都在勤奋的敲程序,所以请不要找借口, 先编上十几二十万行代码再说话。编写而不是抄写。

   天下没有免费的午餐。不付出相应的成本,无法得到相应的回报。学习没有捷径,只有方法。只是方法正确并不能保证你走到终点,毅力,机缘都是不可或缺的。你是否能够1天10小时以上持续地考虑同一个问题,是否能够保持同样的注意力坚持到每本书的最后一页, 是否一年365天对新鲜事物总是保有一份天真的好奇。

   在工作中除了抽象的思想和具体的技术知识之外,还有大量小的trick. 例如调用equals的时候把常量放在前方if(MY_CONST.equals(myVar)).
 一般不可能通过书本学习掌握所有这些技巧,只能在编程的实践中观察总结,更多的时候是要你主动思考,重新去发现这些方法。一个人的工作效率很大程度上是受其工作习惯所制约的,你是否在随时随地的改进自己的工作?

    怎样才能做技术高手?这个问题我并不知道答案。公司里所需要的也不是技术高手,而是能够解决问题的人。不过如何培养合格的程序员,在公司内部也有两种看法。adun说要给他们指明职业发展的方向,关心他们遇到的困惑。这是P大的浪漫主义情怀。X罗说要给他们可以完成但是不易完成的任务,等待大浪淘沙后的结果。这是T大的现实主义精神。

    开源是不可阻挡的历史洪流,我们只能改变自己的思维方式,调整自己的行为目标来适应它。

    面对未来的挑战,Alan Kay有一句名言:The best way to predict the future is to invent it。如果你不知道该怎么创造,那就先从捏造开始练习吧----事物之间总是可以建立关联的。

posted @ 2007-12-08 03:14 canonical 阅读(2459) | 评论 (20)编辑 收藏

    现在讲软件工程的, 所谈论的多半是项目工程, 即如何在有限的时间内配置使用有限的资源在单个项目中达到既定的目标. 传统上, 在这一领域基于预测和计划的瀑布方法曾经占据主流, 但是随着项目的日益复杂化, 各种基于演化(evolution)思想的工程方法在实证中逐渐发展起来. 在时空跨度更大的软件工程领域, 例如延展到软件的不同版本以及多个相似项目的工程中, 演化更是逐渐取得了无可置疑的主导地位. 但是, 从另一个方面说, 目前所有这些软件工程方法所推崇的演化实际上都是非常有限的, 它们通过迭代(iteration)所能够描述的演化过程都只是片断性的, 例如一个项目中的演化, 一个软件产品的演化, 最大的莫过于一整条软件产品线的演化. 所有这些演化过程都面临着一个天然的屏障: 商业公司.在公司内部, 知识或代码可以由开发人员携带到下一个项目, 或者从一个小组传播到另外一个小组, 在新的基础上继续演化的进程. 但是核心的知识或者代码一般只能通过商业交易传达到其他公司, 这是一条非常受限制的途径. 而一个单个公司所开发的软件包, 即使是平台级的产品, 如果只是内部使用, 受限于该公司所从事的业务领域, 其所面临的使用检验也是非常有限的. 而且出于经济上的原因, 单个公司往往无力支撑多个实现同样功能的解决方案, 因而它倾向于消灭软件中的多样性, 这有可能会进一步限制演化的进程.  
    开源(OpenSource)软件为软件演化创造了新的可能性.商业友好的开源软件可以被不同的公司自由的运用于不同的业务, 因而可以参与到不同的局部演化过程中. 在应用的过程中, 开源软件面临着巨大的重构压力(这往往是超越了应用最广泛的封闭源码软件包的), 有可能保持更快的演化速度. 而通过对开源软件的回馈, 对开源软件的改进可以传播到时空范围跨度巨大的软件开发过程中. 而且基于源码的开放性, 开发人员的知识交流也随之开放起来. 类比于Darwin进化论, 我们可以说开源驱动了整个软件业界的共同进化(co-evolution).
    多年前, Eric Raymond在著名的文章"大教堂和市集"中 http://263.aka.org.cn/Docs/c&b.html, 提出了开源的工程价值, 但其所关注的重点仍然只是单个软件如何在开源的模式下演化, 从今天的观点看来, 这篇战斗檄文已经显得有些局促了. 开源所造就的巨大演化空间远远超越了软件工程所能够提供的. 开源软件现在已经在商业开发领域站稳了脚跟,也渐渐超越了单个公司能够控制的范围. 可以说开源软件的发展是无可逆转的, 我们已经不会也不应该再回复到原先的封闭世界中.

posted @ 2007-12-08 02:58 canonical 阅读(1166) | 评论 (0)编辑 收藏

   每当我在文字中对函数式语言有些不敬之意时,便好像动了某些人的奶酪,以至我的言辞总在被曲解后遭到排斥。我想这就是因为视角差异过大所造成的. 但是谦虚谨慎是传统的美德, 不能容纳他人的观点只会妨碍自己在某些方向的探索。
   首先请不要轻易怀疑我的知识水平。当然如果总无法聚集起足够的注意力来理解别人话语中的细节,我也无话可说。
   容纳他人的观点就意味着不要总在自己的话语体系中试图找到反例. 一个人总是受限于他的知识范围,因此他也经常在自己的知识范围内篡改曲解别人的意见。我从未说过 "一个具体的问题是现有的通用语言无法描述的". 我说的是"现实开发中所需要处理的结构问题并不是在语言层面得到充分解决的", "现在的通用语言也是无法有效承载Domain Specific Structure的". 请注意我对定语和动词的选择。其实我已经举了大量的例子来进行说明,但可能因为大多数人不是物理背景,对相关的内容不熟悉,所以直接无视了。这也很对,符合物理学的精神。

   可能大多数人都知道函数式语言和命令式语言都是和图灵机等价的,因此它具有某种终极能力,怀疑它无异于怀疑我们世界存在的基础。但是请注意,这种等价性是数学性的。它潜在的要求是无限的能量和时间消耗。如果在限定的物理约束下,我们会发现我们的选择范围会大大缩小。所以我说"函数式语言和命令式语言的计算能力相同,但是在具体的情形下它们的描述能力是不同的". 比如说我现在有无穷多种方式从北京跑到上海,但是如果限定只允许用1升汽油,那么我们的选择就近乎于0。飞机和汽车的运输能力是相同的吗。物理学的一个基本精神在于一种物理性的约束是始终存在的。而事实上,我们在实际工作中也总是在各种有限的物理条件下工作。

   也许有些人认为这种区分是无关紧要的,我们只关心某种终极的东西。但是物理学中有着太多的例证,说明在有限约束下,整个系统呈现出完全不同的性质。在通信领域我们都知道Shannon定理,它的物理诠释是在有噪声的信道上可以有效的进行准确的信息传递。但是这一诠释只能在有限的数学精度(远大于我们实际需求的精度)上成立, 在绝对准确的数学意义上,这是不可能的事情。

   你觉得现在的通用语言做起领域相关的东西来很方便吗,这就是我所谓无法有效承载的含义。在这里我也没有否认"未来的牛语言可以轻松搞定目前难题"的可能性。

   因为所有的软件设计最终都要落实到某种代码实现上,所以怎么会有什么神秘的软件结构是现有的语言无法描述的呢。但是ErLang中那种高并发,支持错误恢复的程序结构是在其他语言中能够轻松实现的吗。很多人不是在潜意识中认为ErLang的成功是函数式语言排他性的成功吗,不是认为命令式语言无论如何实现不了ErLang的程序结构的吗。很显然,在命令式语言中是无法直接实现ErLang中的程序结构的,否则它就变成了函数式语言,但是所有发生在ErLang世界中的事实都一样可以发生在命令式语言的世界中。ErLang语言的编译器可以是使用命令式语言实现的,在终极的意义上,语言之间能有什么区别呢?

   我说"实际上现在的通用语言也是无法有效承载Domain Specific Structure的", 这还有另一层含义。通用语言设计总是要考虑到内置结构的某种通用性,设计时能够凭依的信息较少,因此不可能直接制造某种复杂的领域相关的结构。而目前已知的通用语言中提供的结构抽象的手段也不够强大(实际上我认为任何语言都不会强大到内置所有结构,也无法提供所有的结构抽象手段), 相当于是把领域结构问题推给程序员解决。这就如同C语言把内存管理推给程序员解决一样。现在ruby比较流行不就是因为它能够动态处理很多结构问题吗,但是它现在所作的一切就是足够的了吗。难道二十年之后再来看这个语言,不能够发现它存在着巨大的改进空间吗。我们目前在Witrix中通过tpl模板语言,bizflow extends等机制,结合整体框架设计实现了一些与ruby不同的结构构造方法。这些手段都极大的增强了我们面对领域问题时的信心,也确保了我们的领域知识是技术层面上可积累的。但是即使这样,我对程序发展的现状就是满意的吗?难道不存在更加丰富的结构知识等待我们去发现吗?一般人总是习惯接受已经存在的现实,在有限的职业生涯中把它们当作不变的真理,却没有耐心的去思考如何去改变。

  我认为很多结构问题不是需要在语言层面得到解决的,而是应该在独立的结构层(平台,框架)进行解决。这意味着没有必要在语言层面直接内置某种特定的结构,内置某种特定的结构抽象手段。这基本类似于说不要把集合论扩大到包含所有的数学关系,请在别的学科分支中进行研究。需要注意的是,我所谓的领域知识不是特定的业务知识,而是从业务知识中可以分析得到的某种更加通用的普适的结构知识,甚至是可以使用数学进行精确描述的。

  现代软件发展的时间还很短,与数学和物理学这样深刻的学科相比,它无疑是相对幼稚的,是待成长的,是更加的不完美的。在程序构建的基本问题上并没有抽象出什么可以实际操作的精确规律。这是所谓Pattern在软件业流行的部分原因:我们希望用这种半形式化的方式捕获某种思考的结果。但是软件真的除了基于抽象数学的全局的全称性的证明之外,不能够在局部进行某种更加复杂,更加严谨的分析吗。

   我们说结构问题是独立的,这也意味着它和具体的实现语言具有某种意义上的分离性。通过一种语言书写的结构可以在另一种语言中得到表达。我们可以建立语言中立的技术结构。一种所谓的结构在概念上具有某种确定的形态,我们可以脱离具体的语言来理解它。例如我说"面向对象的继承关系从结构观点上看是两个一维集合之间的覆盖关系". 在java中我们可以直接使用语言提供的继承机制,而在C语言中我们就需要建立某种结构体,手动维持所有的指针关联。而在Witrix平台中,我们从继承的结构诠释出发,定义了更加复杂的extends算子,这就需要利用java语言编制特定的parser来实现了。但是显然,在思考的时候我们所有的思维指向是结构本身,而不是任何通用语言的语法。

   在物理学中,通过摄动分析我们可以清楚地意识到:同样一个物理现象对应的数学模型可以是众多的,但是在特定的参数区我们会选择某种特定的数学表述,并确定其中的待定参数。

   delta函数是物理学家狄拉克引入的,在Schwatz引入分布概念建立广义函数论之前,物理学家们已经使用这一函数工作了很多年。后来Abraham Robinsen利用数理逻辑方法,建立了非标准分析,通过模型论的方法精确定义了无穷小的概念,从更加直接的角度论证了delta的合理性。但是在物理学家看来,这些数学又有什么区别呢?物理学只是按照物理的诠释进行工作,具体的数学只是它可选的工具而已。

   物理的真理并不是蕴含在数学中的,它需要我们独立的探索,从与数学不同的观点进行思考,检验,最终我们才能做出真正的发现。广义相对论可以采用Riemman几何进行描述,但是它的物理诠释却是Einstein提出的. 没有人说Riemann或者Hilbert发现了广义相对论。另外一方面,因为Einstein的工作触发了对于微分几何的更加深入的研究,靠着物理直觉的导引,我们将这一数学分支推进到了难以想象的深度。"数学是无法涵盖物理学的". 这不是说最终物理学无法采用数学语言进行描述,而是说在这一发展过程中,所有思想的推动来源于物理学的经验,来源于我们在这个物质世界上所进行的反复验证。不是在一个封闭的小屋中,整天摆弄各种数学符号,我们就能够发明所有的物理公式所对应的数学。实际上,现在学术界普遍承认,没有物理学的推进,很多数学的进展是不可能发生的。

   物理系每天都在演算着Feynman路径积分, 但是所有人都知道这是没有什么严格的数学依据的.目前并无法定义路径积分的收敛性,但是所有人对此避而不谈. 只要形式演算合法,物理预测符合实验, 合理性的证明只是数学家们的事情. 在量子场论中所采用的重整化(Renormalization)方法不过是回避无穷大问题的一种形式手段.我们仍然无法在数学层面对所有的演算都给予合理化解释. 在更多的物理分支中工作,你就会发现物理学家的胆子不是一般的大。也许在未来我们能够发现这些物理过程背后数学机制的精确定义, 但也许最终我们也无法找到合适的定义方式. 但这对物理学家来说, 并不是很大的打击.因为指引我们的是物理直觉,是独立于数学的物质世界的意象。

   我所想讨论的不是某种终极意义上的可能性,不是绝对概念之间的冲突,而是在物理现实的约束下,我们如何才能有效工作的问题。我已经反复表述了自己的观点: "结构是可抽象的,是具有独立意义的。这就是Witrix所提出的面向结构的设计视角。不是强调对象的所谓业务含义,不是强调某种通用语言(例如ruby)的灵活的语法结构。在这之间存在着厚重的具有物理意义的可以进行结构分析的技术层". 也许有人觉得我说的这是废话, 但是当系统化的执行一种思想的时候,就会揭示出未预料到的可能性. 整个Witrix平台简单的说起来就是"面向结构的级列分析", 但是如何找到合适的技术形式来体现这一思想,却绝对不是一件平凡的事情. "在Witrix中我们实现的代码重用程度和程序整体结构控制能力是超越了目前所有已知的公开技术的。这不是什么哲学,而是我们在残酷的商业竞争中得以生存的资本".http://canonical.javaeye.com/blog/126467

   在我看来,计算机领域充斥着纯数学的深沉遐想和从工程实践而来的轻佻常识,还没有注意到物理学所能带来的不同的同样深刻的视角。我常说,好好学习物理是必要的,因为这个世界远比你想象的要复杂的多。


posted @ 2007-12-08 02:51 canonical 阅读(1025) | 评论 (7)编辑 收藏