我们需要怎样的工程师,我们需要成为怎样的工程师?

刚加入 Young 团队时,那会儿还有大半年才毕业,我就在思考这个问题,只不过当时更专注于安卓开发领域:安卓开发的核心竞争力是什么?我有一个专门的笔记来记录对这个问题的思考,由于版本迭代,最初的答案已经难以追溯,大抵就是在强调安卓平台的一些技术要点吧。
经过这几年的实践、观察和思考,我越发觉得应该把目光往更基础、更通用也更经久不衰的方向转移,具体的 APP 开发的技巧和范式,其实并不多,基本都可以抽象为软件开发的技巧与范式,无论是安卓还是 iOS,无论是客户端还是后端。当然各个平台各个领域都有其独具特色的 API,对这些 API 烂熟于胸也是一种能力,但有多少项目、多少团队需要这样的能力?对于 API,具备检索与理解的能力就差不多了,烂熟于胸性价比太低,于我是没有任何吸引力的。不过对于前后端这种软件形式而言,前端和后端还是有不同的关注点的,前端注重展示交互,后端则注重大规模高可用,这里不做展开。
那从通用的软件工程师角度出发,核心竞争力或者说核心素养是什么呢?这正是回答“我们需要怎样的工程师,我们需要成为怎样的工程师”这一问题的关键。
下面我仅谈谈个人的几点粗鄙之见,不足之处还请见谅,也欢迎指正。
关于作者:Piasy(许建林),2015 年本科毕业于清华大学计算机系,目前在 Powerinfo 带领客户端 SDK 团队

核心素养

最重要的就是逻辑和方法论(三板斧):先对要做的事情进行适度的了解,再进行合理的规划,最后有条不紊地执行
解决 bug,先得搞清楚出 bug 的根本原因,再想一个能解决当前 bug 又不会引入新 bug 的方案,最后就是编码实现。实现新功能也一样,先得搞清楚新功能的具体要求,再想一个实现新功能又不会引入 bug 的方案,最后编码实现。
前面这两项任务都要求我们对代码库有充分的了解,那如何上手一个新的代码库?更进一步,如何上手一个新的项目?
这项任务我们靠的主要是三板斧的第一步。先搞清楚项目的宏观架构,有哪些模块,各个模块如何交互;再结合具体的业务,搞清楚具体的功能是由哪些模块如何实现的,主要是宏观的逻辑流程和数据流程;最后,上手项目也是为了解决 bug 或者实现新功能,这就回到前面的场景了。
如果我们需要设计一套新的系统呢?这个要求就更高了,但还是可以用我们的三板斧予以解决:搞清楚我们想要实现的目标,结合对具体技术细节的理解,设计解决方案和系统结构,最后编码实现。设计解决方案和系统结构的过程一定要充分思考和讨论,不断提出质疑和挑战,并对设计方案进行适当调整,确保功能完备、结构清晰、可扩展。
在这个过程中,适度很重要,几乎所有领域的知识都浩如烟海,如不把握好度,我们很容易迷失其中,忘记了初心。我倾向于比刚刚够用多了解一点,既够解决问题,又能多学一点。
除了逻辑和方法论,我们还需要在相关领域有一定能力和经验的积累,此外,工作中大家通常都是团队作战,因此团队协作也是很重要的能力。积累和协作,这两点的重要性难分先后,更多的是看具体的需求。
从团队协作的角度来讲,通常我们都是希望找到一个好相处的人共事,只要人好,协作技巧可以在工作中进行训练。但这里我想提很重要的两点:沟通与度。保持积极的沟通,及时同步信息,及时抛出问题,但又要适度,不能过度干扰他人。重要信息可以立即同步,同时每日每周都有汇总,遇到自己搞不定的问题,我倾向于超过一个小时就抛出来求助。
关于积累,我想先问一个问题:何谓专家?我觉得就是在某个领域有很深的理解,洞悉这个领域的历史、现状和未来,有宏观认识还不够,技术细节也得了然于胸,不长期从事领域内的工作、不进行广泛的学习和深刻的思考、不紧跟领域发展的前沿,应该是无法达到这样的境界的。
当然,参加面试的候选人很可能远没有达到这个境界,但经过一定年限的工作积累,候选人到了什么程度,这应该也是面试官希望了解的。
前面说的这些比较虚,接下来我就结合“面试指南”这一主题谈点实的。
正如键盘男说的,“面试就是互相了解”,在我为数不多的面试经历中,我想要了解候选人的就是前面提到的三个方面:逻辑和方法论、经验和积累、团队协作。面试过程中,候选人知道哪些、掌握到什么程度,考察的是经验和积累;面对未知问题如何应对,考察的是逻辑和方法论;团队协作则通过面试过程中候选人如何交互来考察。
还是觉得很虚?那就来点更实际的内容:我的面试经历和被面试经历。

面试经历

我作为面试官的经验并不多,前期经常找不到重点,不过经过这篇文章的思考和总结,今后我应该会更加得心应手。

top Created with Sketch.