要想成为一名优秀的大数据平台开发工程师，只要做到深度与广度并重，钻研技术、理解产品、能搭架构、能解Bug，那就妥妥的了。优秀的人都是类似的，说起来就太过无聊了。所以，本文换一个角度，聊聊如何做到不那么优秀，要想成为一名糟糕的开发工程师都需要有哪些表现。

本文选自《大数据平台基础架构指南》一书，原文篇幅较长摘取时有部分删改。

我是小白我怕谁

要想成为一名糟糕的大数据平台开发工程师，首先你得干上这行，怎么入门不重要，重要的是自我修养要从入门抓起。

大数据开发如何入门?在各种论坛或技术会议中，时不时地会有人问起这个问题。而提问者的问法往往也很类似：对大数据开发很感兴趣，想学大数据，但不知道该怎么入门?应该学些什么呢?

对于这个问题，我也总能估计到提问者的预期答案。应该包括一串技能清单，以及回答问题者自身的成功实践示范：先看什么书，再学什么课程，然后搭建一个什么系统。最好列一个完整的学习计划和清单，要是还有各种职位需求的市场调研和薪资待遇的统计分析那就更完美了。

至于搞清楚自己到底喜欢什么，为什么喜欢，很重要吗?让专家来替自己做主，直接告诉自己该学什么，效率岂不是更高?

敏而好学，不耻下问

学什么的问题解决了，下面来解决怎么学的问题。

遇到问题前先思考一下，看一下文档，读点代码，分析一下日志?不存在的。都什么年代了，社交为王。微信里加了这么多大数据群组干吗用的?“讨论”问题啊!“敏”而好学，快就一个字!

要是有人胆敢拿出“如何问一个好问题”这样的垃圾文章出来敷衍这样好学的同学，那就是傲骄。往往会被这位同学反驳：问一下不可以吗?你懂还是不懂?懂就回答，不懂就不要胡说!古人云：不耻下问，你能有回答的机会就是你的荣幸!

那么，如果想在这个领域长期耕耘下去，这样做靠不靠谱呢?据说大数据平台相关开发工作，面对的问题往往是复杂的，需要从业人员具备良好的学习总结和推理分析能力。如果不具备主动学习和思考的习惯，听说也就几乎不可能成为这个领域的专家?

在这些同学看来，这种言论简直就是妖言惑众。事实胜于雄辩，明明有好多公司，有很多同学，在日常工作中就是这么做的。他们也搭过集群，复制粘贴过代码，写过ETL程序，遇上过“特别复杂”的难题，比如集群莫名其妙起不来了之类的，百度一下专家推荐的配置参数或者搜索一下出错信息就搞定了，还经常写点“我司数据平台的踩坑经验和实战的分享”，你就说牛不牛吧!

什么?这种情况长久不了，这类工作迟早会被替代，尤其是在偏底层的基础平台开发工作环境中?那得多久的将来啊?至于AWS和阿里云平台上的标准化服务，没听过，我们要有自主知识产权啊!

效率优先，中文至上

能百度就不谷歌;能找到不知道谁写的搭建笔记，就坚决不读官网的向导文章。要是还有手把手的教学视频，那就更好了。

集群如何调优?问题如何解决?根据错误信息，搜索踩坑指南，别管花多少时间，在多么不起眼的博客也要搜出来。至于官网的问题FAQ或性能调优指南，抱歉，没时间看。至于邮件列表和Jira，那是什么东西?

怎么，这么做不行吗?有些同学可能回答，这也没啥大不了，不是看不懂英文，但是还是更习惯看中文，如果不到山穷水尽，能用中文就用中文呗。

或许你总能给自己找到这么做的充分理由，但除非你想永远玩别人早就玩剩下的东西，否则，还是应该尽可能接触第一手资讯。觉得英语水平差，看英文文档代价很高吗?实际上，筛选过时或错误信息的代价可能更高。

流行的就是最好的

什么技术热门就学什么，不管自己行不行，先看赚不赚钱。

这种现象不只在大数据领域存在，在各个技术领域都存在，从这几年我所接触的求职者的求职意愿上就能很明显地看出来。

无论校招还是社招，无论是刚从别的方向转行想做大数据，还是在大数据领域内已经有过一些简单业务开发经验的同学，几乎90%以上的应聘者都会把自己将来的工作和实时计算挂上钩，越是“初生牛犊”越是积极。可不，不玩Spark，不玩Flink，还怎么跟上时代，大家都说Hadoop已经被淘汰了!

其实蹭热点本身问题不大，不过要想长期发展，关键是你本身也要具备相应的实力，大家都想做的事，你凭什么能比得过别人，就算现在没问题，过几年等该领域成熟了呢?与其研究哪里是热点，不如想想自己适合做什么样的工作，如何让自己在技术的变革中持续成长。

我们的征途，是星辰大海

也有同学会说，我并不是跟风追热点，只是当前的工作真的不适合我，我希望去做更有价值、更有挑战的事。为什么现在的工作不合适呢? 比如：

• 业务太烦，琐事太多，没有时间学习。
• 干了很长时间，重复劳动，没有成长的空间。
• 系统很成熟了，没有什么可做的了。
• 做的事没挑战，发挥不出我的能力。
• 做的事太普通，觉得没前途。
• 问题太多，团队技术水平太差。

总之，就是我行，但是，这事不行、环境不行，所以我要换方向、我要换地方。

诚然，上述情况未必不客观，很可能也是这些同学在工作过程中的真实感受。但我敢说，如果这就是全部原因，那么，有一多半问题的根源不在环境，而在我们自身。因为上述情况只是问题和现象，不是答案和原因。

• 琐事太多，重复劳动太多?有没有思考过如何化繁为简，还是只会用体力劳动代替脑力劳动?
• 系统成熟，没什么可做的?是系统真的完美无瑕了，还是我们坐井观天，眼界太低，不知道该如何改进?
• 做的事没挑战，做的事太普通?是事情本身太普通，还是做事的目标和方法太普通?
• 问题太多?是同事能力太差，还是自己只会头痛医头，解决问题不彻底，又或者是没有能力推进复杂问题的解决?

当然，每个人都希望在一个最好的环境中工作，这并没有错，但如果你只是单纯地回避问题，而未曾解决过这些问题，那么在新的环境中，你早晚还是会遇上同样的问题。

书中自有颜如玉，热衷阅读代码

有些同学，特别是经常和开源相关组件打交道的同学，会特别喜欢阅读代码。

阅读代码，当然没错，说实话，爱读代码的同学现在也不好找了。但是，过犹不及，毕竟阅读和熟悉代码只是手段，而非最终目的。遗憾的是，有时候，很多同学往往并没有认识到这一点。

这些同学很可能惯性地认为，只有依靠完全彻底地理解代码，才能得到第一手资料，才能更好地评估实施方案。

而事实上往往事与愿违，一方面，你可能迷失在一些无关痛痒的局部细节上;另一方面，你可能忽视了真正需要尽早找出答案的问题。

实际上，这也是一种用战术上的勤快来掩盖战略上的懒惰的行为表现。因为阅读代码可能是程序员最习惯做的事。但是，采用其他可能的方式去评估或熟悉一个未知的系统呢?

比如详细阅读官方文档，进行功能验证和Demo测试，对类似系统进行横向比较，收集他人踩坑经验，寻找问题的其他可能解决途径等，这些工作往往有可能更加快速全面地帮你了解一个系统，并做出合理的方案设计。但是这么做会涉及持续的思考、分析、判断和尝试的过程，所以有时候很多同学往往不愿意在这上面多费力气。

谜之问题的谜之解决方式

相比阅读代码的执着，很多同学在分析问题时的表现却往往与之相反。

分布式环境下的问题往往错综复杂，如果一个问题不是明显的确定性逻辑错误，而是跑得慢、性能差、莫名其妙地随机崩溃、超时等，不少同学很容易就快速陷入迷茫中。而为了将自己从迷茫中挣脱出来，往往会在问题排查过程中，轻易地将某些故障的现象归结为故障的原因，进而以治标不治本的方式来解决问题。

做得好一点的代码流派的同学则可能在排查问题过程中，发现一个Error或Warning日志，还会去阅读相关的代码，最后花几天时间阅读完代码，可能分析出了什么流程会打印出这个Error日志，但却不知道或者解释不了为什么当时程序会走到这个流程，同样也就排查不下去了。

上述情况，通常还是方法论问题，不知道如何把握问题的重点，在问题自身信息尚未收集清楚的时候，就过早地聚焦在某个收益未知的现象上。而对于进一步的动作，比如：

• 质疑问题，考证现象，现有的结论是否站得住脚，是否还有疑点。
• 能否再多方面收集一些信息，或者换一个角度，尝试用别的方式分析问题。
• 能否想办法复现问题，或者学习新的技能解锁进一步分析问题的能力。
• 能否改进日志，争取下一次问题出现时能收集到更多信息。
• 在自以为修复问题后，能否针对性地进行后续的监控分析，看看是否真的解决了问题。
• 在类似这些工作方面，往往就没有表现出应有的执着了。

勤奋好学，但是回头即忘

作为一个有梦想的工程师，你一定会去关注新技术。

如果方法得当，在短期内依靠深入阅读文档、翻阅核心代码等手段，你往往可以快速地在几天内对一个系统形成基本的认知。

只可惜，大数据领域的技术日新月异，加上很多系统相对复杂的架构特点，决定了这些新技术往往信息量不小，如果你没有真正深入地实践过，通常很难形成有效的长期知识记忆。可能再过一个月，你刚掌握的内容就都忘得一干二净了。

花费的精力就要产生价值，做好留存工作，在一个需要长期积累的领域，很多时候可能比拉新更加重要，将来的激活成本也会低很多。

总结

反面视角谈完了，再从正面鸡汤的角度总结一下吧：

• 有“钱途”的方向，未必适合你，除非你具备战胜80%以上的跟风者的能力。
• “快速”学习的结果通常是欲速则不达，请学会思考，请阅读第一手资料。
• 阅读代码很重要，但比阅读代码更重要的是阅读问题。
• 知识面决定了你的广度，但信息不等于知识面，人云亦云的概念一钱不值。
• 在抱怨工作之前，先审视自身问题，毕竟改变自己更加容易，也更普遍有效。

最后再补充一句在食品安全反伪科学中常说的一句话：“脱离剂量谈毒性，都是耍流氓”。上述所有问题，并无绝对的对错，重要的是对程度的把握，你是否认清了自己的目标，你所做的事情与你想要的结果是否能够匹配。