要想成为一名优秀的大数据平台开发工程师，只要做到深度与广度并重，钻研技术、理解产品、能搭架构、能解Bug，那就妥妥的了。优秀的人都是类似的，说起来就太过无聊了。所以，本文换一个角度，聊聊如何做到不那么优秀，要想成为一名糟糕的开发工程师都需要有哪些表现。
本文选自《大数据平台基础架构指南》一书，原文篇幅较长摘取时有部分删改。
我是小白我怕谁
要想成为一名糟糕的大数据平台开发工程师，首先你得干上这行，怎么入门不重要，重要的是自我修养要从入门抓起。
大数据开发如何入门?在各种论坛或技术会议中，时不时地会有人问起这个问题。而提问者的问法往往也很类似：对大数据开发很感兴趣，想学大数据，但不知道该怎么入门?应该学些什么呢?
对于这个问题，我也总能估计到提问者的预期答案。应该包括一串技能清单，以及回答问题者自身的成功实践示范：先看什么书，再学什么课程，然后搭建一个什么系统。***列一个完整的学习计划和清单，要是还有各种职位需求的市场调研和薪资待遇的统计分析那就更***了。
至于搞清楚自己到底喜欢什么，为什么喜欢，很重要吗?让专家来替自己做主，直接告诉自己该学什么，效率岂不是更高?
敏而好学，不耻下问
学什么的问题解决了，下面来解决怎么学的问题。
遇到问题前先思考一下，看一下文档，读点代码，分析一下日志?不存在的。都什么年代了，社交为王。微信里加了这么多大数据群组干吗用的?“讨论”问题啊!“敏”而好学，快就一个字!
要是有人胆敢拿出“如何问一个好问题”这样的垃圾文章出来敷衍这样好学的同学，那就是傲骄。往往会被这位同学反驳：问一下不可以吗?你懂还是不懂?懂就回答，不懂就不要胡说!古人云：不耻下问，你能有回答的机会就是你的荣幸!
那么，如果想在这个领域长期耕耘下去，这样做靠不靠谱呢?据说大数据平台相关开发工作，面对的问题往往是复杂的，需要从业人员具备良好的学习总结和推理分析能力。如果不具备主动学习和思考的习惯，听说也就几乎不可能成为这个领域的专家?
在这些同学看来，这种言论简直就是妖言惑众。事实胜于雄辩，明明有好多公司，有很多同学，在日常工作中就是这么做的。他们也搭过集群，复制粘贴过代码，写过ETL程序，遇上过“特别复杂”的难题，比如集群莫名其妙起不来了之类的，百度一下专家推荐的配置参数或者搜索一下出错信息就搞定了，还经常写点“我司数据平台的踩坑经验和实战的分享”，你就说牛不牛吧!
什么?这种情况长久不了，这类工作迟早会被替代，尤其是在偏底层的基础平台开发工作环境中?那得多久的将来啊?至于AWS和阿里云平台上的标准化服务，没听过，我们要有自主知识产权啊!
效率优先，中文至上
能百度就不谷歌;能找到不知道谁写的搭建笔记，就坚决不读官网的向导文章。要是还有手把手的教学视频，那就更好了。
集群如何调优?问题如何解决?根据错误信息，搜索踩坑指南，别管花多少时间，在多么不起眼的博客也要搜出来。至于官网的问题FAQ或性能调优指南，抱歉，没时间看。至于邮件列表和Jira，那是什么东西?
怎么，这么做不行吗?有些同学可能回答，这也没啥大不了，不是看不懂英文，但是还是更习惯看中文，如果不到山穷水尽，能用中文就用中文呗。
或许你总能给自己找到这么做的充分理由，但除非你想永远玩别人早就玩剩下的东西，否则，还是应该尽可能接触***手资讯。觉得英语水平差，看英文文档代价很高吗?实际上，筛选过时或错误信息的代价可能更高。
流行的就是***的
什么技术热门就学什么，不管自己行不行，先看赚不赚钱。
这种现象不只在大数据领域存在，在各个技术领域都存在，从这几年我所接触的求职者的求职意愿上就能很明显地看出来。
无论校招还是社招，无论是刚从别的方向转行想做大数据，还是在大数据领域内已经有过一些简单业务开发经验的同学，几乎90%以上的应聘者都会把自己将来的工作和实时计算挂上钩，越是“初生牛犊”越是积极。可不，不玩Spark，不玩Flink，还怎么跟上时代，大家都说Hadoop已经被淘汰了!
其实蹭热点本身问题不大，不过要想长期发展，关键是你本身也要具备相应的实力，大家都想做的事，你凭什么能比得过别人，就算现在没问题，过几年等该领域成熟了呢?与其研究哪里是热点，不如想想自己适合做什么样的工作，如何让自己在技术的变革中持续成长。
我们的征途，是星辰大海
也有同学会说，我并不是跟风追热点，只是当前的工作真的不适合我，我希望去做更有价值、更有挑战的事。为什么现在的工作不合适呢? 比如：
- 业务太烦，琐事太多，没有时间学习。
- 干了很长时间，重复劳动，没有成长的空间。
- 系统很成熟了，没有什么可做的了。
- 做的事没挑战，发挥不出我的能力。
- 做的事太普通，觉得没前途。
- 问题太多，团队技术水平太差。
总之，就是我行，但是，这事不行、环境不行，所以我要换方向、我要换地方。
诚然，上述情况未必不客观，很可能也是这些同学在工作过程中的真实感受。但我敢说，如果这就是全部原因，那么，有一多半问题的根源不在环境，而在我们自身。因为上述情况只是问题和现象，不是答案和原因。
- 琐事太多，重复劳动太多?有没有思考过如何化繁为简，还是只会用体力劳动代替脑力劳动?
- 系统成熟，没什么可做的?是系统真的***无瑕了，还是我们坐井观天，眼界太低，不知道该如何改进?
- 做的事没挑战，做的事太普通?是事情本身太普通，还是做事的目标和方法太普通?
- 问题太多?是同事能力太差，还是自己只会头痛医头，解决问题不彻底，又或者是没有能力推进复杂问题的解决?
当然，每个人都希望在一个***的环境中工作，这并没有错，但如果你只是单纯地回避问题，而未曾解决过这些问题，那么在新的环境中，你早晚还是会遇上同样的问题。
书中自有颜如玉，热衷阅读代码
有些同学，特别是经常和开源相关组件打交道的同学，会特别喜欢阅读代码。
阅读代码，当然没错，说实话，爱读代码的同学现在也不好找了。但是，过犹不及，毕竟阅读和熟悉代码只是手段，而非最终目的。遗憾的是，有时候，很多同学往往并没有认识到这一点。
这些同学很可能惯性地认为，只有依靠完全彻底地理解代码，才能得到***手资料，才能更好地评估实施方案。
而事实上往往事与愿违，一方面，你可能迷失在一些无关痛痒的局部细节上;另一方面，你可能忽视了真正需要尽早找出答案的问题。
实际上，这也是一种用战术上的勤快来掩盖战略上的懒惰的行为表现。因为阅读代码可能是程序员最习惯做的事。但是，采用其他可能的方式去评估或熟悉一个未知的系统呢?
比如详细阅读官方文档，进行功能验证和Demo测试，对类似系统进行横向比较，收集他人踩坑经验，寻找问题的其他可能解决途径等，这些工作往往有可能更加快速全面地帮你了解一个系统，并做出合理的方案设计。但是这么做会涉及持续的思考、分析、判断和尝试的过程，所以有时候很多同学往往不愿意在这上面多费力气。
谜之问题的谜之解决方式
相比阅读代码的执着，很多同学在分析问题时的表现却往往与之相反。
分布式环境下的问题往往错综复杂，如果一个问题不是明显的确定性逻辑错误，而是跑得慢、性能差、莫名其妙地随机崩溃、超时等，不少同学很容易就快速陷入迷茫中。而为了将自己从迷茫中挣脱出来，往往会在问题排查过程中，轻易地将某些故障的现象归结为故障的原因，进而以治标不治本的方式来解决问题。
做得好一点的代码流派的同学则可能在排查问题过程中，发现一个Error或Warning日志，还会去阅读相关的代码，***花几天时间阅读完代码，可能分析出了什么流程会打印出这个Error日志，但却不知道或者解释不了为什么当时程序会走到这个流程，同样也就排查不下去了。
上述情况，通常还是方法论问题，不知道如何把握问题的重点，在问题自身信息尚未收集清楚的时候，就过早地聚焦在某个收益未知的现象上。而对于进一步的动作，比如：
- 质疑问题，考证现象，现有的结论是否站得住脚，是否还有疑点。
- 能否再多方面收集一些信息，或者换一个角度，尝试用别的方式分析问题。
- 能否想办法复现问题，或者学习新的技能解锁进一步分析问题的能力。
- 能否改进日志，争取下一次问题出现时能收集到更多信息。
- 在自以为修复问题后，能否针对性地进行后续的监控分析，看看是否真的解决了问题。
- 在类似这些工作方面，往往就没有表现出应有的执着了。
勤奋好学，但是回头即忘
作为一个有梦想的工程师，你一定会去关注新技术。
如果方法得当，在短期内依靠深入阅读文档、翻阅核心代码等手段，你往往可以快速地在几天内对一个系统形成基本的认知。
只可惜，大数据领域的技术日新月异，加上很多系统相对复杂的架构特点，决定了这些新技术往往信息量不小，如果你没有真正深入地实践过，通常很难形成有效的长期知识记忆。可能再过一个月，你刚掌握的内容就都忘得一干二净了。
花费的精力就要产生价值，做好留存工作，在一个需要长期积累的领域，很多时候可能比拉新更加重要，将来的激活成本也会低很多。
总结
反面视角谈完了，再从正面鸡汤的角度总结一下吧：
- 有“钱途”的方向，未必适合你，除非你具备战胜80%以上的跟风者的能力。
- “快速”学习的结果通常是欲速则不达，请学会思考，请阅读***手资料。
- 阅读代码很重要，但比阅读代码更重要的是阅读问题。
- 知识面决定了你的广度，但信息不等于知识面，人云亦云的概念一钱不值。
- 在抱怨工作之前，先审视自身问题，毕竟改变自己更加容易，也更普遍有效。
***再补充一句在食品安全反伪科学中常说的一句话：“脱离剂量谈毒性，都是耍流氓”。上述所有问题，并无绝对的对错，重要的是对程度的把握，你是否认清了自己的目标，你所做的事情与你想要的结果是否能够匹配。
