分享【企业角度分享】要倒苦水,谁没有 -- 如何避免成为一个不好的远程开发

头像
tp
837阅读25评论

我们在电雅招聘远程兼职有一段时间,我们作为企业,首先非常感谢电鸭,因为我们在电鸭已经招到若干非常不错的开发(当然这是在层层面试,实际任务刷选的结果,成功比率确实是大部分人都被淘汰了,但是留下的一定可以长期跟我们发展的,这个比例,面试成功其实就大概30-40%,然后做了几个任务后稳定下来的,又是只有50-70%,所以真正成功率也就15-20%,意思就是我们应聘5个人,可能最终能长期合作1个人左右)。
我们没有离开电鸭,因为我们项目任务一直在增加,同时远程加兼职人员流动性也大,所以我们一直会扩充我们的远程团队。

一直想分享点我们作为企业看到不同候选人,是的,各种候选人,各种有意思的不同的表现。其中有很好,也有很不好的。正如同作为候选人,你们也会对各种公司各种不同的看法。我们分享的原因很简单,我们的原因是建设性的,我们在电鸭获得了不少好的开发,我们也希望大家,平台也好,候选人也好有更好的发展。这样反过来,我们以后也会更加收益,因为我们持续需要好的开发。

那么,今天我们就想说一下,到底什么是好的开发?我们作为企业,我们绝对不会说些虚头巴脑的,等下大家看了可以自会感受。我们下面通过反面例子来说明,什么样的行为是不太好的行为,你们应该去避免。

例子1

时间改代码花了几分钟。结果单元测试无法过,泪崩。任务必须是单元测试能pass算过。

我想强调的是这个“泪崩”,首先作为一个职业开发,或者说,你把开发作为你的职业(意思是我不在乎你多少年“职业”经验),但是你选择了它作为你的“职业“,你要对他有点尊重。你不能稍微不如你的想象,你就”泪崩“吧,不管你碰到什么问题,如果你内心里面有达到这么巨大落差的负面情绪 (注意我们不是说你不能有负面情绪,每个人在工作时,都会遇到自己不舒适的区域。但我这里讲的是,当你遇到这种不舒适区域的时候,你合理的反应)。你不应该太去夸大他的难度,你应该是利用这个机会去增强你的技能,让你心里对它的这个“恐惧”降低,这才是一个好的开发非常重要的心态。你的心里不能太波动太大,因为它就是一个工作,因为这个工作需要你冷静的分析问题,解决问题,而不是一下”泪崩“一下”喜极而泣“啥的,那样你又怎么冷静去处理真正需要处理的问题?我们观察到如果开发碰到对他们有挑战的问题,他们会先尝试去建设性的解决问题,或者去调研下,我们作为企业会更加需要这样的开发。应聘者站在企业角度,问问如果你是老板,你会希望开发怎么处理,然后你自然就知道你下一步的步骤了。

回到业务上面,这个例子里面,这个”难“的地方,其实是仁者见仁。这里无非要求的是,你开发新的代码,你需要保证已有代码里面的单测要能pass。这个是非常基本的要求。如果有应聘者会因为这种要求感觉到非常惊讶,我们的建议是,你的Test Driven Development的skill/意识还不够,你应当在这方面加强。

例子2

国内很多项目都没有单测,单元测试没什么用,而且写他们还浪费时间

承认这个可能是现状,各种赶工,或者连需求都不确定的项目,写单测当然比较头痛。我们自己也有部分项目是不要求加单测的,但是大部分我们会要求单测。但是,事实上,我们想说的是,如果花时间在单测上,并不会浪费时间。原因就是,如果你不在单测里测,你就得去集成测试环境里测,那些方式绝对是更加浪费的方式(基本是手工测),不是自动化,每次代码迭代你能那么都去测,能保证都测过么?所以说,在我们看来,这种理由是没有太多根据的,他无非是,把部分责任从开发挪到了别的职位,比如让QA去手测或写集成的黑盒测试,更甚者是没有QA那么实际就是实际的用户就是你的免费QA(他们会报告bug,然后你再去修,这种模式也存在,无法评论,根据企业实际情况有存在的理由)。但是这种责任的变化绝对不是等价的,QA的集成测试是绝对没有好的单测能覆盖更多场景的,那么这就是意味着你开了更多漏洞的口子,让bug延后出现。注意”延后出现“就是个核心,这是个选择问题,就是企业选择延后bug的出现,也无可厚非,就是说企业延后等bug到生产上,用户抱怨了等等,再去修,也是可以的,因为这种模式是你不需要考虑什么覆盖不覆盖,来一个修一个。但是我们的观点就是,那你到生产上出了问题再去修,你怎么知道你修的地方会不会把别的好的逻辑搞烂?你在那么紧急的氛围下去修生产bug,你的效率一定是比你在有条不紊开发阶段,有计划,有充足时间考虑的单测中去覆盖的情况下低很多。这就是我们最终会很依赖单测。另外,有了单测,很多代码提交你都能够更加确信他就是work的,否则靠眼睑去看出代码有没有问题,那得要求reviewer有多熟悉你做的东西,基本不现实。说白了单测就是拿事实说话,简单直接明了。当然很多开发会不习惯,因为,写好单测会需要一些学习的难度,而且很多时候单测就是要花多倍于非单测代码的工时,很多企业因为这些原因就直接把他们给省了(当然我绝对不是说所有企业,很多企业都是很严格要求单测的)。只是在这里我想说的是,肯定是大部分应聘者会因为这个被过滤掉,所以为了不被过滤掉,你们可以加强这方面的学习,这个东西说难不难 ,说简单不简单,你开始潜心弄了,你就会掌握它,你总避免他,你就永远进步了阶,只能去做不需要单测的项目。另外对于远程工作,单测也是一个非常有用的验收环节,可以节省很多工作者和管理者的往复沟通成本。

例子3

开发碰到问题会说,这个项目跑不动。 部署出错了。有无关的单测挂了。

这个说的是沟通技巧,对于远程工作者,你得明白,我们看不到你,也了解你脑袋里想什么,你碰到了问题,你跟雇主的沟通的目的到底是什么?你是让他知道你卡住了,然后就完事了?还是说,你跟他沟通的目的是,你想要解决问题,如果是你真的想要解决问题,你说10个字,雇主如何帮助你?我们经常会花很多时间来改进远程工作者的沟通方式,好的开发,他们会一开始自己就有这个概念,他们会用截图,各种地方的截图,截大图(所以雇主可以看到他相关的信息,来帮助定位问题,而不是一个很小的截图,其他地方都看不到),来提供尽可能全的信息,让雇主能能够快速知道全貌,然后迅速定位问题和帮助到他们。这个是非常重要,但其实开发又很容易学到做到的一个技能,这个没有技术上难度,只是一个将心比心的常识。但是他会让你跟远程雇主沟通非常丝滑,雇主绝对会非常喜欢这样的开发和沟通,因为效率高,他需要花费的帮助你的时间会很少。这个其实不光是远程雇主,即便你作伴上班,你的lead绝对也会喜欢这样的,当你有问题,你会把所有信息都提供给他,你进行了哪些尝试等等,给截图证据,这样他看到的不是你转述的,而是客观的结果,(不需要你转述是因为,你的转述很可能是错的,那么你不给事实的原貌,那么解决问题就会需要绕很大的不必要的弯子)。我们面试都会注意这些,都是加分或减分项。

例子4

那就这样,88

承诺的任务,中途没做完,开发直接选择退出,也没有尝试过建设性的沟通,也不考虑雇主方的利益。这种情况,更好的处理方式是,你先沟通提出你的想法,而不是一言不合就甩手走人。合作出了问题,至少可以显示你的责任心,先完成手头的任务,再退出也会好很多。我们有一些开发就是属于这种和平分手,都是建设性沟通, 然后遵守责任性的完成自己的承诺之后再离职。工作本来就是双向选择,但是不论你在那里工作,兼职全职,远程或面对面上班,总会遇到各种各样和你预期不一样的状态,区别是在于你怎么去处理,你是刷手走人,还是尝试建设性的解决方案,这是个不好的开发和好的开发的重大区别。这个和第一点讲的如何处理非舒适区的方式是共通的。其实这个跟你做别的事情是一样的,常识性的,但是如果你能把这些地方注意到,你就绝对是高于平均水平的做事的人。

例子5

项目没有文档,要通过读代码来理解项目逻辑,太麻烦

现在都是敏捷开发,我们不是说文档不应该有,但是我们认为,代码本省是最好的文档。如果你放着已经部署到生产商的代码不管,非得去找别的文档来像更快速理解代码逻辑,我们认为这不是最合乎现实实际的方法。即便是项目里的readme,很有可能没有得到即时同步的维护和更新,跟不要说代码以外的各种confluence page等等。我们的意思是,代码应该是第一位的,好的开发不应该在没有看代码的基础上,去要别的(很可能是过时的)资料来了解代码本身。试想一下,即便有了那些文档,有个生产bug要你修,你是不是还是得去到代码里定位。当然项目大概得架构图啥的,我们也认为是有用的,但是他绝对是不能被代码替代的,我们感觉有的开发觉得文档不多,就觉得为难,这个就是我们要说的,好的开发不能因为这个而为难,因为你还有代码这个最真实的”文档“。

例子6

看到一个新的项目,上手就去尝试把服务器run起来,然后非要去把想依赖的集成环境配好了,才感觉舒服和踏实。而不是去更快的把单测run一下。总觉得run下test心里不踏实,觉得做了也不理解项目

这个跟单测讲的点是共同的,需要加强对单测的理解和意识,并经一步把它当作理解项目逻辑的工具。当然没有单测的项目,或者单测形同虚设做做样子的项目,不能包括在内这么处理。我们这里假设项目单测有一定覆盖面,考虑到了核心逻辑至少,那么你通过阅读单测是应该能快速理解代码业务逻辑的。

结束语

我们会继续持续补充,希望对大家有所帮助,当然,如果你觉得我们说的都是常识,那么恭喜你,你应该大概率就是很好的开发了。
如果有不同的观点我们也可以讨论,只要大家对事不对人,我们都乐于讨论。

另外,我们真心认为,虽然全世界都知道,印度是个软件大国,但是我们的亲身经验是,我们中国开发,比印度开发要靠谱太多,我们这个帖子,也是希望让更多中国开发更加靠谱,这样中国软件这个行业可以拿到更多市场份额,原因很简单,印度占的市场份额远大于他们开发的实际水平,而我们中国开发实际远比他们厉害,但是我们的占领的软件服务行业市场份额远不匹配(从海外市场来说)。而且我们可以听到,很多海外外包项目因为成本问题从中国挪到了印度,但是本质上来讲,我们的成本并不比印度高太多,但是结果是,他们的代码质量,效率真的不值那个节省的成本。这也是我们想分享给大家的这个大的背景。

分享主题:
经历/经验
收藏
举报
加载中…
精选评论
头像
等级3

“你开发新的代码,你需要保证已有代码里面的单测要能pass。”

说的非常好!支持!既然接了兼职,那对项目中以前的问题,也一定要一并处理。而且,公司也需要因此给出更多的工时(因为是按照工时付费的)。
我觉得你们公司做得挺好的。让双方都很满意。支持一个!

所有成型项目一般都是这么来的,单测就是为了保证已有逻辑不会烂掉。对于远程项目更加容易验收。其实方便双方,很多事情很容易说清楚,过了就过了,没过就没过,省了很多扯皮的麻烦。

我相信很多其他同行公司也会强调这些,这些确实会事半功倍。当然,维护这些测试包括新加测试都是需要额外成本,但是我们觉得是划得来的。当然前提是我们的开发需要有这个意识和能力写出合理的单测。这也是我们说它是重要的技能。

单测很重要!

接项目接了新任务,是新任务的工时。
“保证已有代码里面的单测要能pass。”,是属于额外的工时。

我支持你们公司!拒绝恶意抹黑!

头像
等级6

这个帖子非常好,我觉得所有接单的自由开发者都应该看看。

头像
等级0

1.优先采用云端开发,新人不用管环境问题,装个编辑器就行了。对代码安全也是好事。
2.全面基于云,serveless,服务的颗粒变成了云函数,天然支持高并发,颗粒度小更容易维护。
3.领域驱动,业务层以用例为颗粒度。大部分情况下,代码难读于业务逻辑而不是程序逻辑。
4.远程办公要依赖好的沟通软件,开会并不是好的方式,因为很多问题会上那么短的时间里并不能想明白。回头才想出好的方案。应该用discord之类。提出议题,各抒己见。也缓解了成员英语口语的问题。
5.承接3,从产品,测试,运营,开发,全面实施领域驱动,全部一套术语沟通,代码里严格按照领域术语命名。画出领域图,用例图,时序图,胸中有图才能不失全貌。大部分新人入职的问题在于一把抓,无从下手。

头像
等级3

+了微信了,但是主要平时工作时间不太确定,可以一周就认领一个任务这样子逐步展开吗?

最好是一天有2小时,比如一个任务就2小时,如果你要一个礼拜去完成,我们不可能等1周的。

微信没有看到消息,再加一下?

头像
等级0

很务实的描述了一个合格开发需要做到的各方面,这本不该成为一个阻碍/难点。只能说现在更多的开发是缺乏规范的。另一方面,因为你很清晰的表达,我对你们团队感兴趣了😊

一个蛮重要的能力就是,我们的lead和开发人员(其实和所有其他人员一样,我们在面试后的时候我们就会感觉,有的候选人,他就是一下问到点上,有的候选人,就是说一堆,然后你也不知道要怎么帮他),如何用最合适最简洁最能表达清楚问题的方式沟通,是非常重要的。我们见过沟通差的团队,什么事情都需要开会沟通,就是属于完全就不会抓住问题,不会问核心的问题,会说一堆有关无关的,但不会提取核心问题,不知道哪些是context需要提供,哪些无关可以省略。其实这些东西是你在任何一个团队都很重要的技能,你做得好,你绝对是很吃香的,让别人也很舒服,别人一下就能懂你问的点,或者一下就能被你点醒他哪里的问题。

建议大家都可以在这方面加强,然后很多时候不需要开会,几行字说清楚的问题,轻松搞定,同时还能享受自由工作。即便你是坐班,一个能打几个字就把开会搞定的事,大家不都开心么

头像
等级0

关注你们公司好久了,特别想加入你们团队,对英语要求高不?会使用NodeJS,但是大多数时间使用的是Java/Python/PHP。这个年代,体制内都随时都可能降薪,唯有多挣一份钱才能缓解内心的焦虑,增加抵御风险的能力。最近一年搞深度学习,以为靠AI能翻身。发现这行业跟玄学一样,人员也鱼龙混杂,以次充好的很多。

对英语没要求。但是我们现在没有Python/PHP的项目,Java的项目只有一点点,活也不多,也没打算摊开java。
Nodejs会还不够,得有一定的经验才能完成我们的任务。

AI吹得蛮多的,但是我们发现还是一般的互联网项目比较多,AI这种项目太专业了,面挺窄需求没那么多。再说了,AI这些,真正能做出很牛的很有用的也不容易的,大部分没太大用处,项目和需求也不稳定。

头像
等级3

印度的IT公司能拿到那么大份额的市场,主要是因为沟通方面他们更积极主动,甩锅的能力很强且能神奇的逻辑自洽。但是就真实的能力而言绝对没法胜过中国的IT公司的。

深感认同,中国程序猿确实比印度强,但往往吃亏在沟通上,另外印度人的PPT做的真好

头像
等级0

你好,说得很好,客观。
请问贵公司还需要前端开发吗?请回复

我们开发人员现在较充裕,但你还是成为团队一员,react方向,建议看下我们招聘贴的要求,面试如果通过后不能保证1周内马上有任务,得有点耐心。

头像
等级2

你说了一大堆,就是要求远程开发在保证技术的同时要有责任心,尤其是对于远程来说,这个确实非常重要。其实都是相互的,远程开发者有技术有人品,招聘公司保证费用合理及时。

这也是我们希望的,能长久合作对任何公司来说都是很重要的,既能减少招聘的成本,安排任务的时候也能交给合适的人。对于每个进加入的开发我们会由简简的任务开始协助大家尽快熟悉目前的项目,合作前期我们会定期根据合作情况做薪资调整并相应增加任务,不会因为效率变高了反而赚少了。

头像
等级1

除了第五点不太同意外,其他基本同意

在一个运行很久了的项目中,文档真的要比代码重要很多

头像
等级1

感到了国人对国外开发方式的不适,招人这块得严把关了

头像
等级0

文档在多人合作的项目里,确实很重要。比单纯的看代码效率更高。
当然,如果代码本身质量够高,并且有必要的代码注释,那么确实优于文档。

头像
等级0

五年前端,有机会合作吗

头像共建者
等级4

还挺有意思,前几年我刚开始做的时候也试过用多兼职的做法来做项目,后面不用兼职的原因是我觉得代码出品和质量不过关,出问题的话核心团队还需要多花时间收尾。目前还是尽可能依靠全职来做项目,所以团队规模一直上不去(虽然也不是特别想继续做大,比较佛系哈哈哈哈)

看帖子描述和评论感觉贵司团队应该做得比较杂,用的语言比较多,我们一开始也没硬性规定,但是目前还是锁定在NodeJS和Laravel为主,这样效率和维护性可控很多。我们唯一硬性要求是一定要有code review,至少要有两个人知道有这一段代码。

头像
等级1

确实除了第五点都说得挺好,只看代码十分需要对业务有比较深度的理解和比较好的原有代码质量。

头像
等级3

大家觉得好留言下就行,不用给我们加电量了