自去年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.
写于 汉庭酒店