莫要轻视应用架构

标签: Life Tech Work | 发表时间:2012-04-20 15:29 | 作者:Stanley Xu
分享到:
出处:http://www.xuwenhao.com

在管理大规模数据处理工作的时候,发现不少工程师,包括一些老工程师,某种程度上,都对工作有着某种程度上的轻视,常常的口头禅是“这个技术上没有什么难度”,但是我其实不太认同,所谓数据处理,在技术上没有什么难度这种说法。

的确,在这个MapReduce的基础架构已经被Google设计清楚,由Doug Cutting通过Hadoop完善实现了之后,似乎大数据处理变成了一份体力工作。似乎工程师需要做的,只是写写简单的字符串解析,以及统计逻辑,对于外边很多人觉得看起来很美的工作,一旦实际接触后,常常又会觉得颇为无聊。不过,从我过去的经验来看,很多工程师也是这样对待Web时代的Struts和Spring,搜索时代的分词器,Lucene。大量算得上不错的工程师,通常当熟练运用已有的技术,在一个特定模式下工作后,就会开始觉得工作无,然而颇为遗憾的是,一旦成为一个熟练工种之后,很多人便开始停滞不前了,原先不熟悉框架的时候,他们需要10天摸索才能完成一个功能,现在熟练了,他们只需要3天了,但是之后,他们再也不能缩短开发时间,同时,他们的Bug数量也不会变少,当有新的需求出现的时候,通常第一反应就是套入到当前框架种处理,我通常称之为“1年经验重复10遍”。

有些工程师在进入这样的状况后,往往会寻求找一些新的工具、框架以及工作内容,通常,这意味着换一份工作,或者换一个开发团队,但是在新工作或者新团队下,一般在度过了一年蜜月期之后,会再次陷入“其实也就那样都是些体力劳动”状况,这种情况我一般称之为“八大菜系都吃过你也不是一个好厨子”,这个情况比“1年经验重复10遍”会好一些,但是仍然是一个糟糕的循环。

还有些工程师,会去研究所依赖的基础框架的源代码,开始依样画葫芦,搞些新轮子出来,部分热衷造轮子的同学会对所有的项目都造同样的轮子出来,这种情况我称之为“轮子爱好者”。

然而遗憾的是,这几种情况,其实都不是一个正确的,提高一个程序员解决问题水平的正常路线,这些方法也许能够帮助你从一个水准一般的程序员,变成一个还不错甚至算得上优秀的程序员,但是不能帮助你跨过平台,成为一个真正优秀的明星程序员,或者用个被用得糟烂的词——“架构师”。

这些程序员不少最终会觉得写程序是个没前途的事情,觉得只能往Manager这一条黑道上挤,从此,世界上少了一个本有希望能够贡献杰出代码的人。事实上,真正想要成为更优秀的工程师,需要做的,是在应用架构层面,去提高生产效率,乃至支持更多更强大的功能。区分真正优秀的程序员和普通程序员的差异,往往在于,是否能够真正地找到契合问题域的解决方案,通常这样的解决方案,能够在数量级上减少实际的开发工作。想像一下用EJB2做PetStore,再到用Struts,再到用Struts2/WebWork,再到用SpringMVC,乃至使用Rails。

“1年经验重复10遍”会每天反复操练EJB2,“八大菜系都吃过你也不是一个好厨子”会用JSP,Servlet,EJB2,Struts,PHP,C#.NET,“轮子爱好者”会看到Struts之后轮一个和Struts差不多的。但是真正优秀的程序员,能够改进Struts的不足,搞出WebWork,乃至Rails。这并不意味着你一定要很Fancy地去搞Google面试一样研究很多算法,也不需要你一定多熟悉编译原理,操作系统这样的底层技术,也不需要你18般武艺样样稀松地去看PHP和C#。你需要的是,在有了解决方案之后,仔细思考,真正理解问题域,寻求能够更好地满足问题域的解决方案,从细节上改进现有问题域的解决方案。这是来自我的教训,事实上,前面的三种陷阱我都荒废了不少时间,直到近两年,才愈发觉得无论是反复操练熟练工,还是18般武艺样样稀松的都会一些,甚或是轮一些别人轮过的轮子,都不是能让自己真正跨出成为顶尖程序员的一步。真正要解决好问题,交付出有价值的程序和框架,还是要回到问题域去。

这也是我喜欢Twitter技术团队以及推崇Nathan Marz的原因,无论是ElephantBird,Finagle,还是Storm,都不是庞然大物般的程序,而是贴近问题域,合理解决问题域的解决方案,也是从技术角度,希望自己能够在最近两年里能够达到的水准。

相关 [应用 架构] 推荐:

企业架构-应用架构构图

- - 人月神话的BLOG
在这里要谈的是在传统的企业架构-应用架构的基础上进一步体现SOA和企业私有云平台的思想,而非传统意义上简单的原有企业各个业务系统功能架构的堆砌. 这个思想包括两个方面的内容,一个是集中化和平台化,一个是SOA服务化和业务能力组件化. 对于该构图模式考虑两种,首先第一种是充分考虑平台层独立和平台层能力的体现:.

应用架构和技术架构

- - 人月神话的BLOG
在这里再谈下应用架构和技术架构的关系和边界问题,这里的说明和标准的TOGAF会有一些区别,仅为个人理解的一些点滴记录. 首先再说下应用架构,应用架构是和业务架构有强烈的映射关系的一个架构,应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设,应用系统间的集成关系是如何的. 即我们常说的应用架构和应用集成架构.

再谈应用架构

- - 人月神话的BLOG
前面谈了业务架构和数据架构,接着谈下应用架构,对于应用架构的描述将参考togaf信息系统架构部分的内容,但是不完全相同,总体思路是围绕在IT架构层面来谈应用架构包括的内容. 为了区分高层架构(包括多个应用的总体架构)和底层架构(针对单个业务系统的架构),前者采用企业架构中的应用架构这个词,后者采用系统架构这个词以进行区分.

Java 应用一般架构

- - SegmentFault 最新的文章
原文地址: https://blog.coding.net/blog/General-architecture-for-Java-applications. 当我们架设一个系统的时候通常需要考虑到如何与其他系统交互,所以我们首先需要知道各种系统之间是如何交互的,使用何种技术实现. 现在我们常见的不同系统不同语言之间的交互使用WebService,Http请求.

浅析信息系统架构的应用架构与数据架构

- - 企业架构 - ITeye博客
    信息系统架构包括了对于 应用架构和数据架构. 这里不再介绍具体的方法论,而是考虑如何在设计信息系统架构时有效地避免复杂性. 在应用系统层面将通过分层和配置的方式来简化应用系统,从而可以获得简单的架构. 在数据架构层面将通过分层主数据的思想来考虑我们如何来管理主数据. 企业从生产/采购计划开始,到生产/采购管理,以及现场制造的执行.

iOS应用架构谈(一):架构设计的方法论

- - 博客园_知识库
  之前安居客iOS app的第二版架构大部分内容是我做的,期间有总结了一些经验. 在将近一年之后,前同事zzz在微信朋友圈上发了一个问题:假如问你一个iOS or Android app的架构,你会从哪些方面来说呢.   当时看到这个问题正好在乘公车回家的路上,闲来无聊就答了一把. 在zzz在微信朋友圈上追问了几个问题之后,我觉得有必要以文章形式专门来讲一些个人见解.

开源应用程序架构

- WCM - LinuxTOY
建筑师会在训练过程中学习并了解上千年来由不同大师所设计的建筑,而软件工程师却鲜有这样的机会去了解现实中的软件架构是什么样子. 该书列举了以下开源软件架构设计:. 该书依照 Creative Commons Attribution 3.0 Unported 发布,既可以在线阅读,也可以在 Lulu 上购买纸质印刷版本和 PDF 电子书版本(其他格式的电子书版本正在制作中).

莫要轻视应用架构

- - 灰色的灵魂
在管理大规模数据处理工作的时候,发现不少工程师,包括一些老工程师,某种程度上,都对工作有着某种程度上的轻视,常常的口头禅是“这个技术上没有什么难度”,但是我其实不太认同,所谓数据处理,在技术上没有什么难度这种说法. 的确,在这个MapReduce的基础架构已经被Google设计清楚,由Doug Cutting通过Hadoop完善实现了之后,似乎大数据处理变成了一份体力工作.

Mule应用架构:1、关于mule

- - CSDN博客推荐文章
本文介绍Mule结构上的特性,你可以使用它们构建你的Mule应用. l  关于Mule执行单元. Mule ESB提供综合的应用集成,既可服务于小型商业公司,也可用于大型企业. 企业服务总线(ESB)作为Mule的核心功能,即可利于组织内部的内网连接,也利于基于Web的API和其他云资源的外部连接.

知识共享图书《开源应用程序架构》

- Ryan - Solidot
《The Architecture of Open Source Applications》是一本新推出的采用“知识共享署名3.0 Unported”许可证的程序设计图书,每一章节讲述了一种开源程序的设计,如Audacity、CMake、Eclipse、Hadoop分布式文件系统、LLVM、Mercurial、NoSQL生态系统、Python Packaging,等等.