aimingoo的专栏

今天下午做了这幅脑图，为便于显示，切成了四个部分，描述了我对架构师能力的基本理解。 这四幅图不见得能阐述架构师能力的全部，但我尽量给出范围和有用的建议，希望能对大家有所启发和裨益。 图一：本能力模型的基本角度。与爱立信人力模型做了一个对比，请注意没有涉及到与“个人内在素质”相关的任何部分。所以类似于诚信、坚韧、耐心等等这类素质不在讨论的范围之内。图二：个人特性 

VCL已死，RAD已死        ——SD2C中未能尽言的话题 四、后RAD时代：界面可视，到界面可描述－－－－－RAD过程与快速原型构建的理论直接相关，这种过程方法要求用户及早看到一个产品并试用之。通过用户对产品原型的体验与确认来固化用户需求，这个是应对用户需求变化的有效手段。RAD过程方法在过去二十多年的时间里取得了不俗的成绩

本文为《程序员修炼之道：从小工到专家（评注版）》一书的序。http://product.dangdang.com/product.aspx?product_id=22531373该书的这一版次是英文版原版（带原版页码），由学镛（在这里在这里）与我合写的点评，点评是中文。我主要评点内容细节，也就是各章内插入的只言片语，以及后来补写的第七、八两章的全章点评。以前做过《大道至

VCL已死，RAD已死 ——SD2C中未能尽言的话题  这个插播，是Shaofei Cheng在MSN跟我的一段聊天记录。关于这个话题，我在会后休息的时候，与很多朋友都谈到过，但限于现场，无法记录。正好Shaofei Cheng与我又一次沟通了这个，得以形成记录，也能反映一些我在“VCL已死，RAD已死”这个论题中有关架构的思想。故此公众，大家可以狂批……建议整篇文章从头读起，在这里在

VCL已死，RAD已死——SD2C中未能尽言的话题六、更远的将来（有限无责任预测）－－－－－再接下来，更为迎合这种面向领域组织团队并开发的工具便会出现。但这种工具不再期望整合各个领域的实现技术（注意我不是说“开发技术”），而是提供领域间的交付标准。或者更为直接地提供交付物。更多领域专精的公司受到关注（例如现在的macromedia），大厂商开

没想到华章已经把这篇序在china-pub上放出来了，那我也就公开了罢。不过更没想到的事情是，这本书有38位作者固然是令人称奇，而这本书(中文版)共有八篇序，大概也是出版中少有的了罢。代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)  等度的流明        ——代码之美·序一~~~~~~我上一次印象深刻的美的体验，大概已

VCL已死，RAD已死        ——SD2C中未能尽言的话题今年的SD2C，我匆匆去又匆匆还，因为有急事要处理，所以第三天的课程都没来得及参加。与此相同的是，我的那场话题，也讲得匆匆忙忙，有许多不清楚透彻的地方。其中之一便是这两个断言：“VCL已死，RAD已死”。所以今次开贴重讲！一、从UI的变革到系统的复杂性－－－－－UI怎么构成？在Window

这篇专访是ZDNET的李宁编辑在2007.03月期间做的。[编者语]最近在网上读到了“杀不死的人狼——我读《人月神话》”系列文章。是周爱民关于《人月神化》的读书心得。《人月神化》在软件工程里一本很有分量的书，讲述了Brooks博士在IBM公司 System/360家族和OS/360中的项目管理经验。周爱民在他的这一系列文章中用自己架构师经历为基础，从他的视角重新品读了这本书。而这也使我

VCL已死，RAD已死        ——SD2C中未能尽言的话题五、后RAD时代：领域的成熟－－－－－从界面可视，到界面可描述的变化，使UI设计渐已成为一个相对独立领域。UI团队与UED团队之间并没有严格的、学术性区别，在不同的公司中它们的定义并不一样。一般而言，我们称前者为参与UI的全体，而UED则更关注于用户体验的这一部分。有些时候，我

VCL已死，RAD已死 ——SD2C中未能尽言的话题二、分层，真的改变了你的思想了吗？－－－－－分层思想提出来了——这在操作系统的设计上可以上溯到上个世纪50年代，但在应用软件开发上却并不太久。一个比较稳定的分层系统是“交互、业务和数据”三层，当然，与实际需要相关的还有更多层、更多更多层。分层没有什么不好。正如我说WIMP没有什么不好

VCL已死，RAD已死        ——SD2C中未能尽言的话题 三、RAD之死与系统的复杂性－－－－－RAD在较小规模应用的开发上，具有相当的优势。同时，它具有两方面特性：1、对于应付在各个模向分层上需求相对均势，并且在开发工具商提供的方案可应付的区间内的需求中，RAD以及使用RAD开发的团队具有极大的能量。例如早期的C/S模式下的数据库应用。

我曾经去给OSCHINA做过一期有关“软件工程实践”的有奖高手问答 （奖是给提问者的，哈哈），现在来看，许多问题仍然可读之处，因此整理成文字，以为众赏。原贴在这里：http://www.oschina.net/question/12_78459本篇的问题是：什么是架构？以及什么是架构师？答：几位读者​都提到了架构的问题，但架构话题并没有在《大道至简》这本书里讨论过，而在另一

我曾经去给OSCHINA做过一期有关“软件工程实践”的有奖高手问答 （奖是给提问者的，哈哈），现在来看，许多问题仍然可读之处，因此整理成文字，以为众赏。原贴在这里：http://www.oschina.net/question/12_78459本篇的问题有两个：架构是否就是把问题域理清楚？软件工程各要素可有比重？问：一、关于架构。我认为架构就是把问题域的方方面面理清楚咯，设

MPD（软件工作坊，在这里在这里）中我的内容是“架构的过程“。架构是一个过程而非结果，是我的主要观点。本主题讨论两种不同视角下的架构过程与具体方法。将在实践环境中与大家完成一个系统的分析，评价与构建。并尝试性地讨论“架构过程论”的局限性。下面是此次分享中的完整PPT，与大会中用到的略有区别。其中，还有程文宇先生的一份《系统架构方法》，可供参考。下载位于：http://cid-f9303c43d5c

目录目录传说的开始看到winter的代码我的第一反应是全无promise的精髓其实我了解Promise也是新近的事情我与Promise后来发生的故事红绿灯大战的亲历实录Promise写出来怎么会是这个样子欢迎回到火星感谢米粽粽同学提到我的一篇旧文第一步的抽象一点说明前提重新定义问题Promise的编程基础之逻辑过程如何确认一个数据就绪然后then只能处理一个数据最后任何

有这样的一个世界在持续地向前推进着，这个世界充满着无穷多个选择，也就是说有无穷多的可能；但对每一个选择来说，存在决定/未决两种状态，如果已经决定，则只能有yes/no两种结果之一。那么，这个世界是确定的么？

这大概是我最后一次讲过的“软件设计”话题了，包括音频和PPT。需要的同学请自行下载。Chapter1~3，下载Chapter 1介绍： http://blog.youkuaiyun.com/aimingoo/article/details/2735597 下载(Part1~2)： http://download.youkuaiyun.com/source/562755 http://download.csdn.n

没有可讲的，我就不讲；多言误事，胡言误人，这是我一直以来的态度。

淘宝的懒懒交流会在三月间组织了一次分享，这个懒懒交流会其实就是著名的D2的前身，只不过懒懒是在公司/集团内部开展的，大概两周一次。三月份的这一期，组织了淘宝跟支付宝的两支团队，我做了《前端，架构、框架与库》的Topic。事前已经讲过：主要讲架构的思想，跟大家开拓一下思路，而非实作。视频在这里：http://v.youku.com/v_playlist/f4262628o1p0.html 这一讲的反

wwe: ...wwe: 我这几年的大部分工作也是偏重架构设计 Aim: 有什么感想呢？ wwe: 个人觉得架构设计就像生活中的一部分 Aim: EN..这个怎么讲？ wwe: 架构设计就像规划你的生活一样，都想把它变好、变美 Aim: 但是，你也应该知道。会有很多人、很多因素让生活变得不美好。 wwe: 当然 wwe: 但有一个美好的愿景是很重要的 Aim: 规划就如同畅想，你甚至可以认为：床与

  今天去优快云做了一档节目（细节保留……呵呵），这勾起了我对在盛大工作的回忆。曾经，我在盛大做过一次内训，是关于设计师的实战的，这次内训大概是在2007年5月间。时间过去了一年多，如今我来看这些内容，仍然有许多可圈点之处。所以这里就把它公开出来，与大家分享，也欢迎批评。这次内训讲了三讲，但非常遗憾的是，第一讲没有录完——中间的时候，我的手机内存被耗空了。这一讲一共讨论了“事务系统”中的

 这是“设计师的实战过程”内部培训的第二节。第一节的信息在这里：http://blog.youkuaiyun.com/aimingoo/archive/2008/07/30/2735597.aspx 在这一节里，我回顾了我在初入盛大时所做的一套数据架构。这套架构设计和实施约是在2005.10月，包括了完整的分析、设计，以及组织项目实施、交付的全部过程。这次培训录音以分析、设计为主，并讲述了项目过程

这是“设计师的实战过程”内部培训的第三节。第一、二节的信息在这里：http://blog.youkuaiyun.com/aimingoo/archive/2008/07/30/2735597.aspxhttp://blog.youkuaiyun.com/aimingoo/archive/2008/08/01/2754675.aspx 这一节是这套培训的主体，也是源起。事实上最初的话题正是从“接口、分层设计

思考才是进步本质——近期文章回顾到底是什么让我在进步？这个话题很久以前我就拟过，却一直没有作答。我总是把这样的一些问题拟给自己，这个过程，在我看来就叫反思。我不停地反思，反思这个过程本身，反思“反思这个过程”本身，如此递归往复下去。如同李维先生说的，思考才是进步本质，我找到了不停催促自己前行的动力。自去年来，我有些文章是发在BLOG之外的，因为受了人家所托的缘故，所以不是太方便在自己的

这篇文章发表于《程序员》2008.04期。其中有关模型图参见：http://blog.youkuaiyun.com/aimingoo/archive/2007/06/26/1667508.aspx有关该模型的另一个讨论参见http://blog.youkuaiyun.com/aimingoo/archive/2007/07/09/1683128.aspx做人、做事，做架构师——架构师能力模型解析  

这两天在上海参加erlang的大会，来不及写第五小节，先回复一些评论吧。其中最主要的是nanyu的一组评论，大概有三、四篇，写到了不少东西。下面一一道来。 有关评论请参见：http://blog.youkuaiyun.com/aimingoo/archive/2008/12/17/3540112.aspx  如果我没理解错，你说的似乎是 RAD已死，而取而代之的是WEB UI.－－

在博客里写了《一个程序员的迷离人生》，便总有人说我太娇情：要是那周爱民都迷茫无知了，不知道别个又该如何活下去。这样的话题，原本我是不放在心上的，也没想着要去回复。后面再写《感受支付宝》，大概这种“迷离”是看不到了，却又没几个朋友看明白我在写什么。 算了，不管这些吧。我原本没打算再谈这些话题的，于是缩了身形儿，准备“掩了柴门”消停一段时间。但是又有朋友在MSN上找我说：爱民爱民，快去看看呀，

http://blog.youkuaiyun.com/aimingoo/archive/2009/09/08/4532496.aspx（书接上回，继续！）  五、这个DSL框架有什么问题？=============有什么问题吗？有一点，并不严重。比如说，我们在Env中声明了一些属性和方法。对于Env这个对象Env = { max: 100, min: -3, calc

导言============在支付宝有一个奇怪的组织叫pCLUB，是一群programmer讨论问题的公共博客（没有对外开放哈）。最近呢，孔宣同学发起一个话题，提出要为种种脚本语言“平反”。他提到说：========我发现，现在脚本语言也深受第一印象所苦。一谈到脚本语言，人们作何反应？「运行速度很慢」「只能写一些玩具小程序」「没什么好用的IDE」「调试很困难」=

【源起】琉璃要我推荐一下给工程师们的各阶段的书单，这件事被我压在手边好些天了已经。然后呢就看见了公司内网中孙坚的一份推荐。其实那份书单的一些信息也是有出处的(或者说有类似介绍的地方)，是江南白衣的另一份架构师书单，目前已经“翻新”到2009年版和第3版了：http://calvin.javaeye.com/blog/351007http://calvin.javaeye.com/blo

本文从第2小节，至第6小节，仅供对架构、框架、库等方面有兴趣的同学学习研究，有志于在语言设计、架构抽象等，或基础项目中使用相关技术的，欢迎探讨，切勿滥用于一般应用项目。

舍弃“继承”这种方式不谈，系统构建还有其它的什么方法吗？

第一等级的优化，70字节！

JavaScript中的原子(Atom)是QoBean中提出的一个重要概念，借鉴自erlang，但具有与后者不同的含义。在QoBean里，Meta（元）与Atom（原子）是一对概念，前者表明执行系统中的最小单位，后者表明数据系统中的最小单位。QoBean约定这两个东西为一切元编程的初始，即最小化的执行系统与数据系统模型。有什么意义呢？没什么意义。这只具备理论上的完整性。为了描述这种完整性，Qo...

接下来谈谈《我的架构思想》。上一篇是“电子书《程序原本》小述”，在这里：http://blog.youkuaiyun.com/aimingoo/article/details/75506782。 本电子书可自由下载和传播。这些年来我所谈的“架构思想”在2007年，我还在盛大的时候曾做过一次名为《设计师的实战过程》的内部分享，这个分享现今在优快云还能下载到（在这里）。但在此之后，我便再也没有讲过“设