作者归档:tomly

成就他人

去年的业绩比较好,年底的调薪和股票激励也还不错,但是知道同组去年刚进来的同事没有股票,调薪也聊胜于无,突然就感觉有点难过。

他也是很努力的,而且刚刚买了房,经济压力很大,仅仅只是因为表现还不够突出,收获就差了好多。

选择真的很重要。毕业时的选择,让我在现在这个人生阶段就拥有了相对比较好的经济和生活条件,而别人也许跟我有同样的能力,也足够努力,但是只是因为来的晚了一点,就错过了好多。

我因为自己的选择(其实也是运气)收获了很多,所以也要把这样的运气传递给其他的人,让别人也可以一起分享,这是感恩,也是传递美好。

不只是为自己的成长,也关注团队的成长,这是我后面要更加着力的事。而现在的我,也有能力和职责,去做能成就别人的事。

成就他人。

工程师到架构师

好友在写微信公众号,上个月找我约了个稿,写一下程序员成长为架构师的话题,而我也刚好想对这么些年的工作,有一个阶段性的总结,于是有了这篇文章。

朋友公众号文章首发,地址在此。我这里就算留个底。

——————————

0、前言

架构师是一个没有被严格定义的角色。

在写这篇文章之前,我特意把这几年看过的关于架构和架构师的书重新翻了一遍,结果发现它们的定义或多或少有一些不一样,而经过了这几年,一些之前同意的观点,现在的我也不敢苟同了。另一方面,业界对于架构师这个岗位,其实也没有统一的角色定位。在阿里巴巴,前几年是有专职的“架构师”职位的,现在已经回归到“工程师”、“专家”、“研究员”这样的纯技术职位。而我面试过的人中,也有各种各样的“架构师”,很多小团队里,项目经理就经常自认为架构师。大概架构师目前还不至于称为一个职业,更多的是在项目中的一个角色,而其角色定位也是模糊的,因此,这个文章里,我主要还是从自己的理解出发,阐述一下这个角色的定位和个人发展的建议。

1、架构师的定义

架构师:任何复杂结构的设计人员。

架构师的名字来自于建筑业,Software Architect直译应该叫“软件建筑师”。从很多方面讲,软件架构师的工作跟建筑师很像,为了寻根问祖,曾经我也看了不少建筑设计的书(推荐一本《建筑的永恒之道》),最后我发现,两者一脉相承,现阶段分道扬镳,未来也许殊途同归。

一脉相承——不管是建筑师还是软件架构师,都是为了“大图”而存在,做好顶层设计,充当需求方和实施者的桥梁,是其最重要的两个职责。

分道扬镳——两者的发展阶段不同所致。建筑业实践绵延数千年,理论根基有数百年,真正成为一门学科也有一百多年,而软件架构真正出现不过二十年。建筑业已经在足够高的层面上模式化,建筑师能够真正去“设计”,也就是决定“做什么”。而软件行业还在高速发展中,各个层面的技术还在百花齐放。技术的选择意味着权衡,因此软件架构师更多还在关注“怎么做”——这也是建筑师可以称设计师,而软件架构师只能算高阶工程师的原因,设计师更关注美感,而美感在软件架构师的考虑优先级里,排不上第一。

殊途同归——计算机发展的几十年,也是技术不断往上抽象和模式化的几十年。SOA、IoT、IFTTT等技术理念已经接近于建筑行业的模块化级别,各种“智慧城市”、“生态城市”已经在架构层面上考虑“做什么”。假以时日,架构师也许能成为一个真正的纯“设计”的职业,到时候大学里也可以开设“软件架构”的专业了,那一句“建筑设计师在成为建筑设计师之前,是不会成为建筑工人或工程师的“也能在软件行业成为现实。

当然,这只是可能的未来,这需要我们这些前辈技术人员,能够和建筑行业的前辈一样,把技术规范化,设计模式化,还要有一套关于架构美学和功能设计的完整统一的约束,任重而道远。

2、架构的职责

在软件技术发展的前几十年,是没有架构师这个称谓的。所有的人都是程序员,可能有个带头的人,叫主程序员。随着计算机技术的发展,软件覆盖的领域越来越大,软件本身也越来越复杂,现在,动辄几百万行、几千万行代码的软件系统已经非常普遍。软件的复杂化,对于开发人员的脑力负担也不断增大,而人脑所能处理的信息量是有限的,于是,软件开发工具、开发方法也在不断发展,从汇编语言到高级语言,从函数到框架,从面向过程到面向对象,从设计模式到架构模式,总体而言,人类在软件开发工具的各个维度上都在做着”封装“和”抽象”,架构设计是这种抽象和封装的最高层次。从架构的维度上,已经不需要考虑语言、函数、设计模式这一类的抽象,而是站在整体软件系统的高度上,考虑系统设计的技术合理性,需求实现的完整性,商业诉求的匹配度(主要是成本和效率)——这是架构的技术职责。

另一方面,随着行业的发展,软件项目的参与角色和人员也越来越多,从起初只有程序员和需求方,发展到技术、产品、设计、商务、项目管理多团队,技术团队内部的分工也越来越细化,前端、后端、测试、运维、售前售后技术、集成技术等应运而生。架构师是技术团队面向产品设计等团队的接口人,承担着弥合技术与非技术团队之间知识和语言体系差异的职责,同时作为技术团队的带头人,要负责勾勒蓝图,明确边界,让不同技能的团队通力协作,最终完成软件系统的整体建设和发布——这是架构的组织职责;

2.1、架构的技术职责

首先,架构师经常被类比于建筑师,但是有两个建筑领域的基础理念,在软件架构领域是不成立的(至少现阶段不成立):

建筑设计师在成为建筑设计师之前,是不会成为建筑工人或工程师的。——现阶段的软件架构师,一定是从软件工程师成长起来的。

建筑学和工程学之间的区别表现在“做什么”和“怎么做”:建筑师决定做什么,工程师想出怎么做。——现阶段的软件架构师,除了决定做什么,也要决定关键部分怎么做。

架构的技术职责分为三大块:

  • 抽象设计;
  • 非功能设计;
  • 关键技术设计;

首先是抽象设计。架构师需要能自由地在不同的抽象层次和视角上分析需求,不同的架构层次/视角提供了不同的视图,这些视图互相验证,又能构成整体的设计大图。架构的抽象层次分成两个维度:

  • 垂直维度

从上到下,分成企业架构、解决方案架构、应用架构、系统架构等,这个分层的逻辑,是提供不同颗粒度的业务建模。CTO关注企业架构,它提现了一个企业整体的IT技术建设的战略选择,典型的就是集中式和SOA、大型机和云计算的选择等;产品经理和运维关注应用架构,这里映射了产品的业务流程和应用的整体部署依赖;外部客户关注解决方案架构,它定义了如何通过产品的整合和协同,解决特定客户的特定的技术方案需求;研发工程师关注系统架构,这里定义了单个系统的领域建模和系统框架。

  • 水平维度

具体到对某一个业务的架构设计,又可以区分出业务架构、数据架构、技术架构、应用架构几个不同的视角。业务架构是对业务领域和业务流程的分析抽象,需要提炼出业务的核心领域模型,业务的可变和不变部分,这是架构师和产品经理协同完成的;数据架构基于业务架构提炼的核心领域模型做数据模型和存储模型的设计;技术架构基于业务的性能,可用性,安全等非功能性指标,确定语言、框架、中间件、部署等技术选型;应用架构基于业务抽象设计应用系统的层次结构、系统边界等。

在这些架构划分中,企业架构匹配商业模式,业务架构匹配业务模式,其他几个架构的划分,更多的是从技术的不同视角来看,他们提供了从不同的抽象层次,不同的切面对于功能需求的分析和建模。

同时需要说明的是,架构的抽象是匹配于业务的,就像桥梁设计师不能直接转做摩天大楼设计,架构抽象也是区分领域的,每一个业务领域都有自己的独特性,因此在架构上也是千人千面的,好的架构设计也是对于业务抽象得最好的设计。

架构师的另一个技术职责,是对非功能需求的分析,这也是“架构服务于功能,高于功能”的含义。这里的非功能性需求包括了软件系统的可靠性、扩展性、可测性、数据一致性、安全和性能等。考虑到成本和运行环境等限制,这些非功能性需求很多时候是不能同时满足的。这个时候就需要“权衡”,空间换时间的算法层面的权衡,性能和可测性、可靠性的权衡,一些权衡甚至上升到了学术层面,变成无完美架构的理论根基(如CAP理论)。

架构师的最后一个技术职责是关键技术设计。建筑师不只是做整体外观设计的,建筑师也需要考虑关键部分的细节设计——曾经在巴塞罗那圣家堂,我甚至看到高迪连教堂里一把椅子都留下了详细的设计图纸。同理,架构师也需要对可能影响到软件系统整体质量的关键部分,做更细节的详细设计。

2.2、架构的组织职责

架构师是企业的一员,作为“边界人”,承担着在不同角色、团队之间沟通协调的作用。

  • 和业务、产品团队的协作

软件系统是解决现实世界的问题的,任何的软件系统都是业务相关的,当一个软件系统的商业模式确定之后,架构师就开始和业务、产品团队紧密合作,确定软件系统的业务架构和领域模型。业务和领域模型抽象的好坏,决定了软件产品是一次性的解决方案,还是可以持续支撑业务成长的真正的产品。

需要说明的是,业务、产品方和架构师是需求方和实施方的关系,所以,双方之间既是合作的关系,有时候也是谈判双方的关系,特别是对于外包型的软件产品而言,这个时候,架构师又承担着在业务方和技术团队之间找到诉求契合点的重任。

  • 和技术团队的协作

研发阶段,有架构师参与的项目,往往牵涉多个不同方向,不同业务领域的研发团队。架构在其中的作用,是整体大图的传导,以及应用和团队研发边界的划分,对于影响到整体的非功能需求的关键技术点,架构师也要能亲力亲为完成设计。归根结底,架构师为软件系统的整体质量负责,也为研发团队的研发分工负责。

部署阶段,架构师需要和运维团队一起评估满足整体非功能需求的前提下,软件系统部署的硬件成本和部署拓扑结构。例如对于互联网应用,针对性能要求,是否需要CDN,带宽需求;针对可靠性,是否需要多机房部署;针对安全,是否部署相关的安全软件。最终的部署策略,仍然是基于成本和需求的一个权衡。

技术团队是架构师的大本营。根据不同公司的职能定位不同,有的架构师立足于技术团队,有的游离于技术团队。立足技术团队使架构师能更深入了解团队所负责的产品,因此能对业务做更合理的建模,也有利于架构师对关键技术方案做针对性设计,但是可能会限制了架构师拥有更加全局的视角。游离于技术团队的架构师能够从全局看待软件设计而不受制于屁股,因此更能从客观合理的角度规划整体设计,但是由于对技术团队没有管理职能,对于方案的落地只能依靠个人的技术号召力,而且,游离意味着疏远,如果架构师不能自觉地去跟进软件产品的实际落地,可能慢慢就会架空,变成PPT架构师。

简言之,架构师既不能完全负责某个技术团队,也不能完全游离在技术团队之外,这个,又是一个职能定位的权衡了。

同时,架构师和技术团队的协作,还有一个很重要的组织职能。如前述,架构师既决定了整体的架构选型,也决定了关键的技术方案的设计,而什么是需要架构师亲力亲为的关键技术方案,是架构师来确定的。因此,这就引申出架构师的另一个重要的组织职能——团队培养。如果架构师完成所有的技术方案设计,研发团队只管写代码,架构师会累死,研发团队也不会成长,这就要求架构师给予研发团队足够的成长空间和信任,并因此承担一定的风险和责任,这是这个角色必须承担的。

  • 和其他角色的协作

除了产品和技术团队,架构师需要协作的还有项目经理,外部客户,甚至是公司财务……一句话,架构师作为技术方案的总负责人,对接所有对技术方案有关联关系的合作方。

  • 如何沟通

协作就需要沟通,架构需要掌握多门沟通语言,而最好的语言是图表。对于产品来说,架构师沟通的工具是业务架构,用例和领域模型;对于研发团队来说,架构师沟通的工具是应用架构,组件和时序图;对于运维团队来说,沟通的语言又成了部署架构。图表的作用是维护共同的语言,同时也是让设计文档化以便于传承。

3、架构师的成长

上面讲了架构师的职责,职责既是能力的要求。可以看到,架构师既是一个全方位的技术专家,也是一个沟通协作的专家。因此,总结一下,架构师的成长,也是两条线:

  • 技术上

架构师的首要工作是抽象建模,而首要的首要是要了解自己所处的业务领域,只有对业务足够了解,才能更好地抽象和建模,也更能沉淀通用的设计方法论。几年前,我曾经看过我司首席架构师的书单,其中有银行卡组织的介绍的,有零售银行的业务分析的,而那个时候,我司还只是金融业边上的支付公司而已。

另一方面,架构师需要在业务领域所涉及到的技术领域中,都要了解甚至精通,譬如对于互联网行业的架构师,小到语言、算法、数据库,大到网络协议,分布式系统,服务器,中间件,IDC等等都需要涉猎。一句话,架构师是技术团队的对外接口人,也应该是外部团队技术问题的终结者。广度之外也要深度,对于关键的技术模块的设计,架构师需要有技术的权威性。

  • 组织和个人成长上

架构师要作为业务和技术的桥梁,因此需要精通业务和技术的语言,要锻炼沟通能力,不只是口头的沟通能力,也包括用标准化的图表表达设计思路的能力。

架构师需要一种“中庸之道”。不管是技术的选型,团队的协作、培养和分工,商业诉求和成本、产品需求和技术诉求的匹配,很多时候都是一种权衡。可以说,架构的工作主题就是权衡,这可能也是工程师成长为架构师最大的挑战。工程师经常是完美主义的,程序也总是精准精确的,但是架构师要习惯于不完美和一定条件下的不精确。

4、补充说明

上面写了这么多,其实针对的是大型的,有明确需求的,多团队参与的项目或者产品的架构师。现实世界中并不都是这样的项目,所以也并不都是这样的角色分工。例如,对于创业团队来说,活下来是最重要的,所以创业团队崇尚的是敏捷开发,快速构建,灵活试错,37signals的《Getting Real》是这种思想的最好诠释。这样的研发体系特别适用于不需要太复杂的底层设计,功能扁平化的,可以快速开发原型,小迭代不断扩展的应用,特别是web应用和APP。

另外,架构师也不是技术人员唯一的方向,甚至不是大多数技术人员的职业方向。在技术上,架构师是广度优先兼具深度,同时在技术之外附带了许多的业务性和组织职能,而很多的技术人员会更倾向于在技术的深度上不断挖掘,也不愿意投入太多的精力在业务和沟通上,这样的技术人员其实更适合的是技术专家的路线。技术专家研究的是纯粹的技术,这里面可能有算法、有编程语言、有运行容器(虚拟机、操作系统、应用服务器、中间件)、有通讯机制,这些都有足够的源源不断的问题等着技术人员去解决,而他们解决的问题,也成为软件技术不断向上抽象,不断模式化的基础,所以,技术专家的路线也是同样重要的。

是轮回,亦是梦——看《如梦之梦》

7小时的鸿篇巨制,让人禁不住想去解读它的复杂剧情。

这是十三年前首次公演的一部话剧,却给人《盗梦空间》的感觉,而且比《盗梦》更复杂了无数倍。

看完上半场的时候,我觉得这是一个轮回的故事,因为主人公在传说可以“看见自己”的诺曼底古堡的湖边,看到了古堡的原主人伯爵;

刚看完下半场的时候,我以为这是一个梦中梦,主人公“五号病人”在妻子莫名消失之后,梦见了自己周游世界,从巴黎到诺曼底古堡,再回到中国追寻古堡的原女主人顾香莲——一个上海名妓,而名妓讲了自己的故事——旧上海的灯红酒绿,作为伯爵夫人的生活,巴黎的艺术追求——而那也是梦。顾香莲死了,第二层梦境消失,主人公死了,第一层梦境也结束了。

然后,看了剧场外买的纪念画册,看到人物时间表,再看演员感想中的只言片语,突然又觉得,这分明是一个轮回的故事啊。伯爵是存在的,顾香莲是存在的,伯爵同时受到两种悲剧命运的诅咒:休原配太太娶顾香莲;伪装火车事故抛弃顾香莲。第一个诅咒让伯爵的转世“五号病人”遭遇妻子莫名消失的命运——他的妻子是中法混血,我不能不联想她跟伯爵的原配夫人的关系;第二个诅咒则是伯爵临死前顾香莲亲口说的“我要你永远遭受比我更大的痛苦”,于是“五号”一辈子受难于莫名其妙的发烧。

但是我的逻辑还是不满足于这样的推理。这个故事中讲了太多的梦:“五号”的妻子的梦,为什么说她已经死了两年了?她的”仇人”做了什么坏事?为什么他跳楼自杀的方式跟顾香莲的恋人王德宝那么像?还有江红的梦,这分明就是一个梦中梦——在梦境中不断煮鸡蛋,惊醒,起床继续煮鸡蛋,再惊醒,再起床继续煮鸡蛋,再惊醒……如此七次,这个嵌套了七层,每层的场景都一模一样的梦,看起来如此恐怖,要是这个梦永远这样循环该是怎样?或者,我们怎么能知道,江红第七次打下鸡蛋,心情忐忑地发现自己没有突然从床上惊醒,就足以确定她已经回到现实了?

还有“五号”在巴黎为什么看到了那个穿着旗袍的女人,只有梦里才能不分时代出现各种各样的人。

还有剧中不断重复的庄生晓梦的故事,一直在迷惑着我,莫非是“五号”梦见了伯爵,或者伯爵梦见了“五号”?

复杂的剧情,让人浮想联翩的故事。期待和导演的交流,让我能够稍微看穿一些迷雾吧。

我回来了

一直以来我就觉得我的人生至少要经历一次长时间的流浪,尝尽最极端的漂泊感,不然我不会甘心安定下来。两年前看《不去会死》开始埋下环球旅行的种子,去年看了《迟到的间隔年》,这个想法开始成为计划——当然我不会一次走完全世界,但是我可以重走一次马可波罗的路。去年年底开始做准备(主要是看各种中亚西亚地区的游记和探险记录)。今年上半年经历了工作上的巨大挑战(也是巨大的压力),从结果上来说也达到了我预想的目标,再加上三年的工作合同即将到期,因此,我跟主管商量,合同到期后我想休息一段时间。开始的时候商定了休假三个月,后来变成了一个半月。时间短了,留给自己做旅行计划和办签证的时间也只有一个月,于是,马可波罗之路变成了从伊朗开始的亚欧七国之旅。

于是有了这次44天的“流浪”。

回来之后我才意识到这一路的辛苦。实际上,在旅途最后几天里,我已经开始担心裤子要掉下来了(真的是明显地越走越瘦)。对于我一路走过的这七个国家,44天的时间实在太短,而我想看的东西又太多,于是乎几乎每天都在赶路,甚至在最后的一个星期成了空中飞人——7天时间坐了6趟飞机,飞了5个城市。

有过无数次陌生人的友好相助,也有过旅途的第一天就被人放鸽子,一个人在陌生的德黑兰机场无处可去;

有过跨国渡轮到点了不开,几百人等我一个人上船的惊喜,也有提前近两个小时到机场,最后还是错过飞机,不得不在寒冷的机场睡一晚上椅子的凄凉;

挫败过无数次可能的陷阱和骗局,甚至是两个人明目张胆的抢劫,但是也被顺手牵羊偷过钱,甚至一次不注意,信用卡被偷然后当天就被刷爆;

有过和女生同处一室的浪漫,也有头枕椅子辗转难眠第二天成为行尸走肉的惨痛;

遇见过太多精彩的人,拍了一万多张照片,在古丝绸之路骑过骆驼,在土耳其坐过热气球,在爱琴海游过泳,在马拉松跑过马拉松,在意大利看过歌剧,在西班牙看过弗拉门戈,在无数的博物馆度过了无数沉醉其中的白天,也无数的街道小巷走过白天黑夜以至于双脚抽筋……

然后,收获了什么呢?

我只知道,我经历了我想要经历的多得数不清的种种,也经历了不想经历的种种。一个人的人生观和价值观是不会轻易被改变的,但如果一定要说的话,也许这一路,我最深刻的两个感悟是:

1、你永远不会别无选择;

2、坏事总会发生;

其他的,就让它们潜移默化吧。至少,这些旅途的经历,足够我在往后的数年里,心满意足地回味了。