小马的世界

读书笔记-软件工程师指南【2-7-2】拆分工作

下面的内容是我在作为一名程序员入职之前阅读的由Gergely Orosz写的The Software Engineer’s Guidebook。我将将阅读时得到的重要的信息总结成中文以供大家分享。

拆分工作

需要完成的工作越容易,估计所需时间也就越容易。将工作细分为小部分,然后挑战自己将它们再细分!这样做有助于更好地组织工作流程,提高工作效率。

不要害怕增加、删除和修改任务
有些开发者倾向于仅仅按照既定任务来工作,即使他们在中途意识到需要新的工作,或者有些任务不再合理。
不要成为这样的人!记住,目标是构建解决客户问题的软件,而不仅仅是完成任务。
任务只是组织工作的一种工具;不要忘记这一点。利用这个工具,但要在需要的时候毫不留情地改变、增加任务,或者删除多余的任务。如果遇到新的工作或者遇到阻碍和新的限制条件,那么你的原计划可能需要重新修订。在这种情况下,大刀阔斧地整理任务!
不要忘记任务或者其他组织工作的方式必须提升生产力。不要把更多时间花在处理任务上,而忽视了编写代码。

估计你的工作用时

许多软件开发人员害怕被问到“这需要多长时间?”。尽管如此,这个问题还是会被提出。企业需要计划,不管你喜不喜欢,你都会被要求估计任务所需的时间长度。唯一能提升这方面能力的方法就是去做。
有一些开发人员认为准确估计是不可能的,他们主张采用无估算方法。然而,我认识的可靠工程师是出色的估计者:他们给出准确的估计并清楚地说明“未知因素”和延迟。
估算是一种可以学会的技能,但是随着手头工作类型的不同,挑战也会有所不同。

对先前类似工作进行估算

这是最容易进行的类型估算。假设你需要添加一个新功能,这个功能与之前做过的工作非常相似。这可能是为网站添加一个新页面,或者为API添加一个新的端点。你可以根据上一次完成类似任务所花费的时间,合理地估计新任务所需的时间。

估算你以前从未做过的工作

这是一个更有趣的地方,因为你没有经验可以作为基准。然而,有很多方法可以根据工作类型来准确估算时间。以下是七种常见的工作类别,以及如何精确估算它们。

#1:与同事类似的工作。

通常会有团队成员已经编写过与你第一次尝试的工作类似的代码。你不是从零开始!已经编写过类似代码的开发人员可以估计完成该工作应该花费多长时间。唯一的区别是你肯定会花更多时间来完成工作,因为你需要了解一些背景。如果向他们咨询并分解他们的方法,你可以得出一个现实的估计。由于是第一次尝试,可以把估算时间延长一点。

#2:重构。

你改变代码结构,但不添加新功能。如果你以前做过重构,即使现在要做的重构类型是新的,也可以利用那种经验来得到“基准时间估计”。或者,问问团队成员他们是否做过类似的重构工作,以及他们是否能分享工作的难易程度。你也可以简单地对工作进行时间限制。时间限制意味着为任务指定一段时间,并且只在这段时间内工作,不再超时。

#3:使用你熟悉的技术进行的全新工作。

在这种情况下,技术风险不大,你不太可能卡在语言或框架的一些bug上。最大的风险是业务需求不清晰。但是如果任务很明确,就可以得出足够好的估计。

#4:与你不太熟悉的系统集成,使用一个你熟悉的技术。

当你需要在一个你不熟悉的系统上构建或集成时,估算就会变得更加困难。这可能是与另一个团队或第三方拥有的端点集成。最大的风险是打开一个被标记为“未知”的潘多拉魔盒,里面充满了关于系统如何运作的未知因素。它可能与文档所述不同,可能存在一些你没有考虑或记录的边缘情况,也可能缺少文档。在这种情况下,考虑先做原型,当你建立了一个简单的概念验证来测试其他系统或API之后再给出估计。如果无法建立原型,你可以给出一个“理想估计”,假设系统没有问题。还要提供一个“最坏情况”估计,假设系统的行为异常,并且需要解决方法。最糟糕情况下的时间估计从定义上就是高的。如果有压力要给出一个估计,就提供一个最坏情况的估计。会有一些不解的眼神,但这将有助于为原型的时间限制提出理由,这样你就可以给出更准确的估计。我的建议总是先构建原型,因为它能让你提供一个准确的估计。

#5:使用你不太熟悉的成熟技术构建简单项目。

假设你正在使用一种你经验较少的稳定技术进行项目开发。在这里,学习新技术——语言或框架——是最大的努力。获取一个现实的估计的最佳方法是询问使用过这种技术的工程师。他们可以指导你从何处开始,帮助你估计学习这方面可能需要多久。要对他们的估计持谨慎态度,因为他们可能低估了掌握这项技能的难度。如果可能的话,与熟悉这种技术的开发人员一起工作,因为这将缩短实施工作所需的时间,并加快你的学习过程。如果无法与开发人员合作,你可以使用一个时间限制的估计来迅速掌握这项技术。要确保这个时间段足够长,能浏览一些教程,做编码,并查看你的前几次迭代代码是否需要比通常更多的调试。

#6:使用你不太熟悉的新技术构建简单项目。

新的框架或语言比成熟的技术带来更多的风险。学习材料更少,可以回答问题的人也更少。此外,新的语言或框架很可能会有bug。在没有进行一些原型设计的情况下,很难估计使用新技术需要多长时间。因此,请先构建一个新技术的概念验证,直到你能自信地使用它之前不要做估计。

#7:构建复杂系统并集成到你不太熟悉的系统中,同时使用一个陌生的新技术。

在这种情况下,要做出明智的估计有太多未知因素。你不了解的东西有:

  • 你要集成的系统
  • 技术
  • 不确定因素要准确估计,必须减少未知因素的数量。
  • 可以通过两种方式做到:
  1. 原型设计。可以从原型设计中获得估计。
  2. 将工作拆分更小!将其分解为较小的部分,每个部分包含一个未知因素。

寻找导师

导师是经验丰富的工程师,你可以在遇到问题和疑惑时信任地寻求帮助。一些公司拥有正式的导师计划,但在大多数情况下,你需要自己找导师,这并不会形成一种“正式”的关系。

在导师指导方面,不要仅限于一个个人导师,而应考虑一个人群。

每个人的经历和见解都是独特多样的。充分利用这一点是学习和职业成长的好方法。这就是为什么我相信建立一个技术部落的导师团队是非常重要的。

  1. **专注的导师:**我喜欢与一个专注的导师建立良好关系,并且感觉舒适地与他分享我的挑战和成就。定期互动设定明确的目标,并激励我们不断提升。要找到一个专注的导师,最好是联系之前已经互动过的人,或者是那些你钦佩的、与你的目标一致的人。
  2. **临时导师:**有时候,安排与那些与你的职业道路有交集但并不密切合作的人进行一对一的交流是很有意义的。例如,我可能会安排与一位架构师进行一对一的交流,了解如何更好地设计一个新的服务,分享我的想法并获得反馈。又如,会见一位资深领导,了解他们的职业经历并获取一些建议。
  3. **互联网导师:**听起来可能有点奇怪,但我确实有互联网导师。我的意思是那些在他们的博客、书籍、播客等上分享他们职业历程和经验的个人/领导者。随着时间的推移,我已经确定了一些写作风格和想法与我产生共鸣的人,并且他们提出的建议/想法是可行尝试的。并不是每个建议/想法在你的情境下都能说得通。

保持你的“友好值”

每个人都有一个友好度余额。当你帮助别人时,你的友好度余额会增加。当你请求帮忙时,它可能会减少。当你没有正当理由地打断别人时,它肯定会降低。

在团队中,如果你是较新或较年轻的成员,那么你的友好度余额会更高。人们愿意帮助你;事实上,他们期望这样做。但是如果你不花时间自己解决问题,问太多琐碎的问题或经常打断别人,这个余额会很快减少。

避免过快用尽你的友好度余额。在寻求帮助之前,先尝试最常见的调试和信息收集步骤。如果可以找到解决方案,可在线或在公司内部知识库寻求帮助。当遇到框架或技术问题时,首先要仔细阅读相关文档。

在处理团队拥有的代码时,请查阅源代码历史和最近的提交记录。如果你在调试一个bug,需要逐步检查代码、记录变量值、注意假设,并结构化分析出错的地方。如果以上方法都不奏效,找到可以帮助你的人并向他们请教。向同事寻求帮助时要做好充分的准备。清晰地解释问题,总结一下你已尝试过的方法,以及如果他们无法帮助你,你的下一步计划。如果他们很忙,请尊重他们的时间,因为他们可能有其他优先事项。在这种情况下,可以向他们请教一个快速的指引。定期为自己的善意“存款”加油。如何建立你的善意“存款”?通过做一些增加友好值的活动:

  • 为他人提供帮助。坐在一起帮助解决他们的问题。
  • 分享你的专业知识,让他人的工作更轻松。
  • 当有人帮助你解决问题时,请感谢他们,甚至更多。

尽量避免单独工作
作为一名工程经理,我很少看到经验较少的开发人员或新人独立工作几个星期或几个月取得好结果。通常,他们的工作要花费更长的时间,人们告诉我他们感觉没有效率,也感到更孤独。为了解决这个问题,在回顾会上我们决定给他们分配一个**“项目伙伴”**。但如果你的主管没有这样做,作为开发者,你可以采取什么措施呢?

采取措施解决独自工作的问题。例如,向团队中的另一位工程师请求成为你项目的伙伴,每天通过快速沟通与你对计划进行审查以及进行代码审核。如果工程师客气地拒绝了,与你的经理或主管沟通,并试图说服他们关于对团队生产力带来的益处。当然,经验丰富的开发者将需要花费一点时间与你在一起。然而,作为回报你会更快地完成工作,也更快地成长。很快,你就能够帮助团队中的其他人。

此外,增加你在团队中的信誉度余额。其他人对你的好感度越高,他们就越有可能愿意在项目上成为你的伙伴。

主动出击

我见过一些最高效的工程师,他们总是主动去承担一些较小或较大的工作,即使这些工作并不是要求他们做的。这就是所谓的主动性。
许多这样的工程师会研究一项新技术,用于项目中,无论是内部系统还是开源组件。他们与队友交流,参与了解其他项目,并主动提出帮助完成一些较小的任务。他们往往是第一个自愿承担任何出现的机会的人。

在快速发展的科技公司中,主动承担责任并参与那些并非直接分配给你的任务往往会对职业生涯产生重大影响。比如,在Uber,我看到一位初级工程师在自行调查和原型设计了一个新的微服务部署系统后,成为了团队在部署方面的负责人。其余团队成员都太忙,没有意识到这项新服务将使他们的工作变得更容易。

主动承担责任的方法以下是您可以主动承担责任来帮助团队和自己的方式,而又不会花费太多时间:

  • 记录不清楚的事情,与团队分享这些文档。“记录会加深你的理解,向同事展示你在帮助团队,也可能在未来帮助团队中的某位同事或新人。
  • 自愿进行调查。这可能包括试用新的框架或技术,原型设计如何整合新服务或组件等。如果您经验较少,可以提出与某人搭档,或者请某人与您搭档。
  • 调查团队可以使用的有趣工具或框架,与团队分享您的学习。在工作任务之余,调查一下公司中可用的工具和框架,或其他团队使用的工具和框架。例如,可以尝试新的前端框架、新的文档工具、日志框架、新的构建或部署系统等。试试看,并为团队做一个演示,陈述您的看法。即使结果是“我们不应该使用这个”,您的团队也会认识到您在努力超越自己的角色学习更多。
  • 与您的经理讨论即将到来的项目。在这个过程中,表达您对感兴趣工作的兴趣。通过向经理询问即将发生的事情,您将更好地了解工作的优先级和未来任务。通过告知经理您对某些项目感兴趣,您更有可能参与到您感兴趣的项目中。您还可能了解需要提前调查的内容。

作为一种警告:确保在承担许多新任务前完成您“期望”的工作。新任务有助于他人看到您是一个高效的人,前提是您首先要完成您最重要和分配的工作。如果您必须在做某事新的和完成您当前的工作之间选择,我建议您先完成最需要的工作。