阅读 549

「译」当你独自开发时,你可以这么做

发个小广告,阿里云中台招前端/Java,P6及以上,base 北京/杭州,hc 非常多,机会难得,帮你过寒冬,如果有兴趣的朋友也欢迎联系 yeshu.lrt@alibaba-inc.com 进行沟通。

进入正题,本次分享的是一篇不那么干的干货。

当你独自研发(Working solo)时,你该如何充分发挥自己?

大部分开发者都在自己的团队里工作,不过有些时候,我们也会不得不独自研发,固然大量产品研发离不开团队的管理和协作,但是在个人研发时,遵循一些工程实践方法同样重要。

什么是 Working solo

Solo 一般指独自做某件事,但是在本文里,它特指一个人或一个小组在非办公环境下进行项目研发,例如:

  • 开源项目,例如一个 package 或 library
  • 个人项目,可以是收费或免费的
  • 自由职业者

上述示例的共同点是:你在开发时,并不会受到像公司里那样的约束。

为什么需要关注工程实践

原因之一是你将会成为团队不可或缺的财富。

我们设想一下你加入一个团队时最初的场景:

  • 你所加入的团队遵循的实践规范和你之前的一致,那么你会很快融入这个团队。
  • 两者不一致情况下,如果你之前遵循了最佳实践,那么用不了多久你也会融入。
  • 最糟糕情况是,如果你所在团队没有遵循最佳实践,你可以推广你的经验来改善团队流程,要不然只能离开了。

不管怎么说,我们期望的还是双赢。

另外一个原因是你还会成为一名更优秀的开发者。

软件工程可不止编程,一个产品从概念到上线需要考虑很多事情,遵循最佳实践可以帮助你走上正轨,少一些挫折。如果你钟情编码,那么当你做一些新事情时,总会有一种诱惑让你跳过其他事情直接埋头编码。但是随着时间的推移,我发现,遵循一些最佳实践会让我们在享受独自工作带来的灵活性的时候,同时帮助我们规避掉一些障碍。

现在,让我们考虑一下下文提到的一些最佳实践吧。

遵循一个工作流程

一个工作流包含许多步骤,这些步骤包含在将想法转变为产品的过程中,下面是一些你的工作流中需要考虑的事情:

  • 当决定要变更时,我该遵循什么流程来实现它?
  • 我该如何发布一个新版本给到使用者?
  • 我该如何追踪产品所做的修改?
  • 我该如何追踪Bug、问题以及未来的研发计划?

为什么要做上述思考呢?不需要任何工作流(直接编写代码,然后推送到 master 分支)看起来是最快的方法,但是随着项目规模和复杂度的扩大,你会发现,有了清晰的定义,就可以更容易确定做什么和关注什么。当在团队中工作时,工作流会帮助每个成员更具生产力。

你可以这么做:

  • 使用 issues(GitHub、Gitlab、BitBucket 或者你自己的代码托管平台)。Issues 可以帮助你追踪 Bug ,功能需求和重要变更。另外,编写 issue 标题和描述会强迫你细化头脑中的想法,定义好解决方案包含的内容,你可以使用诸如 Trello 和 Github 这样的团队管理工具来进一步实践它。
  • 使用 pull request 。许多开发者自己工作的时候倾向于直接推送到 master 分支,然而,通过 pull request 来创建变更有许多好处,它可以很容易地看到一个 feature 或 bugfix 中的所有变动,以及合并时对基线产生的影响。当一个 pull request 关联了 issues 后,我们会更清晰地看到项目的演变过程,而非通过阅读源码的方式。
  • Review Code 。这听起来可能有点奇怪,不过我们的确需要 review 别人代码一样 review 自己的代码。有人建议可以先提交一个 pull request ,然后离开一段时间,随后在合并功能前,在远离 IED的情况下,保持新鲜感地开始 review 自己的代码,这会帮助我们捕捉错误,发现我们所遗忘的事情。 Review Code 还会迫使我们思考为什么要用这种方式实现?什么情况下会出错?有没有更好的实现方式?
  • 维护有意义的 Git History ,尝试做像你在团队里做的 commit ,避免大量 commit ,保持语义化的 commit message 。就像 code review 那样,编写具体的 commit message 会迫使你放慢节奏,开始思考:我在这个 commit 里实现了什么,我是如何尝试实现它的?

在某些情况下,你可以允许自己打破上述约定,例如你或许会决定对于一些很小的修改(例如拼写错误)可以直接推送至 master分支,避免整体节奏变慢。

不管你将哪些建议融入到你的工作流里,重点都会是是这种意识的建立。一个成功的产品的不会凭空发生,他们一定是建立在爱和呵护上的,保持这种意识意味着你会放慢节奏,观察你遇到的痛点,并且开始思考用某些方法和工具来改善它。

构造可重用的组件和模块

遵循 DRY ,SOLID 和 FIRST 原则进行思考。使用较小的,封装的可重用模块来构建你的软件。使用像 Bit 这样的工具来创建你喜欢的模块集合并且保持更新,你会从中受益,开发也会愈加快速 。

编写文档

文档是老生常谈的话题,但是却很少有人坚持做它。在兴奋地编码之后,记录它通常是一件难事,我该如何通过文档来记录代码的复杂逻辑?

坚持写文档的原因很多,我们会犯错,会生病,会忘记许多事情,会调整项目,文档可以确保项目知识不会束缚于一个人,也可以帮助开发者全面了解项目后然后保持专注。

你可以这么做:

  • 你不是在写本书,文档并不是文学作品,没有人会为它评分,不用尝试解释一切,保持简洁明了,很多时候,点几个重点就可以了。
  • 在编码前写文档,定义产品的接口,描述它如何使用,它会如同一个规范指导你进行编码。
  • 在编码后写文档,按照使用者的视角去思考什么是重要的,如何去使用它或者如何做贡献;编码过程中接口定义可能会发生变化,在编码完成后确保它的正确性是非常重要的。
  • 编码过程中写文档,这块通常是指为代码编写文档,此类文章很多,本文不做展开。
  • 从单元维度编写文档,上述原则均适用此,一个单元可能是一个函数,一个类,一个新功能,一个变更,一个模块或者一个完整的项目。如果描述一项工作十分困难,尝试将它拆解为更细粒度的单元来描述(或者提升到更高的层次上)。

沟通

沟通主要适用于与小团队或客户合作。

为什么要遵循它?因为透明制产生责任制,当你必须要向某人报告时,它会帮助你保持专注,这就是许多公司开站会的原因之一。

另外一个原因是,团队中成员遇到的问题往往可以通过与客户或其他团队沟通来解决,我已经记不清楚我抱怨过多少次我的变更没有在线上生效了,直到另外一个团队的同事告诉我,他的变更可能会和我的冲突,从而导致失效。

你可以这么做:

  • 当你遇到未知障碍时,让你的团队和客户知道。
  • 为你的客户定时更新项目进度,尝试让这些更新不要过于技术化。
  • 让你的团队知晓变更计划时间。
  • 消除沟通的障碍,确保每个人都可以很容易知道别人在做什么,挑选适合你们的沟通工具。

本质上,确保及时反馈,这会消除大部分合作者之间的分歧。

监控

所有的事情都可能会发生错误,部署出错,编码错误,异常抛出。准备好监控方案非常重要,它可以帮助你更好地掌控这些错误。监控也是反馈的重要部分,它避免你构建一个象牙塔,而不知晓你的产品的真实运行情况。

你可以这么做:

  • 捕获日志,必要时不要不好意思编写 console.log() ,记录更多的信息总比记录少的好,但是务必记住,不要记录不必要的细节污染日志,以便更容易的筛选日志。

  • 知晓日志存在哪里,并且配置一个方便查阅的系统。最基础的查看日志的方法是通过 SSH 工具访问你的服务器,并且调用 tail 命令查看你的日志,或者传送你的日志到日志采集系统里。无论哪种方法,重要的是当你编写了日志后,你清楚去哪里查看它。

  • 不要忽略错误。虽然你的应用应该具有弹性(在发生错误时自动恢复),但是依然要在发生异常时记录错误日志。举一个例子,如果你正在调用一个 API 来获取用户的信息,并且你已经准备好处理 404 异常,同时也应该记录来自该 API 的其它错误,有一次我遇到这种场景时,并没有去记录错误,从而导致我无法感知到调用失败的具体原因——因为接口调用超过限制导致我的应用被加入到 API 的黑名单里。

  • 检查你捕获的日志,这可以通过人工或者自动的方法来完成,曾经我遇到我发布了一个简单的修复,但是后来我才意识到它并未按照预期运行。从那时起,我通过在发布后监控应用日志的方式,来确保程序运行符合预期。

监控方案可以有很多种形式,可以是简单的控制台 log ,也可以以文件形式存在于第三方服务商(例如 Sentry, Bugsnag 和 Elastic APM ),挑选一种适合你的,然后使用它。

观察和迭代

这是一个最佳实践,并且也是其他实践的落地指南。没有一个适合所有人的公式。人们习惯不同的工作流,监控策略,文档风格,这便是为什么要持续观察和迭代的原因。

观察主要指批判性地观察用户的行为和表现。通过观察,你可以将所闻所知结合起来,推断出一些结论。当独自研发时,你通常无法受益于高级的用例研究或者 A/B Test ,所以你可以采取一些非正式的方法,例如用户评论,issue 报告和日志。观察之后便开始迭代,迭代是根据你观察的结果来改进你的产品,随后再次进行观察。在观察之后,下一件事情是得出结论,然后实现它们,但是这绝不是终点。

举一个例子,我的一个 APP 包含了一个项目列表,并且按照 UTC 格式显示了它们的创建时间,然而这对许多用户来说,显示的时间是错误的,这给他们带来了许多困扰。我决定通过在时间展示后面增加 UTC 字符来修复这个问题,效果还不错,但是这时我意识到,为什么不能根据用户自己的时区来展示时间呢?据此我调整了时间展示策略,并将它们调整为用户所在区域的时间,效果更好了。在与部分用户交流后,我了解到对他们来说,最重要的不是展示精确的时间,而是告诉他们这一项存在多长时间了,于是后来我调整时间展示为相对时间,例如“5分钟前”,“2小时前”,虽然没那么精确了,但是对用户来说更加易用了。

这也适用于你的内部流程,没有什么方法是一成不变的,当您选择实践方案时,重要的是观察其是否有效,并且在其基础上迭代,持续做出变化直到你找到适合你的方案。

总结

理想情况下,在结构化的产品研发环境里,从产品所有者到开发人员,有许多不同专业的人扮演着重要角色。当独立进行研发时,重要的是我们自身要尽可能填充这些角色,因此你可以按照你自己的意愿来做这些事情,最佳情况下,你可以利用这种自由来创建让你效率更高的结构,这会花费一些时间和精力,但绝对物超所值。

关注下面的标签,发现更多相似文章
评论