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

我们在电雅招聘远程兼职有一段时间，我们作为企业，首先非常感谢电鸭，因为我们在电鸭已经招到若干非常不错的开发（当然这是在层层面试，实际任务刷选的结果，成功比率确实是大部分人都被淘汰了，但是留下的一定可以长期跟我们发展的，这个比例，面试成功其实就大概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心里不踏实，觉得做了也不理解项目

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

结束语

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

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