一个业务工程师的能力体现在哪?

记录一下最近的一些思考,个人认为习惯总结与反思无论对技能的提高还是自身的成长都是非常关键的,否则你可能非常努力刻苦,但其实在很低效地做事,甚至在错误的方向上前行。

先说一下,其实我并不喜欢把工程师分成做业务的还是做基架的,即使按照公司部门的划分,你现在正在做业务或正在做基础架构,至少在自己的内心不要这样定位自己。我甚至听到有同学说自己工作了几年一直在做业务,出去面试也进不了基架部门。为什么要把业务和基架分的这么清楚呢?做业务实现产品需求就不需要有架设计的能力了吗?业务会千变万化,你怎么样在改动最少代码的情况下实现新的需求?你怎么样在实现新的需求时不会影响到老的功能?你怎么样在别人接手你的代码时能快速知道每段逻辑用意?等等,要考虑的问题太多了。你的代码还是需要抽象、封装。同样对于做基础架构的同学来说,如果你封装的东西,不能很好为上层调用方服务,本身做的再完美也是没有太大价值的,所以你依然需要了解业务在干什么,甚至预知业务的未来走向。

我要说的这几个能力都是老生常谈的了,最近换了项目组,接手了新业务,对此又要了一些新的思考。

写高质量代码的能力

这一点我想是所有程序员都在追求的,有很多的文章书籍在告诉我们要怎样设计我们的代码,但是最基本的一点往往被我们忽略了,那就是写没有bug的代码!。怎么样能在提测后,少有bug提过来。我这里把bug分成2类:功力不足导致的极端情况下偶现的bug,和因为不够细心、思考不仔细导致的普通bug。

写完全没有bug的代码确实是很困难的,对于第1类bug,可能在测试阶段测试同学也没发现,程序在线上运行一段时间后可能会触发程序异常。一旦发生了我们会去研究到底哪的问题导致的,或许还是自己技能的一次提升。

但是对于第2类bug,换句话说就是没有太大技术含量的bug,往往被我们忽视了。这可能是文案跟需求文档中的有出入,为了调试注释了某段代码在push时忘记了还原,执行了编辑操作却没有刷新列表进行同步,等等。当测试同学把bug丢过来时,你一看就知道问题出在哪,三两下改好了,也不会放在心上。一个版本下来,不知不觉就积累了很多这样没有技术含量的bug。但其实这就造成了低效的一个重要因素。你改好问题后要编译、部署,测试同学那边还要把相同步骤再走一次。反复多次,时间就这么没了。而且你还可能不断地切换你手头正在做的情况。可是如果提测后bug几乎没有,那你就可以用测试阶段的时间去做更有意义的事了。

所以我们要建立起这样的意识,在开发阶段时刻想着写的代码不能有bug,即使没有技术含量的bug也想一想是为什么产生的。接下来就是找到产生bug的重灾区在哪里。可以在一个版本开发完后回头看一下bug list,将bug分个类,基本能明确产生的原因有哪些。也可以审视一下目前在做的业务的特点,整理一下容易出问题的点,这样在开发时也会特别留意这些地方。还可以跟测试同学交流,让他们给些建议。

不管你的代码写得多漂亮,能零bug交付才是最重要的!

解决问题的能力

私认为解决问题的能力可以拆分成解决问题的态度解决问题的方式方法

首先面对一个问题时,是你打心里想不想要去解决它,比如你面对的是一个不感兴趣的问题,根本不愿意花时间去弄,那最后估计就是不了了之,或者用不理想的方式敷衍了事。在工作中,我们难免会遇到这样的问题,但还是尽量去想一想其中有没有什么让自己感兴趣的点,进而促使自己去做好。如果工作中大部分面对的事,都是你不感兴趣的,那就说明可能你对个人发展的规划,和当前公司的发展规划不是很匹配了,这时可以考虑换工作了。

其次是你打心里觉得自己能否解决这个问题,如果你认定了自己是解决不了的,大脑也会松懈下来,不去找解决办法了。所以面对问题时不能自己先放弃了,要相信办法总是比问题多的。

接下来就是解决问题的方式方法了,有很多文章和书籍都在告诉我们要如何做。我这里总结了几点自己平时可能会忽略的:

  • 分析报错的调用栈。这在自己熟悉的语言开发中是发生错误首先会去看的,但是当换了一个从没接触过的语言,比如你依赖了一个python包,而你没写过python,当这个包报错时,可能就会忽略了报错栈,直接就去问别人,或者去google。如果先看调用栈,打个log,调试一下,也许很快就能定位到问题了。
  • 擅于利用公司强大的wiki,遇到涉及公司内其他业务方的一些事情要了解时,先去搜索wiki,如果没有找到答案,再去找相关人员咨询,效率会高些。
  • 找到解决问题的办法时,要随手记录下来,以便下次遇到时能快速解决。

写文档的能力

写文档的能力对于工程师也非常重要,我想绝大部分人都是认同这一点的,但是能持续的把自己做的东西文档化恐怕就没有那么多了。对于正在做的业务能够每做一块就用文档一下,对跟别人讲解和自己后面看时都会有很大帮助。对于自己的开源项目,如果能有完善的文档,也会更加利于推广。所以养成随时记录是一个很好的习惯,同时也可以锻炼自己的书面表达能力。

沟通能力

拥有良好的沟通能力很重要,这点毋庸置疑。但是要注意的是沟通的目的是为了对事情达成一致的认知,确定问题的解决方案,不要最后变成了互相抬杠。下面几点是我根据过往的经验总结的,希望能够小伙伴们一些启发。

  • 明确沟通的目的。如果自己是发起沟通的一方,在找别人讨论前要搞清楚自己要通过沟通解决的是什么问题,以便别人更好地get到自己的点。如果是别人找到自己,要有耐心地听对方把问题阐述完,先明确他要沟通的目的。这样不至于聊的过程不在同一频道,或者扯到别的上面去,浪费了时间。
  • 对事不对人。只围绕问题本身去讨论,不要有意无意地去指责别人,或好为人师。这样都很容易引起一方的情绪,如果带着情绪去讨论,往往不会有好的结果。
  • 及早地向外抛出问题。比如对需求不明确的时候,及早找产品同学询问。再比如正在做的业务被卡在了某个环节,又是自己这个层面无法解决,要及早上升到领导那,报备出可能要延期或需要支持。不要做一个闷葫芦。
  • 简明扼要,直指关键点所在。沟通时要精炼自己的陈述,让自己的表达条理清晰,别人听了后不会一头雾水。这可能需要对自己要沟通的东西清晰明了,也是需要我们不断的是练习的。

把自己最近的一些想法记录一下,让自己更清晰的同时,也希望能给其他人一些启发。作为程序员编程的能力很重要,但是软技能也很重要。

本文作者:意林
本文链接:http://shinancao.cn/2019/07/20/Programming-thinking-1/
版权声明:本博客所有文章除特别声明外,均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处!