似乎最近写的纯技术文章少了很多，反而很多吐槽。。。
“杂谈”这个tag，不会超过hadoop吧。。。
不过，无论技术还是抱怨，无论总结还是吐槽，有思考总是好的。
关于代码洁癖
我算是有点强迫症的，对代码总是要改来改去，有时自己也觉得很头疼。
空行、缩进、变量名之类的就不说了，而且绝对不能有warning。
还有注释，如果看到很长一段代码没有注释，就会不舒服。。。所以即使是废话也要加几行注释。
怎么说呢，没有注释感觉冷冰冰的，有注释就觉得代码真的是一个“人”写的。
pom里，一定要把所有依赖精简到最小，有多余的依赖就很难受。scope能为provided的一定不compile。打包时，有多余的jar打进去，也很难受。
log4j的配置里，无用的appender一定要删掉。
各种抽象、各种接口、各种设计模式。
所以只从速度上来讲，我写代码是很慢的，总是要想半天才写几行，而且经常重构。
说实话，这样很累。
但最近，总是不自觉的用些quick and dirty的方法。
小到编码，比如字符串于之于enum，写一大堆if else，各种hard code。
大到设计，各种简单粗暴。
因为deadline压在那里。。。
测试催的人头痛。稍有延迟就会邮件通告，似乎你的进度耽误了测试、耽误了整个项目、妨碍了公司、妨碍了世界和平。。。这是个不好的地方，出问题时，所有人都在忙着推卸责任，而不是想办法解决。。。
更别提需求变更了。
在这种情况下，真的很难再精雕细琢。
但写这种代码有点不安啊。。。这就是个大坑，不一定落在谁头上，而且很可能落在自己头上。。。
有句话叫eat your own dog food，但长此以往，当你真的准备吃时，发现已不是dog food，而是dog shit了。。。到时只能自我安慰，自己X的，含泪也要吃完。。。
关于这个问题，应该有很多人思考过了。不知道他人是如何解决的。
常见的所谓解决方法是快速迭代、上线，再重构。我也很难评判是对是错。
不过重构真的不是万能的。
只能说，如何取舍，如何平衡，都没有定式。只能自己把握。
@Autowired
见过一些人，根本不知spring是何物，但@Autowired用的很欢快。
因为整个项目的框架已经搭好，一些“大牛”已经写好一些类，只要照猫画虎就可以了。
我当时就给跪了。
暂且不谈对于项目，这种“分工”是否合适。至少对于个人，是百弊而无一利。
不要以为新人才会出现这种情况，所有人都会。
对于自己不熟悉的领域，人们总是倾向于浅尝辄止，会用就好，而不太关注原理性的东西。
从我的面试经历来看，会用MR的很多，能说清shuffle过程的没几个。
但这种浅尝辄止式的“学习”，有个好处，就是可以用来吹B，糊弄下不懂的人。。。只要自己保持一副高深莫测的样子就可以。。。某人看了篇quick start就来跟我大谈特谈hadoop，还好我机智。。。
但不得不说，吹B才能获得注意，才能有存在感，所以我也很理解。
另外很多面试官其实都是这样的，问你的问题他自己都不懂。。。我找工作时就被某HR镇住了，还以为是个技术总监，太年轻啊。。。
其实分辨方法也很简单，就是看他会不会追问，考察技术的广度还是深度。
不是说一定要深入源码去了解，至少要知道大概的原理吧。还是要多看书。
我也在反思，多注意自己的言行。谨记。
关于打杂
前段时间折腾linkedin，要填自己的职位，想了半天，我写了“打杂工程师”。
这倒不是抱怨，而是我觉得，每个人都要有些打杂的能力。
最近做的事情确实比较杂。在好几个项目之间转，哪里缺人，哪里进度紧急，就被派到哪里。感觉就是个救火队员。。。做的事情也不全是hadoop相关，一般是普通的Java EE，有时还做前端。。。缺人的时候还去到处收集简历和面试。
如果能专注于某件事，专注于某些技术，当然很好。
但现实中往往不会有这种条件，除非是专门的做研究。大公司分工很细，也许可以，小公司却诸事混杂，很难专一。为什么有些大公司出来的人受到各种诟病，就是因为只会一种技能，只能在这个公司里用。
所以各种地方都混混，各种工作都参与下，蛮好。
但也不能忘记本职。个人感觉，能有一两项核心技能，同时触类旁通，博闻强识，是最好的。
通俗点说，需要你打杂的时候要能hold住。用老郭的话说，上炕认识娘们下炕认识鞋，嗯。我也越来越三俗了。。。
对我来说，目前为止，我的本职是hadoop相关的应用/运维，其他都是副业。写简历的话，至少hadoop中的某些部分我敢写精通，其他最多写个熟练。。。但要我去搞前端什么的，我也不会怕，多少还是知道点的。哪怕让我去写lisp/haskell之类的，也有信心短时间内熟练使用，不过最好不要。。。
微服务？
最近似乎所谓的micro service很火？我在InfoQ上看到了很多文章：1/2/3/4。大都是“SOA已死，微服务当立”之类的论调。
Dropwizard我很早就知道，非常喜欢这种开箱即用的框架。最近又知道了Spring Boot。这就是所谓的微框架。难道用了微框架就是微服务？恐怕不是。
虽然我对SOA的理解完全来自google，没什么实践经验（只用过dubbo）。但感觉SOA是抽象程度非常高的概念，所以每个人的理解、实现都会有不同。而现有的标准实现太复杂了，需要各种技术SOAP、WDSL啥啥的。就像以前的EJB规范一样。
引用一段话：
很多人使用SOA的原因就是为了用而用；厂商、委员会与协会一起过来告诉我们什么是我们“需要”的。最终，SOA也提出了关于组织结构的相同目标，不过却迷失在了WS-*规范中。
于是出现了一种SOA的简单实现，就是微服务。SOA和微服务不是对立的，而是class和instance的关系。
感觉微服务就是一堆小的tomcat，使用者要按需调用。。。这其中也有很多问题，比如如何发现服务、如何管理之类的。
其实很多产品，早期都是所有服务做在一起的，可以理解为一个大tomcat。后来随着业务发展，才开始逐渐拆分。
所谓天下大势，分久必合，合久必分。
反正就是来回折腾。也许某天“微服务”又被一个大一统的框架取代了。
据说JAX-RS是用来取代JAX-WS的，但用起来也没觉得简单。。。
另外“软件咨询师”到底是干啥的。。。感觉就是发明一堆概念拿去卖钱。。。
小步快跑？平台化？
最近老大总是跟我们提到一个词，小步快跑。感觉上就是快速迭代，先把眼前的需求做掉再说，细节的问题以后再修。
不过他是很鄙视这样的，说这样坚持不了多久，早晚会死掉。他给我们灌输的思想是要做通用性的平台，在这个平台上可以承载各种各样的业务。平台初期可以做的不完善，但一定要留出扩展的余地。
我想了想，觉得还是很有道理。
所谓的小步快跑，初期实现非常容易，一个星期上线一个产品绝对不是开玩笑。但蛋疼的地方在于容错性小，扩展性差。如果不断的有需求进来，就要不断的做一个个小的系统，不断重复着相似但是又有些许不同的代码和逻辑。最后变成一堆无人敢碰的遗留系统。。。
小步快跑适合用在哪里？1.初期圈地；2.忽悠投资人。。。
平台化的思维则是尽量考虑扩展性，初期也许降低了开发速度。但有了平台的支撑，以后的开发反而会变的很简单。所以最关键的问题在于平台的设计。这没什么捷径可以走，只能凭经验和自己摸索。成了就是高瞻远瞩，不成就是过度设计。
比如我拿到某个产品的需求，感觉就是很简单的java应用啊，mysql+spring搞搞不就好了。
但老大一看，就说这个功能可以用已有的招商系统实现，这个功能可以套到已有的运营后台，另一个功能我们要做一个服务凭证的平台，以后其他产品也可以用。。。
怎么说呢，这是思维方式的差别，不服不行。
我是没什么电商相关的从业经验的，所以只能看到具体的需求。而从阿里出来的人，见识过很多。尤其是呆的时间比较长的，经历了淘宝怎样从一个普通的LAMP变成巨大的平台。经历过，自然知道怎么做。思考问题的方式自然也不同。
比如我，有过一些运维经验，所以在设计系统时，也会更多的考虑可用性、SLA、运维友好之类的问题。
而经验这种东西，是不能凭空想象的，需要一点点积累。
小步快跑和平台化，从某种角度上来说是对立的。
就好像你不能既当T又当DPS，总要有所取舍。
开挂另当别论。如果有这种逆天的挂，请务必通知我。。。
每个公司的发展过程中，都必然经历这一阶段。只有度过这一阶段，小公司才有可能发展成大公司，注意只是有可能。小公司发展过程中有太多因素会导致死掉，但如果是死在技术不给力上，身为码农也太没面子了。
而我们目前就在这个阶段艰难跋涉。对我个人而言，有这样一段经历，蛮好。
于是我对自己有了新的定位：造积木的。
我做的只是造出尽量好的积木，表现力尽量丰富，比如乐高那样的。让使用方按自己的意愿拼成自己想要的样子。也许叫橡皮泥更合适？
其实吧，这有点类似中间件的概念。具体业务之下的，都可以叫做积木，无论是语言、框架、工具。当然hadoop也是。但积木是有层次之分的。java属于底层的积木，MQ更上一层。而我要造的，是比较接近上层的，与业务方只有一层之隔。
我以后写本书，就叫《积木论》，感觉像儿童图书。。。
关于翻译
曾经我还想翻译一些技术blog，比如cloudera blog，databricks blog之类的。上面有很多高质量的关于大数据的文章。
到时在文章标题前面有个大大的前缀——【译】，好像也不错啊，逼格瞬间提升。
可惜，看懂是一回事，翻译又是另一回事。
尝试着译了几段，自己读着都别扭，就跟hadoop权威指南的中译本似的。
我算知道这本书是怎么翻译出来的了，敢情语文水平都跟我差不多，也就比机翻好一点。
黑这本书已经是我的日常了。。。
而且按我的风格，总想夹带些私货进去，吐个槽之类的。
但既然是翻译别人的文章，总要严肃些。如果我的私货比原文还多，还不如重新写一篇。
于是不了了之。
也许其实只是懒而已。。。
总结？
只是想随便写写而已，为何又写了这么多。。。
本来还有一节，叫做“装B有风险”，写了一长串又被我删掉了，怕影响不好啊，我记得就好了。
大千世界无奇不有，不能高估别人的下限。
本篇文章为何叫“方法论？”（注意是有问号的）？可能部分是受了这篇文章影响。这些抱怨我觉得都有些道理。
在我们身边存在着各种各样的“方法”，大多是别人告诉我们的，比如软件工程、各种管理书籍、各种业界标准。似乎只要按着这些方法做事，就是正确的，至少也能避免最坏的结果。也许这些“方法”刚发明时是好的，但很多却渐渐僵化，变成了为了使用而使用。不顾实际场景而硬往方法上套，往往很惨。
也许我是个怀疑论者？我怎么觉得各种“方法”大多是忽悠人的。也许其中有些是有价值的，但很难明确该如何使用、该用在哪种场景。
工作过程中，我也会总结一些“方法”，但也会碰到很多问题。大多数问题是一个“度”的问题。
可惜我能看到问题，却给不出答案。
也许根本没有标准答案，只能凭感觉和经验行事。
