首页 > 代码库 > ArchSummit全球架构师峰会2017年深圳站 漫谈
ArchSummit全球架构师峰会2017年深圳站 漫谈
自去年6月跳槽到某CDN厂,从偏向移动端开发又回到了专注后端,关于做一个移动应用独立开发者的计划暂时搁置,但是如马云所讲: "梦想还是要有的,万一实现了呢"。去年下半年辛苦加班加点干活,但是却乐于其中,随着团队规模扩大,现在负担小多了。不仅仅是涉及时髦的大数据技术,而是体会到了很多非纯粹编码的道,不再死守XX编程语言,毕竟产出效率为王,更何况虽然是在大公司内,但实际也可看作是创业部门,除了极个别领域,大部分是业务驱动产品开发,技术仅仅是作为落地的工具,技术随着产品演化到某个阶段也会随着变化,并非一成不变,具体到编程语言更是如此,保持开放的心态很重要,不要守着"人生苦短,我用python", 亦或"PHP是世界上最好的语言"这类;关注不仅仅聚焦在开发阶段,而是放到从需求到开发,测试,部署运营,以及中间的规范流程,需要为最终的产出负责,而非固执在沉迷在某项牛B技术,或对某个巧妙设计沾沾自喜;看起来灵活的设计似乎有助于产品有效落地,但很可能引起复杂度的增加,通过看似毫无技术含量的约定来达到目的,简单即是美嘛,我觉得是契合了Design by Contract。总之,除了技术上的成长外,其它方面也得到锻炼,可以说这次选择是自毕业以来在所待过的大小厂中收获最大的,即使曾经在BAT某厂呆过。
本来这篇文章是为了这次架构师峰会写的,忍不住先把这一年的经历,感悟一吐为快,现在来漫谈下本次峰会的自己的一些体会。
不得不吐槽下专题中的每个演讲都是45分钟,有的讲师PPT灌了太多内容,流于牛B功能的描述,而淡化了设计方面的演讲。但是自己听过的演讲中,有的确实给人耳目一新,打破自己的狭隘的观念。
千米网首席架构师曹祖鹏老师带来的<<从大厂到创业公司,架构师经历的三次转身>>印象最深刻。其中他将软件复杂度分为两种:一个是领域问题的复杂,这个是本质性复杂;另一个是称之为偶然复杂,即开发工具顺手,框架不好用,开发模式等等。很多开发人员,包括我,往往沉迷在技术,框架,工具的,即重点放在了偶然复杂上,而忽略了本质性复杂,把业务领域问题丢给了产品经理,而这个现在看来是一个不合格架构师的表现。"架构师!=框架师”:一语中的。进一步,曹老师给了他自己的关于如何做业务的看法:领域驱动设计和微服务架构关系,SOLID设计原则,命令查询职责分离模式,event sourcing等等设计原则。讲得虚一点的概括就是:梳理、分解、抽象业务需求并落地这是一个架构师的价值体现,也是架构师的竞争力所在。加上自己的一些经历体会,架构师不是简单的技术选型(或曹老师提到的拿着锤子找钉子),或者靠听几场鸡汤演讲和网上看各大牛人、大厂的关于XXX系统的设计文章就可以照猫画虎设计出优秀的架构,更多的是从实战,教训中得到成长,并联系理论进行总结、又反馈、指导实践,形成一个正向循环。当然合格、优秀架构师不仅仅是上面提到的方面,其他方面可以等过一段时间本次峰会的PPT公开出来后,有兴趣的同学下载看看哈。
爱因互动CTO 洪强宁老师的<<从程序员到架构师,从架构师到CTO>>:对 a good programmer定义了5个精:精细,精湛,精通,精深,精明,分别对应细节之处深思熟虑(如代码结构、封装),简洁、优雅、高效的代码,了解上下游知识(全栈、devops),掌握技术细节(语言、算法原理细节),准确交付(理解需求、优先级);a good architect: 取舍,前瞻,抽象,容错。后面洪老师提的architect到CTO的一个对比给我留下的深刻印象:架构师:用什么技术才能”支撑”业务,CTO:用什么技术才能“发展”业务。
另外在大数据框架专题中,首先是LinkedIn的Samza介绍,作为后来者,它catch到spark本身框架的痛点(目前,自己用redis作为statdb, 而remote db访问通过broadcast+kafka)并进行改进,其实后面提到的Apache Beam的支持才是一个关键点,目前各种离线、实时流计算框架层出不穷,他们的API及构建不一样,而通过一个统一的框架来封装这些差异,使得数据分析人员可以把时间放在真正有效产生价值的业务分析上。在第二个演讲中,来自网易的Sloth流计算平台(据称年底开源)则是从sql方向来统一离线,流计算,可能主要是考虑大部分的数据分析人员是以前写sql出分析报表,如果能将传统的sql转成现在的离线、流计算,将大大减轻分析人员学习成本。其实对sql的支持,也是目前多个大数据计算框架的目标之一,出发点也是重用分析人员sql技术考虑, 但是没有网易如此技术产品化的易用性的体验吧。这两种不同计算框架平台的演进方式,哪一种更好呢,个人更倾向并存,对于复杂的业务分析用sql要写出多大一坨东西呢,而简单的关系型的聚合分析, sql may be a good choice.
写于 汉庭酒店
ArchSummit全球架构师峰会2017年深圳站 漫谈