标签:技术

成长,就是持续创造价值

成长,就是持续创造价值

我时不时会收到一些小朋友们的私信,问是否招实习生或者「程序员学徒」的,可以不要薪水。我一般 […]

技术部门团队管理的一点心得

技术部门团队管理的一点心得

最近半年公司一直在对整体业务后端数据存储做大修改,由我负责开发核心的数据存储、拉取组件,这 […]

关于开发流程的一些体会

关于开发流程的一些体会

工作近5周,共完成了2个项目(第二个项目已经基本完成测试,准备收尾中)。第一个项目,是用爬虫抓取数据,然后做好 API 供用户使用。第二个项目,是扫描僵尸用户,发邮件唤醒,如未唤醒则关停僵尸用户的进程。

做这两个项目的过程中各有各的体会。

首先,是关于解决问题的方式。做第一个项目时,刚刚进入公司,很难适应工程师文化,加上和同事不熟悉,脸皮薄,不愿意问问题,甚至没有仔细确认需求和工程方式就动手开搞,最终耽误了不少时间。在工程上,沟通极为重要,工程师不是低着头闭门造车的,恰恰相反,工程师们是用集体合作的方式共同搭建一个或繁或简的系统,最终完成个体无法完成的大规模工程。这应该是工程师们在一起工作的最重要意义之一吧。

工程被分割成一张张工单,并不意味着其整体被切割成无关联的个体。在完成工作的时候需要尽可能多的理解工程的有机性。例如我将爬下来的时间序列存入数据库时,每条数据的时间都被我存成了str,于是在后期制作 API 的时候就遇到了一些问题,最后需要通过将其转成datetime来解决。类似的问题说明我在完成某件工作时,并不知道这件工作在工程中的位置与意义,这就需要多问和多做了,在对整体熟悉了以后,自然会逐渐清晰。

其次,是关于单元测试的重要性。其实『单元测试』这四个字,有弱化其意义的副作用。我在做第二个项目的时候,由于内部处理数据的逻辑比较复杂,导致大大小小的 Bug 一大堆,每次提交都认为自己已经做得差不多了,但还是在 code review 时被打脸,来来回回提交了若干次,花费大量时间,甚至同事成了我的人肉 Debug 处理器。最后同事说,你还是写一些测试用例吧,覆盖的情况越多越好。

果然,写了一百多行的测试用例后,将单元测试完成,自然发现了一些之前很难发现的 Bug,无论对我还是其他工程师来说,都节省了大量调试改错的时间,多灾多难的第二个任务也随之迎刃而解。经此一役,我对单元测试的意义恍然大悟,其实单元测试并不仅仅是『测试』这么简单。在『测试』的背后,其实是将代码化整为零、各个击破的写作过程,因此单元测试的写作时间,应当与程序本体同步,也即『写一个函数,就写一个测试』,二者几乎是同步完成的。这样看上去花了很多时间在设计测试用例上,其实是规范了自己的思路和代码,同时大大提高了后期的可维护性。

在明白了第二点(也就是单元测试的真正意义后),觉得自己仿佛突破了一个模糊边界——一个软件工程师和业余代码爱好者的界限。虽然现在代码依然很烂,但是本着对代码负责的态度和对自己职业的尊重,我会把以后写下来的所有代码都同步加上单元测试,配得上一个专业人士应有的严谨。

以上就是我在完成了两个项目后的些微体会。工程师的快乐,是由一个个微小的痛苦组成的。此生竟有幸成为工程师,真是一件幸福的事情。

我的求职经历

我的求职经历

2015年下半年,我在一家外贸软件企业任运营总监,某天无意间看了一眼当时公司产品的前端代码 […]

《Automate the boring stuff》学习心得

《Automate the boring stuff》学习心得

经过一个多月的懒懒散散的学习,终于啃完这本600多页的Python实战类教科书。在《Aut […]

技术型运营人员的几个特征

技术型运营人员的几个特征

在过去的一年中,我带领一个运营团队在外贸软件行业整整工作一年,总结下团队的成果:

1. 创造了阿里巴巴国际站内效率最高的消息群发设备组,群发量全国第一。
2. 从创建一个5人QQ群开始,将之运维到10000人的用户QQ群组。我们这行业太小,所以应该是妥妥的国内第一了。
3. 是我知道的唯一一家让阿里外贸圈论坛全站置顶红色警告的软件企业,利用了阿里的一些小bug且推广量大到惹毛官方,『捣蛋分子』成就达成!
4. 整个推广团队加上我只有3个全职,用竞品10%的资源达成竞品60%的真实注册用户量,人均效率完爆同行。

运营人员有时被公司同事理解为『文员』、因而感到沮丧和困惑。这不是事实。运营绝非『文员』,并且恰恰相反,运营是科技企业里除了一线工程师以外,最需要技术的岗位。

运营意味着为一线工程师的产出赋值,将流水线产品变成更富个性的『手工艺品』。在这个意义上,一行行代码远非产品的最终形态,那只是包裹产品的外壳,而产品的实质则产生于内容运营、用户运营、社区运营等等环节之中。如MIUI的诞生固然给当时的Android固件领域带来一阵新风,但产品本身却并不能产生滚雪球的效应,卓越的社区运营才是为小米公司获得最初市场基础的核心(而市场营销,则是在那之后的事情了)。

运营需要哪些技术?

先声明,我所说的技术,不局限于写代码,还包含自由的想象力、以及将想象力变成现实的任何实践能力。因为这些大多需要以计算机技术作为工具,因此就笼统称为『技术』了。

第一,要有一定的代码能力、或阅读代码能力。能够通过代码完成一些简单的功能,如批量操作、运算等。这里除了常见的各类编程语言,Excel等表格处理软件事实上也包含在内,能够通过Excel等工具处理复杂数据,和编程是一样的。另外,能够主动运用技术手段提高运营效率,也是一条必备能力。运营中往往涉及大量重复性工作,需要运营人员寻找合理的技术方案来解决,在寻找方案的过程中不断降低成本、提高效率。

其次,理解工程师的行为逻辑。对于产品,有自己的理解。以我部门为例,运营部与产品部毫无关联,但是产品的任何改动,无疑都会在第一时间作用在运营数据上。因此一个好的技术型运营必须对于产品有整体性的理解,即:产品为什么这样调整?用户行为和数据反映了产品设计的哪个特性?运营应该怎样承接产品的迭代方向?做运营的都听过一句话,产品是一坨屎也跟你没关系,运营得好才是真牛逼——说这种话的人显然缺乏足够的行业经验,一个老资格运营必定对产品有深刻的理解,否则无法出色完成运营工作;甚至老资格运营也应该对产品充分表达自己的意见,而作为最接近用户的运营人员,往往是最懂用户痛点的,当一位资深运营看到堪比『一坨屎』的产品时,他最应该做的就是马上扭头走人,不要在这坨屎上浪费时间。

再次,能够主动认识到自己在技术上的缺陷,寻找有兴趣加入运营团队的技术人员。运营人员再懂技术,往往也并非职业工程师,在技术上的差距很难通过业余时间的学习进行弥补。因此不断的寻找技术人员加入自己的团队,也可看做是一个技术性运营的『天生嗅觉』。换一个角度,判断一家公司的运营团队是否强健,也可以『是否有工程师全职参与运营』为一个标准,能达到这个标准的企业,其运营一般都是较出色的。

以上三点,可以看做是技术型运营人员的几个特征。再次强调,所谓『技术型运营』,并非指运营人员撸起袖子写代码,而是『运营工程师』始终处于一种『寻觅更好的运营技术』的状态中,不断提高自己对『技术』的理解与品位,致力于将团队打造成自动化的『机动部队』。有这种状态的运营人员往往可遇而不可求,一旦发现,应该尽快吸纳入团队,并赋予充分的活动空间。

这是我对『技术型运营』的理解,和对『运营工程师』的画像。粗浅理解一定错漏百出,希望与各位讨论,不吝赐教。