莫要轻视应用架构

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

的确，在这个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，都不是庞然大物般的程序，而是贴近问题域，合理解决问题域的解决方案，也是从技术角度，希望自己能够在最近两年里能够达到的水准。