Top
首页 > 老文章 > 正文

软件架构师之架构能力模型

软件架构师之架构能力模型
发布时间:2009-09-16 09:51        来源:        作者:高阳
如果说架构师是在模型图纸上工作的,那么构建的模型元素必须是实实在在的,正如我们不可能期望抽象派画家来设计高楼大厦,没有实际意义的模型元素是不可能构筑出软件系统的。迄今为止,绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的,这二者直接的鸿沟显而易见。所以,软件公司的头等大事,就是找到第一流的人才。不同于其他行业,软件是一种纯智力产品,你有什么样的程序员,就有什么样的软件,这关系到软件公司的生死存亡。 锐哥看到小蔡在电脑桌前奋笔疾书,于是走过去问到:“小蔡,你在写什么?”“公司派来个软件架构师,我在学习UML与设计模式呢!正试图把您告诉我的东西整理出来做一个存档,以便以后温习。”“我看看。”小蔡把纸递给锐哥,没想到锐哥把纸揉了个团扔进废纸篓里,说:“设计模式,是思想对思想的,写下来的字和画出来的图只有一个功能,就是帮助你忘记。”小蔡很不解:“那您要我怎么做呢?”“照着做,直接从思想到行动。” 小蔡:“如果不需要文字和图形化东西,为什么还会有那么多经典来记述设计模式?”“那些只是砖头。”“砖头?”“是的。我们现在在哪里?”“房间里呀!”“房间是拿什么垒的?”“砖头。”“所以,没有砖头不可能有房子,对吗?”“对!”“但我们要房子,是要它的空间,确切地说,是由砖头围出来的这个空间,对吗?”“对!”“所以,我们要的东西在砖头之外,不在砖头之内!砖头只能形成墙的空间,而这个空间是不能住人的。”“好有禅意啊~我好像懂一点了……”锐哥:“书也是一样,功夫下在书里,而真正的东西却在书之外。如果你只是迷恋那些书里的文字,就好像把自己砌在墙里一样……” 锐哥又指了指纸篓,接着说:“思想上的东西要用行动去强化、固化,正所谓知行合一,一切大道理和大思想与禅都是一样的,不立文字,就好比设计模式,很多程序员在看,挂在嘴边上去说,一写到代码,要么不用,要么滥用,要么错用……都是因为没有悟出这一点来。” 时间:第2年 4月12日 9点 星期六 地点:锐哥家客厅 人物:锐哥、小蔡、大熊 锐哥:“今儿是周末,昨天公司刚发了两张音乐会的门票,你和小丫晚上一起去听听吧!我还有其他事情就不去了。” 小蔡:“这太好了,非常感谢锐哥。这么看来我得先感受一下交响乐,别到时候让小丫认为我没有音乐细胞或者太俗气什么的。我最喜欢贝多芬的交响曲了。”小蔡边说着边在电脑上放起贝多芬“命运”交响曲,随着音乐起伏小蔡开始自我陶醉起来。 锐哥:“不错,贝多芬的交响乐我也比较喜欢,较之海顿和莫扎特的交响乐,形式更加严谨、内容更加丰富、技法更加娴熟。而尤为使人关注的是,他的交响乐思想性深刻、哲理性复杂,他是第一位使交响乐具有了社会启示性和斗争性的深刻内涵。” 小蔡:“没想到,锐哥对交响乐还有些研究!我就只知道好听,感觉贝多芬的交响曲很震撼!锐哥帮我充充电,晚上好跟小丫‘掰扯’一下。” 锐哥笑道:“我在大学的时候参加过校队,练过萨克斯、小号和圆号,所以对管弦乐也有些了解。另外,贝多芬的交响乐在形式结构上,扩大并完善了交响乐的组织框架――奏鸣曲式。同时,以动力更强的谐谑曲取代了过于温和的传统小步舞曲,从而赋予交响乐以更加丰富的有机性。在音调创作方面,给后来的交响乐创作也给予极大的影响。比如你熟悉的第五(命运),是迄今为止最为简短的主题,它只有四个音,而这四个音始终贯穿着四个乐章。另外,他完善和扩大了乐队编制。在他的交响曲当中,我们发现他运用了海顿和莫扎特时期不曾运用的乐器,比如说短笛、低音大管、长号,以及一些打击乐器如三角铁、大镲、大鼓等。更重要的是在他的第九交响曲中引用了人声。面对贝多芬交响曲,让我们感受最强烈的是贝多芬精神。” 小蔡:“嗯~我记得贝多芬的座右铭是‘通过苦难,走向欢乐;通过斗争,走向胜利。’他的音乐是面向全人类的,在现代这个时代仍然需要这种刚毅、英勇、勇往直前和百折不挠的贝多芬精神。” 锐哥:“是的。法国大文豪罗曼•罗兰曾说过:‘艺术中没有进步的概念,因为不管我们回头看多远,都会发现前人已经达到了完美的境界……假如有人认为几个世纪的努力已经使我们进一步接近完美,那将是荒谬可笑的……’前几天你不是问过我软件有什么最佳开发方法和怎样才能做一名合格的架构师吗?交响乐演奏即是最佳的开发方法,它会给你更多的启迪!” 小蔡:“咦~,这个与软件开发有什么关系?” 锐哥笑道:“交响乐演奏与最佳软件开发方法有一定的相似之处。打个比方,交响乐队与软件开发团队在本质上都是成员各尽其职,无论在技术和人员素质上都需要很高的协调统一性,如果哪一位演奏师吹错了音,整个乐曲就变得很失败(如图5.5所示),演奏团队成员同辉煌的意识在里面。再把乐器比喻成UML(统一建模语言),乐谱比喻成MSF、RUP等统一过程,想一想如何才能指挥乐队团结一致地演奏乐曲?怎样才能使团队顺利地完成项目,成功地提交软件产品上线?乐队指挥尤为重要!” 小蔡想了一会儿说:“哈哈~,这种比喻很有内涵和创意!搞明白它们之间的对应关系,就有掌控全局思想能力,离架构师的距离就近了一步。” 这时,大熊从外面冲了进来,差点栽了个大跟头。小蔡大乐道:“好久不见了大熊兄弟,一进门就这么着急磕头拜师啊!” 大熊:“说什么呢,小蔡瓜!北京小区里养狗的人太多,刚进小区就被几只狗盯上了,我跑啊跑的,它们追啊追的,总算狗被甩掉了,要是被狗咬一口就麻烦了!对了,你们在讨论什么呢?”锐哥给大熊倒了杯水,让他坐下先休息一会儿。 小蔡:“我们在讨论怎样才能做一名合格的架构师!记得锐哥曾经说过,要不断抽象已知的东西。现实生活总是包括很多零散的东西,待解决的问题不会只有一面,所以学会抽取零散东西的共同属性,聚合不同角度的面向对象,成为从问题进入编程领域的第一步。”
图5.5 UML+(MSF、RUP…)=最佳软件开发方法
锐哥:“是的,抽象的层次越高,你的架构设计就会越简单。当面对未知的东西时,用已有的抽象经验来模拟体验,从而不断调整,直至达到可以控制未知东西的程度。有了上面第一点的基础,才可能到达第二步境界。就好比我刚才给你说的演奏交响乐(同辉煌意识)的例子,抽象模拟体验来熟悉软件架构的设计以及管理基于团队开发过程,从成员娴熟的演奏技巧、每个成员的职责,再到团队的协作、组织的方法、意识的一致性、团队的协作分工(团队文化)……现实问题总是不断变化着地推陈出新,从未知→半知→已知,是人认识客观世界的一个过程,恰如人生从天真到懵懂到成熟的过程。” 大熊:“锐哥的思想太博大高深,说得太抽象了!如我这般入行不久的小程序员怎能领会?我不得已还是把锐哥先从山巅拉到山脚!不如您告诉我们一个起步阶段的程序员应该怎么慢慢通过实践来逐步达到这种境界吧。” 锐哥哈哈大笑道:“很简单!起步阶段就是专心模仿。切记不要被那些新技术晃花了眼,新技术只要了解就行,所以你不必要特别花精力去关心这些东西。比如说,你在公司上班时,有时会有这样一个矛盾,当你完成公司交待的一个任务时,你可能为了尽快完成任务用了很多别人现成的框架。这本身没问题,但何谓专心的模仿?就是说你在工作之余,需要来研究这些框架,可以不用这些框架,而是用最原始的方式来写,你会慢慢体会到框架的约束,进而有对框架进行改进的欲望。但是最终你也会发现:其实任何一个框架都比你自己写的要好。然而在你不断模仿的同时你就得到不断的提高。” 小蔡:“那么,所谓高手和低手,在起步阶段有什么差异呢?” 锐哥:“其实所谓高手,就是说他在模仿的过程中不断比较自己写的东西和框架本身的差异,不断发现问题,想尽办法解决问题,思考得越多,你碰到的问题就会越多,这是一个正向循环,最终你的技术能力就会螺旋式地上升;而低手只会被动地等待问题,一旦问题自己觉得解决得差不多就放下了,这样自然就不会产生更多的问题,最终技术能力就始终停留在那个菜鸟阶段。” 小蔡:“我明白了,这种方法非常好,回头我得试试。哈哈~我想您提到的框架一定是指在‘砖头’之外的房子喽!砖头(设计模式)→房子(框架)→空间(软件)。那么设计模式、架构和框架之间的关系是什么?现在流行的都有哪些.NET开源框架呢?” 锐哥:“框架可分为白盒(White-Box)与黑盒(Black-Box)两种框架。基于继承的框架被称为白盒框架,它是一个程序骨架,而用户衍生出的子类是这个骨架上的附属品。而黑盒框架是基于对象构件组装的框架,用户只需了解构件的外部接口,无须了解内部的具体实现。在理想情况下,任何所需的功能都可通过组装已有的构件得到,事实上可获得的构件远远不能满足需求,有时通过继承获得新的构件比利用已有构件组装新构件更容易,因此白盒和黑盒将同时应用于系统的开发中。不过白盒框架趋向于向黑盒框架发展,黑盒框架也是系统开发希望达到的理想目标。 “框架更是对问题域的高度抽象,它是一个应用程序的半成品。框架提供了可在应用程序员之间共享的可复用的公共结构。开发者把框架融入他们自己的应用程序,并加以扩展,以满足他们特定的需要。框架的最大好处就是重用。面向对象系统获得最大复用的方式就是框架,一个大的应用系统往往可能由多层互相协作的框架组成。架构通常是代码重用,而设计模式是设计重用(可让代码更容易被他人理解,保证代码的可靠性),框架则介于两者之间,部分代码重用,部分设计重用,有时分析重用。 “目前比较流行的框架有Nhibernate、Sping.Net、Cslas.Net(解决了跨WCF问题)、IBatisNet、Nhibernate等,使用的时候经常是组合框架(IBatisNet+Castle、Nhibernate+Sping.Net等),微软MVC架构和微软MVP架构(Web Service Software Factory(会用到微软Enterprise Library企业库)、Web Client Software Factory、Smart Client Software Factory(适用Winform)和Prism(适用WPF框架)),每一种框架都有它的优缺点和适用场合(例如Nhibernate适用于中小型要求性能不高的项目;IBatisNet+Castle使开发人员不会把精力浪费到数据访问、事务处理主键生成等地方,可以集中精力进行业务组件的编写。IBatisNet只需要致力于完成持久层的SQL―Object映射工作,其他由Castle来装配),必须熟悉它并根据项目自身的需要来进行选择,因为没有万能的框架,所以没有万能的应用。 “一个合格的软件架构师在技术上会根据不同项目需求与环境来进行不同的设计:熟读各种框架→熟练掌握→浑成一体(活学活用)→‘忘’掉所有开源框架,达到随心所欲境界(道),可根据不同项目来创造适合的框架。” 大熊:“非常不错,锐哥又给我们指出了学习架构和应用框架的方向。那么我们首先该学习哪种框架比较合适呢?” 锐哥思索片刻笑道:“关键是据自己的技术因素而定。一般来说编程之初学习PetShop框架比较好。PetShop是微软基于.NET开发的一款在线的宠物购物系统,Microsoft用它来展示.NET企业系统开发的能力。PetShop目前最新版本基于.NET 2.0的PetShop 4.0,是一个小型的项目,系统架构与代码都比较简单,却也凸现了许多颇有价值的设计与开发理念,整个设计非常成熟而优雅(如图5.6所示),大量使用抽象和接口技术,非常便于初学者学习。
图5.6 PetShop业务逻辑层
“PetShop框架中使用了Factory模式、Strategy模式、Facade模式等设计模式。另外,从中也能学习到面向方面的编程(AOP),熟悉控制反转(IoC = Inversion of Control)或者依赖注入(DI= Dependency Injection)技术,即组件之间的依赖关系由容器在运行期决定,形象地说,即由容器动态地将某种依赖关系注入到组件之中。可以关注学习微软的Unity Application Block依赖注入容器。所以,学好PetShop框架会对程序员技术架构能力提高有很好的促进作用。” 小蔡:“非常不错,新手使用PetShop框架确实非常实用。那么软件架构师具备什么能力才算是合格的呢?” 锐哥:“架构思想关注系统的分割与交互,是一系列有层次设计决策的集合。目前国内绝大多数软件公司不重视架构设计,往往由于项目周期短和开发团队整体素质不高,经常是项目经理担当架构设计职责,即使有架构师也只不过是从形式上会使用几种开源架构,摇身一变就成为架构师,在国内架构师职责成了纯技术范畴。 “架构师不是简单地画一些UML图丢给团队那么简单,还需要很强的架构推进、风险掌控和团队沟通与平衡能力。所以,软件架构师也有层次之分。在大型的或者国际化标准的项目中,综合能力真正精湛的架构师就变得尤为重要,架构不是一件纯粹表现技术能力的工作。 “在技术和专业能力中抽象能力(如图5.7所示)非常重要。架构师面对的系统在许多细节上并不见得能够用成熟的语汇去描述,因此必须自己构建一个抽象系统,这就需要很强的概念抽象能力(基于概念逻辑表达力)。它是一种思维能力,就是把目标分解或者概括清楚,它是什么?包括什么?通常用的方法是‘映射系统’。例如,我们可以用‘设计模式名称’来映射‘代码结构域’,能够让团队用更少的词汇做更充分的沟通,大大降低沟通成本,提高团队技术能力。 “当团队讨论软件系统,可以让你保持在设计层次,不会被压低到对象与类这种琐碎的事情上面。对于设计模式有深入了解的团队,彼此之间对于设计的看法不容易产生误解,可以帮你的开发团队快速充电,使初级开发人员迅速成长。将目标系统形式化为一个概念化的、可讨论的结构系统后,你的抽象过程就基本结束。这个‘抽象系统’必须从架构师的思维意识中,灌输到团队项目成员意识中去。 “你只能把UML当做一种辅助表达工具去使用,它本身不能帮助思考。好的架构师都有自己独特的思考方式进行抽象系统。 “在团队关系掌控能力方面,架构师必须具有项目技术推动能力。架构师是从全局→局部;实施是从局部→全局,这也是‘设计做大,实施做小’的含义。增强推动能力比较好的方法就是参与全程实施,尤其是在架构被映射为目标系统的前期。在这个阶段中,架构师的任务就是推动架构实施,以保证在项目全程的设计、架构、体系上的一致性。除了直接跟设计师或设计团队沟通,这些都需要很强的沟通能力,以保证他们的设计在可控范围之内。此外,架构师还必须有阶段化设计的能力。”
图5.7 架构师能力架构模型
小蔡:“我们是否能够这样理解:架构师的能力模型由两部分组成:一部分是有形的技术和专业能力,另一部分则是无形的软技能(如团队关系掌控能力)。在架构师能力模型中,有形的那部分东西(软件实现的技巧,设计模式的运用,软件设计的能力等)是时机成熟以后自然会得到的。这个时候,我们就说某个人在技能上已经可以做架构师了。” 锐哥:“小蔡总结得不错。我们再从全局角度看,在架构师能力模型中还有一部分软技能。比如说,作为架构师,是不是能够结合市场来考虑技术方案的实现难度和成本?是不是能对整个团队资源的配备建立起一个清晰的认识?是不是对公司决策层的想法有一个清晰的把握和认识?是不是对团队中人员能力水平有清晰的把握和了解?设计架构问题的根本,并不在于是否完美或漂亮,而在于是否合用……而恰恰是这部分东西,决定了一个架构师是否合格。具备了这些无形的软能力之后,才能在具体的架构设计工作中更有效地应用你积累起来的技术能力,而不会让那些技能成为别人。” 小蔡:“OK,我已经明白了。另外我们学习架构还需要注意些什么呢?” 锐哥:“模式不是被发明,而是被发现的。在这里需要注意的是模式之间的关系和(3个)层次:架构模式(Architectural Pattern)→设计模式(Design Pattern)→实现模式(Implementation Pattern)。架构模式是模式中的最高层次,我们熟知的MVC、MVP结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式的联合使用。 “设计模式是模式中的第二层次,用来处理程序设计中反复出现的问题。实现模式是最低也是最具体的层次,处理具体到编程语言的问题。比如,类名、变量名、函数名的命名规则、异常处理的规则等等。根据《Pattern Almanac》一书,我们已知的架构模式有七十多种。这是一个只多不少的统计,其中包括了很多通常认为是设计模式的模式,比如Bridge,Facade,Interpreter,Mediator等模式,但是在许多情况下,也可以作为架构模式出现,因此也常常被当做架构模式。” 小蔡:“锐哥总结得太棒了,让我们眼界大开,并且知道有力气该往哪儿使。咦~大熊,你咋一点反应都没有呢,在琢磨什么呢?”小蔡听着兴奋之余,朝着大熊肩头拍了一下。 大熊在思索中清醒过来说:“小菜瓜,别动手动脚的!我正在琢磨锐哥说的‘交响乐演奏模型’呢,感觉锐哥列举的例子真是与‘团队软件开发模型’很像啊!” 小蔡大乐说:“倒~大熊,你反应真够迟钝。我给你讲一个笑话如何?看你想得蛮辛苦的。” 大熊大乐:“好哇!讲来听听,能逗笑我的笑话可不多啊。” 小蔡:“从前,有条装满动物的船在海上遇险,需要丢些动物下去以减轻重量。猴子提议:抓阄,抓到谁丢谁。大家都同意了。但猴子心想自己也有可能抓到呵,还好自己是个讲笑话的高手,于是又提议:抓到的还有一次机会,就是给大家讲个笑话,如果把大家都逗笑了,就可免一死。大家也同意了。谁知猴子运气实在不好,一上来就抓中了。 于是他给大家讲了个最拿手的笑话,把大家笑得东倒西歪的,唯独猪在一旁冷冷的,一点也没有笑。猴子便被惨无猴道地丢下了水。第二个抓中的是兔子,她也讲了个很逗的笑话,大家也笑惨了,可是很奇怪,还是只有猪在一边一点儿也没被逗笑。兔子也被丢下了水。第三个抓中的是羊。羊清了清嗓子,刚要开讲,忽听猪在一旁哈哈地狂笑了起来。羊很生气,骂道:老子还没开讲呢,你笑个P呀!!只听猪笑得上气不接下气地说:我刚刚仔细回味了一下猴子的笑话,还真是TMD好好笑哩……” 大熊大怒:“你个小菜瓜,嘴真够损的,变着法地骂我是猪!我想那问题是有原因的。因为我们公司的老人都快走光了,老板说我工作认真踏实,开发技术好,并且与同事关系也不错,任命我为项目经理,下周一就上任了,所以我在琢磨怎样管理团队。” 小蔡:“狂晕~你才上一年多点班,就担任项目经理?你们老板脑袋被门挤了吧?” 大熊:“我也没办法,实在是赶鸭子上架。公司企业文化不好,总留不住人,老程序员都快走光了!真像锐哥以前说的那样,小公司锻炼人,机会多。我还得向锐哥请教,因为团队成员开发能力普遍很弱,用什么更高效的方法快速地制定出适合团队作战的软件开发框架?” 锐哥略加思索说:“真难为你了,国内确实存在这种普遍现象,往往有很多非常年轻并且没几年经验的程序员担任项目经理,拿着吓人的薪水,做着吓人的项目,结果也是非常吓人的结局收场。我想你们的项目不会太大,人数也不会太多,否则老板不会轻易地交给你。为了避免风险你可以先学习熟练使用CodeSmith(如图5.8所示),里面有CSLA.NET、NetTiers和NHibernate等框架可自动生成代码,项目之初建议使用PetShop框架的CodeSmith代码模板。
图5.8 CodeSmith开源框架模板
使用CodeSmith的好处是可以利用模板自动生成重复代码,生成框架(框架复用),最大限度地避免架构设计的复杂过程。还可以约束技术能力不同的程序员按照规定框架模式编写较规范的代码,即使中途有离职人员,接替人员也能够快速上手,从而大大地减轻了项目风险。” 总结 从无到有的,是架构;从表到里的,是抽象;从粗到细的,是设计。 一名合格的架构师,在架构设计的过程中,要能站得高,望得远,即所谓运筹帷幄。不能局限在技术里,还要跳出框架,学会观察自己身边的资源、环境的状态并进行思考,基于自己对这些非技术的因素的观察、思考来调整自身工作的步调。 比如说软件设计的基本原则之一就是高内聚、低耦合,但是在项目进度很残酷、市场竞争白热化的情况下,为了设计一个高聚低耦的软件架构,而丧失了市场先机,是否智慧呢? 作为一名架构师,要能够对技术以外的因素(比如市场、客户)保持一定的敏感度。概括来说,就是不能唯技术论。个人内在素养基于四个商数,业务能力是基于技术专业能力和团队关系掌控能力的。 架构的目标 可靠性(Reliable);安全性(Secure);可升级性(Scalable);可定制化(Customizable);可扩展性(Extensible);可维护性(Maintainable),其中可维护性又包括:客户体验(Customer Experience)和市场时机(Time to Market)。 提升 软件架构规划与制定个人的职业规划非常相似。例如,个人目标和现实条件,还有业界趋势。架构规划要看价值和代价,还有趋势。个人目标一定要符合您自己的价值观和性格志趣;现实条件,发挥自己的核心竞争优势或综合竞争优势,还要注意业界趋势及相关风险。 软件架构师应具备的素质技能 具有良好的计划能力 架构设计就是要在规划阶段都把后面的事情尽量把握进来,要为稳定性努力,还要为可维护性、可扩展性以及诸多的性能指标而思前想后。 具有良好的沟通及组织能力,让合适的人做合适的事情 除了技术上的考虑,还要考虑人的因素,包括人员的组织、软件过程的组织、团队的协作和沟通等。软件过程是团队协作共同构建系统的过程,沟通能力是团队间的黏合剂。对团队成员的素质判断要准确,比如哪些开发人员对哪些技术更熟悉,或者哪些开发人员容易拖进度等。只有合理地使用人力资源,让合适的人做合适的事情才能让整个软件过程更加高效。 具有抽象与分解问题的能力 这反映的是一种自下而上找出和自上而下解决问题的决策过程。对问题的抽象和分解是软件思维的基本素质,能不能有效快速准确地发现和分解问题,是软件开发人员需要首先训练的项目。 对OOAD理念有深刻的理解,懂得用图形化的工具。 时刻关注新软件设计和开发方面的发展情况。 足够的行业业务知识和商业头脑 行业业务知识的足够把握,可以给架构师更多拥抱变化的能力,可以在系统设计的时候留出一些扩展的余地,以适应可能来临的需求变化。 本章衍生阅读 曾经有位程序员问我:“为什么我学了一年的编程,却还是不知道怎么写程序呢?”我想了想问了他一个问题:“你桌子上的书是乱的吗?”他迟疑了一下不过还是回答道:“比较整齐。”我当时反问他:“你既然知道如何把书分类、规整得整整齐齐地放在书桌,那怎么没想过如何把所学的知识分类一下,归纳一下,整整齐齐地放到脑子里呢?”如果一个人学了一年的编程他的脑袋里还是晕乎乎的,不知道从哪里开始,也不知道如何做程序,那想来只有一个原因,他也把知识学了进去,就是不知道这些知识是干什么的。或者说,他不知道这些各种知识都可以用来做什么。 我把软件开发学习过程比喻为一头牛,在学校中的学习用的是第一个胃,草是吞进去的。而到了实践中,就进入了反刍过程,通过这一学习过程进入第二个胃,这时才演化成有益的营养。应当说后一个过程更重要。通过本章,我们展现了一种超俗的软件开发人员的思想境界,浓缩了程序员发展思想过程之路,并把软件开发提升到哲学高度。 我记得老子讲过:“为无为,事无事,味无味。”其意是说:以无为的态度去有所作为,以不滋事的方法去处理事物,以恬淡无味当作有味。采取顺应自然的态度,必须以平静的思想和行为对待生活,旨在阐发“无为而无不为”的道理和处世哲学。老子举过日常生活中的例子,比如车子有两个轮子,轮子中间是空的,空是“无为”。但是正因为是空的,因此可以插上车轴,然后轮子可以滚动,可以载重,可以坐人,有了车子的“有为”了。 初高级程序员、软件架构师所具备的素质(四个定律和四个商数),是构成了一个高素质软件高级人才模型的重要基本属性特征系统。程序员就好比车轮子,因为有了上面的素质特质,便有了融会贯通、浑然有成的状态,然后忘记它(忘记非真的忘记,而是合一到自身的特质中,灵魂中,那种天人合一自然道的境界),就是“无为”,因此可以随意组装成车子,有了车子就是“有为”了,就是企业的高素质人才,这也许就是程序员之道了。

(责任编辑:董建伟)

加载更多

专题访谈

合作站点
stat