观点与展望，第 8 部分: ibm 架构师为何以及如何成为了架构师

引言：杂家还是博学家？阅读“观点与展望”专栏所有文章第1 部分: 选择 soa 的原因和时机第2 部分: 如何将业务需求转转换为 it 要求？第3 部分: 什么是最有价值的 it 体系结构技能，如何学习？第4 部分: 如果刚刚开始采用 soa，最好将哪些软件作为服务实现？第5 部分: 什么是 it 管理，为什么应该对其加以注意？第6 部分: 定义最重要的 it 体系结构问题第7 部分: 当今开发人员面临的最有影响力的趋势有哪些？更多...长大后，您想干什么？虽然我已经工作了很长时间了（已经到了不愿意公开自己的工作年限的地步了），我仍然在考虑这个问题。或许您也是这样。事实上，如果您和我一样是生育高峰期出生的，您可能将不断问自己这个问题，给出各种不同的答案，直到有一天极不情愿地被推入退休队伍中为止。 本月我们将询问专家组一个类似的问题（不过我们将问的是他们的过去，而不是他们对将来的看法）：为什么您觉得 it 体系结构方面的工作适合您，为了成为架构师，您走过了什么样的路？正如您将看到的，ibm 技术带头人也经历了同样的心路历程。事实上，他们似乎都有一个共同的特点，就是始终都在积极地尝试获得新的经验和知识。或许这使得他们有些像杂家， grady booch 就使用这个词来描述自己，而这又被 merriam webster 定义为“闲人”或“不安分的人”。（此处并不是说“不诚实或没用的人”。）更可能的是，这使他们成为博学家（即 merriam webster 所说的“具有各方面知识”的人）。他们日子过得似乎都不错!对于希望成为 it 架构师的普通人，这可能会使他们望而却步。那么，究竟在 it 领域中工作的哪些人如此有创造力而同时又过得这样快乐呢？但他们每个人都是很久以前从普通人开始一步步做起的。他们并不是一下子就获得了成为 it 架构师的所有技能，他们经历了漫长而艰难的过程，并深入各种不同领域才得到了所需的技能。设计方面也是如此。其他人则是在尝试了其他角色后才选择这个职业。考虑到我们的专家组成员对新鲜事务的好奇心，我忍不住认为这可能并不是他们中的任何人的最终归宿。如果我们要讨论的是他们以后的职业生涯，我想会发现他们在将来承担起新的任务、对新的挑战发起攻击。我们都经历了很长的成长过程，但我认为他们有可能还会继续这个过程。因此，如果下次问他们这个问题也会非常有意义：“长大后，您想干什么？”让我们拭目以待吧。developerworks architecture 团队——paul dreyfus，编辑 developerworks pdreyfus@us.ibm.com回页首放下清高，亲近现实任何方面都能推动架构师的工作：客户、他的团队、体系结构、小故障和各种问题。我认为体系结构更多的是一种态度、完美地建起软件“大厦”的热情，但现实却往往使得这不那么完美。不过，追求完美的想法与现实之间的平衡会让架构师保持一定的清醒态度，因为他必须向客户交付一个正常运行且性能良好的系统。回忆：我看到自己参加会议、在白板上画图、处理一个接一个的问题。在团队的帮助下，我尝试利用过去所积累的知识在问题领域中的各种力量和约束之间求得平衡。模式？或许吧。我喜欢体会团队活力在周围流动的那种感觉——每一分钟，我都能在同事仔细描述各种情况的细枝末叶时获得启发和学到新的东西：为什么这个情况略有不同，因而必须修改模式，以处理实际情况。编写代码的日子：编写代码是孤独的探寻过程。这个探寻过程同时也是永不停止的。有时候还没有回报。找到错误，会得到表扬。如果最终的交付内容/版本中没有错误，则不会提到这些代码中的重要性和您在其中投入的精力！我喜欢编程——不过现在很少进行此类工作了，仅在学术中需要时才会做这样的工作。处理项目时，我已不再进行代码编写工作了。**，1980 年：我开始使用 basic 和 fortran 进行编程。我非常喜欢编程。转眼到了 1995 年，我开始进行 j**a?? 编程，享受接口实现和松散耦合所带来的纯粹乐趣。但应该如何设计系统结构呢？即使获得了最好的运行代码，仍然需要一个能够承受非功能需求冲击的结构。因此，您需要能够对各种相互冲突的约束进行权衡，在重复考虑当前情况的细微差异的前提下进行决策。 我比较认可“模式生成体系结构”这样的学术流派。从蓝图（一组基本模式）开始，然后根据自己的实际情况进行扩展和自定义。这就在最佳实践和现实具有特定的无名品质（qwan，quality without a name）之间获得了最佳的平衡点，这一点我非常喜欢。我喜欢自己的架构师工作。 :)回页首和杂家一起旅行 并不是我决定要做一名架构师，而是我从事的工作所涉及的内容正是我们目前所称的体系结构方面的东西。开始的时候（大部分时间，甚至到现在也是如此），我们并不进行“体系结构设计”。我们只编写程序，其中的任何体系结构都是意外出现的。我在14 岁时编写了第一个程序（使用的是 fortran，当然我对于良好的设计所知并不多，体系结构方面懂的就更少了）。上大学时（最初在 air force academy，后来在 santa barbara 的 university of california），我遇到了当时形成了深度设计的早期理念的很多人：d**id parnas、mary shaw、tony hoare、edsger dijkstra 等。刚刚二十岁出头的时候，我担任过一些相当大（甚至按照今天的标准也可以这么说）的实时分布式系统的项目工程师和项目经理的角色，为美**事航天项目提供支持。 1982 年退役后，我加入刚刚创建的 rational??，参与了 ada 项目的大量工作。我的大部分时间都奔走于美国各地，与合同客户和**协作，以帮助他们应用软件工程的最佳实践以及这个新兴的语言。 我一直是个杂家，出现在科学所指引的地方。我逐渐发现商业领域的很多组织开始邀请我帮助他们进行类似的工作，因此我开始偏离 rational 的核心业务，将我的精力投入到这个更大的领域中。也大约在这段时间，我撰写了第一篇有关面向对象的设计的论文，并开始编写我自己的第三本书（与此主题相关）——其中所有内容不过是对我通过这些项目得到的经验的总结。我还与 bjarne stroustrup 进行了合作（他是 c++ 的发明者，我们甚至还一起去参加了全国性的巡回演讲），因为我们发现他的语言设计方法和我的系统设计方法非常相似。 在那段时间里，我仍然进行编程工作：我使用 objectpascal（在 mac **上）编写了 rational rose 的原型，并采用 smalltalk（pc **上）编写了第二个更为完整的版本。d**e stevenson 和我是第一个 rational 建模产品的架构师（采用 c++ 编写；这对 rational 是一项突破，因为之前的所有产品都是使用 ada 完成的）。这些产品进入市场后，我再次承担起作为架构师和体系结构指导人的角色，为我们的一系列最大的客户服务。在此期间，我受到 philippe kruchten 的工作的很大影响；他领导进行了早期的流程设计等方面的工作，同时他还是 canadian air traffic control system 的首席架构师之一。他也参与了有关体系结构描述的 ieee 标准方面的工作。 我在尝试让人们记住，“soa”中的“a”表示“体系结构”。 ——grady booch 最近这些年，kent beck 和我组织了名为 hillside group 的模式研讨会；这个研讨会今天仍然是模式文化的重心。我是 world wide institute of software architects (ww**a) 的最早成员之一，同时也是后来成立的 american institute of software architects (a**a) 的第一批成员之一，这两个组织都致力于发展软件体系结构实践。这段时间里，随着 rational 的业务全面纳入 ibm 中，我也回到了我原来进行的体系结构方面的工作。我不仅对 it 体系结构感兴趣，而且也对软件密集型系统的每个领域的体系结构原则感兴趣。体系结构方面仍然有很多东西我们不知道——它所代表的东西、它所不能代表的东西、如何最好地表示它、体系结构级别存在何种模式等等。因此，我花费了大量的时间通过实践和研究来进行学习。在实践方面，我仍然继续担任我们客户（甚至也包括尚不是我们客户的组织）的架构师兼体系结构指导人的角色。在研究领域，我正在编写 handbook of software architecture，该书的目标是确定各种有意义的软件密集型系统的体系结构。我与 software engineering institute (sei) 的体系结构人员进行了大量的合作。同时，我也非常密切地关注着 murray cantor 在系统工程方面的进展。我在尝试帮助人们记住，“soa” 中的“a”表示“体系结构”，另外还参与了一些新兴商业和行业体系结构标准方面的工作。我仍然在进行编程工作（大部分时间都是用 j**a），但我想自己现在终于知道了如何设计我所编程的系统的体系结构。回页首度过非欧几里得恶梦当时是我学生生涯的倒数第二个学期。我在堆满研究论文、翻开的书籍和无数的潦草笔记的书桌上埋头苦读，并考虑我的**的命题。我被这个抽象的几何模型困扰着，试图说明其对计算图形的潜在影响。我成天看不同维度形状的视图、准平面和 n 维空间的抽象数学变化，都有些头大了。在此过程中，我清楚地发现自己处于这样一个十字路口：理论计算机科学（学术方向）或应用计算机科学（计算机行业从业）。我非常果断地选择了后者，毕业后加入了一家在《财富》杂志排行 10 强的银行。我在此银行中担任助理咨询师，我所属的团队负责设计广泛分布于全球范围内的信用证解决方案。我全面接触了正式软件开发生命周期方法、经过业界检验的工程原则、软件产品堆栈和大量商业银行领域的概念。有了这些经验，我大胆地来到瑞士，为多家银行提供咨询服务，指导他们解决多个领域的技术问题（如进行电子文档存档，以实现异类数据集成）。瑞士人对精工和质量方面的关注是非常有远见的，而他们对采用新兴技术的渴望让我有机会接触各种创新产品。……他们允许我对应用程序层进行分析，并能够直接研究 os 内核和基础硬件的基本细节。 ——sanjay bose 到此时，我已非常深入地了解了银行业务，并加入了一个全球性 si 的研发部门，重新回到我最擅长的领域。在这里，他们允许我对应用程序层进行分析，并能够直接研究 os 内核和基础硬件的基本细节。我对 unix svr4 进行了修改——调整引导和调度算法、优化设备驱动程序、调整事件和中断处理、对机器代码进行反向工程、研究前辈（ritchie、thompson、joy）编写的组件、使其识别 x86 和 r**c 处理器内部指令、处理后来出现的新兴微内核和实时操作系统。从中获得的经验巩固了我对解决方案和应用程序实际 如何运行的认识。随后进入 .com 时代，全世界都开始更多地接触面向对象的概念，而我也不希望被这个潮流抛在脑后。因此，我开始担任一家新成立的公司的首席工程师，该公司当时正在研发用于解决异类企业数据源的实时集成的产品。我负责设计和构建核心运行时基础设施、元数据管理和数据访问框架。这个公司真的是一个 oo 新兵训练营。我的同事（大部分都刚刚毕业）都具有完全的 oo 意识——我甚至怀疑他们将 gang-of-four 的书作为早餐！我很快便成了 oo 的信徒，对 oo 设计、模式和技术以及如何将其应用于 j**a 以及早期 j2ee 了如指掌。除了核心产品体系结构外，我还承担其他一些任务：客户销售、提供 ui 工具和人为因素方面的培训、生成安装二进制文件、排除客户部署的故障等等。 很快我开始渴望感受大公司的那种节奏，随后加入 ibm。最初我有些担心自己会迷失在蓝色巨人怀抱中，但很快发现 ibm 的运作方式就像带保护伞的 vc，充满了主人翁意识和创新。我最初是 websphere application server 产品的一名开发人员，进行的是系统管理和 e** 容器组件方面的工作。之后，我加入了 ibm research 的一个孵化项目 nextweb，为 web 服务建议和创建综合框架，包括“on-the-glass”服务。由此引出了各种临时标准，并最后定型为 oas** wsrp tc。同时，我还负责设计 websphere portal server 中的一些组件的体系结构，以将这些孵化技术投入实际应用。到此时，我掌握了 web 服务和初期 soa 的要点。我开始为 ibm 战略业务合作伙伴提供技术指导，引导他们充分利用我们的中间件投资组合，从而更好地完成他们的重要产品功能。随着 soa 技术不断成熟，我的这些服务范围开始扩展到大型 ibm 客户和相关的适配器方面——共享技术策略、指导他们进行体系结构试点项目以及将他们的问题转给我们的软件产品团队。目前，我的工作重点已经发生了进一步的变化，负责将全球客户活动中发现的关键差距和问题反映到 ibm 软件投资组合和解决方案资产中，从而帮助推动 ibm 软件部的 soa 需求策略的发展。我非常幸运，能够亲身经历 it 的诸多方面，正如前面提到的，还通过这些经历磨练了我的基本学习技能。就今天而言，如果在处理技术理念僵局或应付要命的竞选活动（是的，在 ibm 也有这样的活动）让我感觉到自己的精力不足，为了重新打起精神，我只需要从书架上取下我的**看看就能办到。回页首确定重要的技术细节我之所以认为 it 体系结构是我的正确选择，是因为这个技术领域是让我最为痴迷的领域（现在仍然如此）。这种专业性驱使我在没有任何时间期限时开展研究工作，也正是这个因素让我错过吃饭时间，因为我舍不得暂时停止阅读有关新技术的资料。我非常喜欢将很多不同的观点组合为一个具有内聚力的交付内容，尝试将似乎不相关的东西形成一个更为相关的解决方案。体系结构强调确定很多不同技术细节的挑战，这包括对项目的成败非常关键的细节，也包括对满足涉众的需求有直接影响的细节。 在我职业生涯之初，担任的是开发人员的工作，工作重点在较大的软件工程中非常具体的元素；这通常意味着主要在实现阶段参与相关工作，而在体系结构设计期间却涉及的不多。我当时所进行的设计工作主要是“小型”设计，通常属于一个应用程序中的工作。随着我职业生涯的发展，我越来越认识到，即使通过非常娴熟的技能创建了软件构建块，但如果基本理解和体系结构不正确，项目成功的几率也将大打折扣。因此我开始主动寻找能让我更多参与此类活动的项目。这让我倾向于喜欢发现解决方案的总体概貌。一段时间后，我开始在项目进行期间担任架构师的角色。以后的故事您都知道啦 :) 回页首从fortran 开始我倒是希望自己对职业生涯以及整个人生都有所计划，但我必须承认并非如此。我女朋友和我曾就自由意志进行过讨论。她认为存在自由。而我认为我们是非常非常复杂的图灵机，完全由输入信息序列定义。因此，我可能不应该来回答这个问题。不过，每个人都知道我将如何回答。我的图灵机进入了一个状态，迫使我自然而无休止地钻研任意主题。我上大学前没有见过计算机（准确地说是大二才首次看到计算机）。是的，我有些落后。实际上，我都是在那之后很久才首次看见计算机的。我在大二时见到了计算机终端。我当时学习了 fortran，才发现以下事实：我真的很喜欢编写程序。我真的很擅长编程。无论如何，我现在并不确定自己是否仍然对此很擅长。我仍然喜欢我工作的技术方面的东西：调整代码、编写小段 php、讨论一些设计选择、考虑重要的下一步工作。我定期到现场视察，花上一整天时间对项目进行检查，并与项目人员进行讨论。现场人员说，尽管会受时差的影响而且每天工作时间很长，我似乎从来不觉得累。他们想知道我是如何做到的。这样的日子是我工作中最有意思的日子，我非常喜欢。我对它们的喜爱程度超过了对咖啡的喜爱。 正是这个原因让我觉得 it 是我的正确选择。那么，我走过的路是什么样的呢？我不断地探索新问题（现在也是如此）。我所走过的路似乎是最具挑战，也是最有趣的。回页首基于广泛 it 领域实践经验的坚实基础我之所以选择 it 体系结构，有很多与 bobby 相同的原因。我最开始负责维护其他人编写的代码。我经常遇到这样的情况，我要维护的代码，除了编写者本人外，几乎没有任何人能够理解。（至少那些希望理解这些代码的人无法理解。）为了更好地了解代码所进行的各方面工作，我要重写代码，以便能够更好地了解系统如何工作。我发现（我的经理和其他更为资深的软件工程师也发现了这一点）自己能够很好地重写软件，从而更便于其他人在我之后进行维护。 随着时间的推移，我的技能不断提升，所接触的项目范围也越来越广泛，我经常发现所处理的软件存在功能重复（或功能非常相近）。我会重新设计此类冗余功能，以使其包含在应用程序内的可重用模块中，从而减少要维护的代码量，降低出现错误的潜在可能性。此时我发现自己希望在更广泛的范围内应用这些技能。我想知道我所处理的所有这些应用程序如何一起工作。我想正是在此时我决定要成为一个 it 架构师。为了最终达到我的目标，我接触了诸多 it 领域的东西，包括 qa 测试和操作。我还在一个替换 erp 系统的部署中扮演过主要角色：这项工作要求对旧 erp 系统与对其依赖的外围应用程序（或反过来）间的所有接口进行全面的检查。 所有这些经验促成了我的 it 体系结构技能的形成。我当然很同意 bobby 的观点，为了成为高效率的 it 架构师，务必通过操作、维护、测试和部署软件获得足够的经验，从而形成坚实的基础。回页首所有层次的沟通是此领域成功的关键我成为架构师所走的路可能与大多数人都不一样，因为我大学学的是数学专业，在高中和大学都编写过很多简单的计算机程序。大学毕业后，我加入了一家大型零售企业，学习使用各种技术构建商业应用程序。我掌握了很多编程语言和技术，并在后来担任过团队负责人、设计师和教师的职位。之后，我厌倦了这样的生活，决定转行，因此去上了一所法律学校。从法律学校毕业后，我惊讶地发现很多大公司（不是律师事务所）在招聘应届法律专业毕业生。在接受招聘面试的过程中，我发现，在法律学校中学习的各种技能（例如，问题确定和冲突管理）对领导能力的各个方面都非常重要（前提是必须掌握这些技能）。此外，我记得在法律学校学习的第一年，一位教授曾指出，该校的目标实际上是仅仅教会我们三件事情：如何读、如何写以及如何思考。这些是我们的主要课程。在决定不从事法律方面的工作后，我在一家咨询公司谋得了一个职位。我后来离职，并首次加入了一家小型计算机公司（当时规模小）tandem computers。我在 tandem 获得了大量的经验，让我对各个公司如何购买各种先进技术以及如何使用技术有了更全面的了解。更为重要的是，由于在 tandem 担任过不同的角色，我担任过指导咨询师、程序员、软件工程师和架构师的职责。我发现自己不仅需要进行设计和编码，还需要帮助为解决方案确定恰当的技术，还必须考虑使用模式、服务质量，而且必须同时考虑以后的需求和目前的需求。我发现好的架构师都是善良的**，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。我很喜欢这个新角色。我之所以加入 ibm，是因为我遇到了很多非常聪明的人，他们都在非常大的公司工作，与 ceo、cio 交流，影响着技术方向，并负责设计主要解决方案（其成功对高级执行人员非常重要）的体系结构。我也希望成为这样的人——现在我是了。回页首当您不再进行编码工作转而将重点放在设计和集成上，会发生什么我从事 it 工作的头五年，主要是在零售行业像打杂的一样（不过仍然被称为 dba）设计和优化数据库。当时是 20 世纪 80 年代初（是的，从我的年龄就能够猜出来），但我仍然感到惊讶的是，重构包含几百万记录的数据库之类的简单任务经常要花上 2 到 3 天时间。联机重组和关系数据库之类的东西当时还不流行！进入公司几个月后，我询问当时的上级，为什么 cpu 大部分时间都是空闲的，还运行这么慢，他给的答案是“原本就是这样的。我们只需要按照手册中的过程进行操作就行了。这就是为什么劳动节的这个周末加班的原因（译者注：美国劳动节在 9 月的第一个星期一），方便您对问题进行修复。我们每年只有一次机会对数据库进行重组（对于不熟悉数据库的读者，我解释一下重组：重组通常用于对已经填充了信息的数据库进行重新设计或重建），以便为应付圣诞节的购物高峰期做好准备。” 我升了职，我的老板告诉我，他认为我以后会成为一名好的架构师（如此之类的说法）！ ——sridhar iyengar 当时我刚刚走出学校的大门。我非常失望，发现自己所学的所有关于并行计算机科学理论并没有在那个年代的计算机系统上得到利用——至少在我所知的数据库系统上是如此。我的目标是设计一个并行版本的重组命令，从而不必在所有周末都在绿色屏幕（指绿色的单色显示器）前度过。而正是这个使我开始进行数据库设计、并行编程和多任务操作系统设计。当我将原来约两天半的重组执行时间降低为约 7 个小时后，我升了职，我的老板告诉我，他认为我以后会成为一名好的架构师（如此之类的说法）！很快，我成为了一家小咨询公司（后来被一家更大的计算机供应商收购）的数据库咨询师，开始为很多客户设计和调整数据库。接下的五年左右，我在教客户如何设计数据库和应用程序，以最有效地使用 cpu 资源。这意味着要讨论应用程序和数据库体系结构——而这使我开始接触 it 体系结构。我最初以数据库设计为核心的工作重点让我开始探索实体关系模型（一项大部分数据库设计人员仍然在使用的技术）。后来，在 80 年代末期，我开始研究语义建模（我当时认为这种技术非常不错），后来又开始研究对象建模和对象数据库。大约在这段时间，我首次接触了“元数据”和“元数据库存储库”——当时正是应用开发周期 (ad/cycle) 的年代。数年后（也就是 90 年代中期），同时发生了一系列有意义的事件，建模语言（如 uml）、元数据语言（如 meta-object facility、xml dtd 以及后来的 xml 模式）和中间件（如最初的 corba 和后来的 j2ee 、.net 及 e**）开始采用面向对象的方式，并最终发展为基于组件和面向服务的系统。从这期间的某个时段起，我的名片上开始出现“数据库架构师”、“对象架构师”、“软件架构师”、“首席架构师”之类的字样。也正是这段时间，我被推举到 object management group (omg) 的“体系结构委员会”；这是一个行业标准组织，致力于推广各种行业标准，如 common object request broker architecture (corba)、统一建模语言（unified modeling language，uml）以及后来的模型驱动的体系结构（model-driven architecture，mda）。我想人们最终认为我是个“架构师”，是因为我几年前开始不再编写代码，而开始将更多的精力放在如何使系统一起工作——工具、应用程序和数据集成的世界。现在我需要考虑的是各个“体系结构”如何一起工作，如“如何将模型驱动的体系结构和面向服务的体系结构概念一起使用”。使用开放源代码（主要是 eclipse 和 apache 项目）和开放标准（主要来自 w3c、pmg 和 oas**）基于真实客户场景设计一起工作的软件工具是这段时间我在 ibm 作为架构师所进行的工作。我还要花时间为重要客户提供协助，帮助他们定义体系结构和使用工具与中间件时的策略方向。我想我仍然是个架构师，因为我现在是 ibm 软件部体系结构委员会指导委员会 (ibm software group architecture board steering committee)、ibm eclipse 审查委员会 (ibm eclipse review board) 和 omg 体系结构委员会 (omg architecture board) 的成员。 毫无疑问，我现在意气风发，准备继续在体系结构的赛场上驰骋几年。也可以说，我现在对体系结构如醉如痴——特别与 ibm 内外这么多业内出色的架构师在一起时。 回页首做每个方面的事情尽管我的职位中有架构师 三个字，但却不从不敢对架构师这个称呼感到理所当然。相反，我对 kent beck 所写的关于极限编程 (extreme programming) 一段话更为赞同：不要强制性地要求团队成员专业化，成为分析人员、架构师、程序员、测试人员和集成人员——每个 xp 程序员每天都会参与所有这些关键活动。能够做各个方面的事情，这才是 it 的乐趣所在。可以构思一个新想法、对其进行展开、向其他人展示、获得反馈，然后对其进行改进。而且可以任何时间在任何地点做这样的事情。其他哪种职业能让您有这样自由进行创新的机会呢？因此要寻找任何能够培养所有这些技能的机会。不要不敢接触任何新技术和编写“hello world”一类的简单应用程序。始终有新东西值得学习和尝试。回页首全面理解问题我年轻的时候，经常对看起来似乎简单的东西如何工作感到疑惑。为什么我的自行车有这么多转动的部件？为什么自行车上有一个链子连到踏板上？如果将割草机的小电动机连接到自行车后面将发生什么样的情况？自行车会自己动吗？骑自行车不捏把手下坡时，最好的做法是怎样的？我并没有意识到，这正是充满吸引力的体系结构世界之旅的开始。 和很多同事一样，我并没有成为架构师的想法。但和他们一样，在我的 it 领域的成长过程中，成为架构师的路似乎是一个自然的发展过程。我的职业生涯始于 80 年代末期，最开始在 ibm aix 开发实验室工作。我当时的体系结构概念全是关于 aix 的速度/数据提供和功能。我并不理解自己作为 c 和 c++ unix 编码人员和测试人员能如何帮助客户实现和部署任务关键型应用程序。其中的很多应用程序都作为所谓的“资本主义社会”的催化剂或为其提供主要支持。离开aix 开发实验室后，我开始担任与客户协作的 it 专家，尝试实现客户机-服务器系统。我从事此工作后不久，.com 热潮开始了，而很多人称为“j**a 进化”的趋势也在这个时候出现了。换了公司后，我于 90 20210311