再谈工程师成长——从代码评审到新人培养
作为初入软件开发的新同学，你是否经常觉得对比老司机们，自己的代码质量一般，但又不知道如何快速提升？ 本文将基于最近在团队内施行的代码质量提升培训计划，从代码评审出发，展开对新手工程师培养的讨论，借此对该计划进行总结，聊聊关于新人培养背后的思考。 先用一张图来看看本次培训计划的效果总结，然后我们进入正题。 目录 纯属虚构的对话 蓄谋已久的计划 考虑再三的设计 细节满满的落地 感触颇深的结果 写在最后的唠叨 纯属虚构的对话 本故事纯属虚构，如何雷同，纯属巧合 小F是一名有经验的程序员，单兵作战能力极强，独挡一面。最近Leader给他安排了新任务，担任一名新同学的mentor，于是他的角色发生了一些转变。但因为经验不足，他在带新人的过程中遇到了一些困惑。新人的代码质量不高，负责的模块质量越来越差，已经到了很难维护的地步。两人都很着急，小F尝试过加强代码review，但效果并不好，逐渐形同虚设。 老Y最近在团队内部，花了一个季度的时间，针对新同学进行了代码质量的培训计划，收到不错的反馈。小F看到了方案后找到老Y，想了解关于代码质量提升方面的经验，于是两人有了以下对话。 蓄谋已久的计划 小F：老Y你好，最近我开始带新同学，遇到一个问题，我发现新同学的代码质量不高，设计上缺乏扩展性的考虑，维护性差，有时候会造成需求延期或者线上问题。我们也采取了一些措施，比如代码review，但每次代码review时我都没有时间细看，导致维护的模块代码质量越来越差，陷入恶性循环中，不知道怎么解决比较好。最近看到你们在团队中开展的小灶班，效果挺好的，所以想和你详细了解下，希望可以解决我现在遇到的问题。 老Y：嗯，这个问题的确比较头疼，我们团队有大量新同学，这个问题非常突出。 小F：能先大致介绍一下小灶班吗？做了一件什么事情？ 老Y：本质上我们做的事很简单，就是导师与新人每周进行1on1，但与常规1on1有所不同的是，我们配套增加了很多的机制，用于保障这个1on1的有效性，并为它设置了一个季度的时间限制，整体目标是围绕着如何让新同学在一个季度内，快速提升自己的代码质量。这些机制包含比如理论的学习，每周1on1要聊什么，季度结束之后如何评估成果，同时增加了月会，用于保障培训计划不跑偏。 小F：这个名字很有意思，为什么叫「小灶班」？ 老Y：这个培训计划的流程较重，可能会给大家带来压力，所以想取个轻松的名字中和一下。整个培训计划占用时间最多的环节是每周新人与导师的1on1，很像我们读书时老师为个别学生开小灶一样，所以就取了「小灶班」。 小F：原来如此，的确很形象。听说培训计划的文档创建时间很早，有同学开玩笑说是蓄谋已久的？ 老Y：哈哈，是的，刚启动时，有同学看到文档的创建时间是2022年1月，所以提出了这个问题。当时团队有很多新同学，所以我从那时就开始思考如何提升团队的代码质量，但一直没有令自己满意的方案，直到今年年初才大概有了思路。 小F：2022年创建的文档，直到2024年才落地，的确是“蓄谋已久”。为什么会经历这么长时间？小灶班的流程还挺复杂的，应该不是一次形成的吧，经历了什么样的过程？ 老Y：的确比较波折。最开始打算推的是代码质量规范，当时定的很细，包含需求开发的完整周期，比如Swift语言的规范，需求的每个阶段具体应该做些什么等。这些规范非常正确，但是它有个很大的问题——很难落地。就和我们平常看到的各种SOP一样，除了刚开始以及遇到线上问题时，其它时间很少会用到。所以当时把推进规范这件事将交给团队负责架构的同学时，虽然他满口答应，但也直言说这个肯定没用。于是，这个规范便搁置了。 后面也有团队尝试进行线下代码review的方案，但依然有很多问题导致难以落地，比如线下review很难凑足人，review耗时过长，效果并不一定好，很多线下参加会议的同学，由于不了解需求的背景，能够指出的问题可能也仅限于语法与风格，而这些由Lint类的工具便可以检测出来。所以据我了解也没有很好的运行。 去年12月，一次我与团队同学1on1，聊到一名新同学代码质量的问题时，他提出了要给该同学制定一个学习计划，于是，我们顺着这个思路，展开讨论了新人培训的话题，包含学习什么内容、过程如何保障、如何进行考核等，这便有了小灶班的雏形。 再后来我基于这次讨论的内容，结合新同学自己在成长过程中遇到的一些问题，首先设立了几个原则，基于它们，才有了完整的小灶班培训计划。 小F：具体是什么原则？ 老Y：基于那次讨论的内容，我设定了五个原则：可落地、针对重点人群、重流程但不过分占用时间、可衡量、日常化。 首先是可落地，之前很多代码review的策略，不管线上还是线下，都有一个问题——完全依赖大家自觉，约束力不强，同时目标并不明确，所以很难长久的推行下去，所以本次计划的首要原则就是所有的策略都可落地。 既然要可落地，那么必然需要流程来保障，因此，我设计了几个环节，每个环节都有相应的机制能够保障可落地这一要求。但毕竟平常的业务压力极大，不能够过分的占用时间，所以需要在重流程与时间占用之间取得平衡。 第三，由于流程较重，我希望做这件事的ROI最大化，因为团队同学的经验差异较大，不能针对团队所有成员进行培训，因此，我挑选了最迫切需要培训的人群，即毕业2-3年内的新人们。 第四，由于这个计划投入人力较多，并且有可落地的要求，因此在最后需要能够衡量计划提升的效果。 最后，培训只是短暂的，也并非所有同学都会参与小灶班，因此，我们希望代码质量的意识能够融入到日常开发过程中，这便是最后一个原则日常化。 正是基于这五个原则，我们设计了整套的小灶班培训计划。 小F：原来如此，由于有了这五个原则，它便与平常的代码review规范有很大的不同了。 老Y：是的，原有的代码review约束力较弱，尤其是封版压力大的情况下，基本形同虚设。在和很多新同学1on1的时候，大家反馈非常希望有人能仔细review自己的代码，但现在只能靠自己，参考原有的代码，靠自己的悟性，成长的速度非常慢。 考虑再三的设计 小F：有了这五个原则之后，你是如何设计整个小灶班机制的？ 老Y：像前面所说，其实也挺简单。可以通过一张图来描述整个流程。首先选择要参加本次小灶班的同学及对应的mentor进行组队，每个小组制定为期三个月的学习计划，也就是理论的学习。在接下来的三个月中，小组每周进行1on1深度沟通，即所谓的每周小灶，新人与老司机就理论学习、需求、代码质量等话题进行深入的讨论。这也是区别于平常1on1不同的地方，平常更加随意，并不就某些具体的事情展开讨论。但每周小灶要求讨论的内容更明确，都是围绕着代码质量展开。除此以外，为了阶段性的了解进展，我们会分别组织新人及老司机的月会，讨论过去一个月中遇到的问题，优化流程。每月会由老司机准备一次关于代码设计的分享，进一步加强大家的理解。三个月周期结束之后，来到最终的考核环节，我们选择了源码剖析的方式，由新人结合过去的理论学习与实践，选择一个常用的开源库进行分析，并输出文章。当然，为了保证大家平常持续对代码质量的关注，我们还建立了叫「充满洁癖的代码」的话题群，用于日常讨论关于代码质量的一切。这便是小灶班的完整机制。 小F：的确是加了很多的机制来保障培训的效果。里面有很多细节我挺好奇的，比如为什么选择三个月为一个周期？ 老Y：从我们的流程中可以看到，这是个比较耗费资源的培训，虽说占用时间并不过分，但在业务迭代压力如此大的情况下，一点点时间的占用都会对大家造成影响，所以这决定了培训不宜拉得过长。同时从效果上来说，很多同学停留在能完成需求即可，没有代码质量意识，不知道什么样的代码质量是好的，而在三个月的周期中，由师傅领进门之后，后续的修行还得靠个人。另外，因为最初设立了理论学习目标，以及每周仅有一次1on1，时间也不能太短，否则达不到想要的效果，因此我们将周期定为一个季度。 小F：整个流程中，老司机起到了非常关键的作用，他们的选择有什么考虑吗？ 老Y：的确，所以老司机的选择我们很慎重，不仅需要他认真负责，平常对自己的代码质量也需要有很高的要求，只有这样才能给新人树立好榜样。同时，因为要涉及到具体的业务代码review，所以尽量选择同一个方向的资深同学，可以减少额外的业务学习成本。 小F：我注意到在培训计划的最开始需要制定学习目标，这是什么原因？直接review代码不就够了吗，为什么还要理论学习？ 老Y：这是个好问题，在最初是没有这一环节的，主要想依赖每周的小灶班。但通过与很多新同学的沟通发现，大家对于代码设计的理论掌握的并不好，比如学校期间可能仅仅学过《设计模式》，但从来没有运用过，工作之后基本已经忘掉。面向对象也仅停留在考试中，很少在项目中使用。这三个月的时间，绝大部分是实践，实践涉及到的面是很窄的，所以如果没有理论的支撑，效果会大打折扣，所以后来增加了理论学习，要求新人与mentor一起制定一份三个月的理论学习计划。 小F：对学习计划有什么要求吗？ 老Y：这里根据个人的经验，以及从一些老司机的建议中，我们将目标定为完成7大设计原则及23个设计模式的学习。并且推荐了几本经典著作，新人需要在三个月的时间里，将这些内容学习完成，每周与mentor讨论学习进展及心得，至于详细的安排，就不做要求了。 小F：为什么要mentor与新人都要参加对方的需求评审？ 老Y：这里有两个考虑。首先mentor要参加新人的需求评审，因为如果mentor想要高质量的review新人代码，分析实现的问题，那么就要求mentor对需求足够了解，否则与现在的review没什么区别，最后只能发现语法或者规范上的问题。 另外新人也需要参加mentor的需求评审，目的是希望新人可以观察mentor如何做需求，在遇到问题时是如何思考，如何应对。过去和几个新同学的1on1中，我都会问一个问题，便是他们观察到哪些同学做的比较好的地方。很多同学反馈都是老司机们如何推进、沟通、设计代码等，给了他们很大的启发。 小F：的确，在实际工作中观察他人是如何做的，是非常高效的学习方式。 老Y：没错，所以我们希望新人可以从需求最初便开始关注，去观察mentor如何与PM讨论需求，如何提出建议，如何做技术评审，如何推进需求等等，后面的所有流程都依赖于一个前提，即对mentor的需求有足够的了解。 小F：从反馈结果来看，每周小灶是大家反馈收获最大的环节，具体需要讨论哪些内容？不让讨论流于表面，如何保障有效性？ 老Y：是的，这也是我们投入最大的环节，每周新人与mentor需要坐下来聊一个小时，所以我对这个环节有非常大的期待。其实并没有限制大家的发挥，主要讨论预计包含三部分，理论学习的进展、需求代码、代码质量话题群的话题讨论。因为理论学习的压力很大，大部分同学都需要从晚上下班或者周末挤出时间来学习，每周需要新人与mentor一起聊聊本周学习的情况，以及确保对学习内容的理解是足够深入的。有些mentor会比较细致，要求新人将每个学习到的设计模式都能够画出UML图，并说明他们的适用场景。 第二部分需求代码，也是最重要的讨论部分，两人会就本周新增的代码进行详细的review。这和普通的代码review差异很大，主要在两方面，一是前期mentor对需求背景足够了解。二是每周过程中都会review，没有合并代码的时间压力，mentor可以给出设计上的建议，新同学也能够及时理解并修改，而不用担心需求无法上车。同时这也是线下review，新人与mentor之间会更多的互动。所以这个环节的效果非常好。我见过一个小组，上周review出来一个性能问题后，下一次就已经提了技术需求进行优化，反馈与处理都很及时。 最后一部分是这个周期中，代码质量话题群大家所抛出来的问题。之前观察到一个现象，或许由于发表话题同学描述过于简洁，或者由于新同学经验不足，很多新同学并不一定能够完全理解全部的问题，但有时又不好意思在话题群直接问，所以导致很多问题还是一知半解。这部分讨论的目的是希望在mentor的帮助下，新人可以充分的理解问题被抛出来的原因，以及如何处理才是最优解。因为话题群抛出来的问题通常是实际业务代码，新人可以就该问题与mentor一起深入探讨，为什么这样写不好，应该怎么写比较好。所以这个环节也非常有帮助。 小F：看起来的确如你所说，这与合码时的review还是不同的，也和平常的1on1有所不同。那为什么还要设置一个观察者？他们是监工吗？（微笑脸） 老Y：哈哈，并不是，从最开始启动小灶班计划，以及对人员的慎重选择上，就决定大家认同它是有意义的，不太可能存在懈怠的问题。如刚刚所说，每周小灶是我们这个培训最重要的环节，整个培训能达到什么样的效果便取决于它，所以我们希望每个小组的讨论足够充分。小组的讨论会有很多启发或者改进的地方，是能给到其它小组作为参考，观察者的设立意义便在此，如果遇到问题也可以更加及时的调整。其实每次讨论可能不仅有观察员，还有自由围观的其它人，我们把日程都贴在了文档中，整个过程透明，有种上公开课的感觉。 小F：为什么还要有月会？它的作用就是刚说的优化流程吗？ 老Y：我们设计了两个月会，一是针对新人，一是针对mentor。新人月会上，我们采取了一种很有意思的形式，由新人两两组队，去review对方的代码，主要是为了检验各自过去一段时间的学习成果。这个月会每次讨论的非常激烈，被review的同学会说明我为什么这么设计，review的同学也会从自己的视角提出一些建议，最后会由主持人给出自己的看法。几次的新人月会下来，效果大大超出我的预期。 另外一个月会是mentor月会，针对每个小组过去每周小灶的情况进行总结，看是否有做的好，以及要改进的地方，为其它小组提供参考。所以这个过程中，我们也会对流程做一些小的调整，进度上也可以较好的把控。 小F：最后的考核环节我看是做了源码剖析，为什么选择这种方式？听说方案也变过？ 老Y：是的，最初的版本并不是源码剖析，而是答辩，答辩的内容包含学习进展，本季度内需求质量的客观数据等，由mentor、leader和方向owner参加，但其实我并不满意这一版的方案，因为除了学习进展与需求的质量以外，其它部分并不符合SMART中的“Specific”，很难衡量做的好坏与否。于是在一个周末，我突然想到源码剖析这一形式。它可以将理论与实践很好的结合在一起，如果能够充分的理解开源库的设计哪里好，为什么这么设计，那么已经可以算是初窥门径。同时因为看懂源码与能够有条理的写出来并让他人看懂之间，要求高了很多，所以交付高质量的文章，目标明确，且与代码质量关联度很高，整体来说这是一个我非常满意的调整。 小F：如果三个月结束之后，如何将代码质量意识贯彻到日常的工作中，让大家能够了解到什么是好的代码，什么是不好的？ 老Y：这是个好问题，我们的流程中有一个话题群，它的周期并不是三个月，而是一直存在。平常关于代码质量的吐槽也好，分享好的代码也好，都可以在这个群里抛出来并展开讨论。它承载了关于代码质量讨论的日常。由于这里面吐槽的代码大多是我们自己的项目，所以相比于公司的吐槽大群更加有体感，并且，这里并不是纯粹的吐槽，而是可以给出建议，讨论怎样可以写的更好。让大家在日常工作中明白，什么是团队所提倡的。 小F：看起来最初是为了提出代码review规范来解决代码质量问题，慢慢演变成了关于新手工程师培养。 老Y：没错。因为在思考这个问题时，越来越发现它并不仅仅是流程问题，流程只是其中的一方面。像很多同学所说的，流程我们都有，但是很难执行下去。于是我在想，为什么这些机制无法落地？得出两个结论，一是做这件事的人本身对代码质量的能力还存在提升空间。二是没有可落地的方式来保障执行过程。所以整体方案才从这两个方面进行展开，演变成了对新手工程师的培养计划。 小F：这个流程还是很复杂的，担心流程过重从而引起大家的反对吗？ 老Y：这是个好问题，根本原因上还是对大家有帮助，新人能够提升代码质量，mentor后续也能够少操心。在设计过程中一直在思考如何既能够达到预期的目标，又能使得流程可接受。所以在每个环节中都尽量做了精简，只保留最基础的内容。各环节中的具体应该如何执行，没有做强制的要求，保留了足够的灵活性。比如学习的内容及节奏安排，每周小灶中讨论的事项，最后源码剖析的选择，都是设计了一个大的框架及目标，剩下的交给新人与mentor自由发挥。如果当周大家都很忙，也可以暂停一周。所以整体上还是给了很大的自由度。 在正发宣贯前，我也分别找了很多同学一起review过，确保了大家的可接受程度。 小F：这个“不过分占用时间”的流程，对时间的占用怎么样？ 老Y：最占用时间的是每周小灶，mentor与新人需要每周抽一个小时时间，基本都是可接受的，对业务开发的打扰并不算大，相反可能mentor能够提供一些思路，帮助新人更好的开发需求，减少后期的返工成本。最后的源码剖析与理论学习环节会比较消耗新人的时间，大家都需要利用晚上下班或者周末的时间，这点上对新同学来说还是比较辛苦的，我们没有预留工作的时间。因为我订阅了所有文档的更新通知，发现很多同学都会在周末更新文档，但我想，这是成长必须付出的代价吧。 细节满满的落地 小F：小灶班的整个周期很长，我见过很多机制都是在长时间的运行中不了了之，最后形同虚设，看起来你们的小灶班并没有，而且这个流程还是挺复杂的，这里有什么经验吗？ 老Y：首先还是大家对这个培训本身的认可度比较高，新人能够感觉到自己的成长，mentor能够看到未来自己模块的质量提升，所以大多还是靠自驱。另外，在执行过程中也有挺多细节，比如观察员与我的重度参与，包含每周小灶、月会、月度分享等，这让大家可以看到我们对这次培训的重视，也促使大家能够认真对待。还有一点很重要，每个环节之后都有及时反馈，做的好的及时给出鼓励，这也给新人们提供了一部分动力。整个机制中，所有的过程透明，包含1on1、月会、分享等环节的日历、文档、录屏，都统一记在文档中，小组的成员都可以随时查看。最后，每个阶段都有对应的产出，比如每周小灶与学习的过程跟踪文档，月会的记录文档，最后的源码剖析文档等，这起到一定的约束作用。多个因素共同促使整个机制顺利的运行。 小F：能详细下说你参与到其中的哪些环节中吗？ 老Y：除了整个机制的建立外，我给自己定了一个原则：不能够做甩手掌柜，而是要深入参与到每个环节中。一方面是希望通过自己的参与，向团队传达一个理念，即我们对代码质量及新人成长的重视，另一方面是希望通过自己的观察，能够不断的改进这个机制。正因为如此，各个环节都有我的重度参与的身影。在第一个月的分享上，我也做了首次分享，并将分享总结成文章：浅谈代码架构设计，发布在ByteTech上。 小F：这应该也挺耗精力的，我看你也是每周小灶的观察员。 老Y：是的，我深度参与了其中一个小组的每周讨论，发现大家每次的讨论还是比较深入的，会针对某个具体的问题讨论，会前新手都会有充分的准备，在要讨论的代码处加上标记。经常也会出现会议冲突，遇到这种情况时我每次都会看录屏，对其它做的比较好的部分，以及建议部分，在内部做好同步。 小F：这些反馈非常重要。 老Y：是的，不仅对当前小组，对其它小组也有很好的参考性。同时，还能够对机制及时做出一些调整。每个小组的反馈都会在月会上再次过一遍，看是否有共性的问题。 小F：是的，这些正面的反馈在某种意义上说，也会帮助你更好的推进整个机制的运行。 老Y：没错。比如倾听，每次的小灶观察/月会等，观察员都会仔细的倾听所有人的发言，给出值得表扬的部分，以及建议，你的认真倾听，大家能够感受到，这一方面会让每个小组有小小的压力，另一方面，会让大家对这事更加重视，认可它们的价值，所以倾听本身也是一种反馈。然后是正面反馈本身，我们会在很多环节给出及时的反馈，尤其是最后的源码剖析环节，帮助大家在大部门内部打call，季度末评选获奖名单及发放奖品，多篇文章参与团队内的技术分享，这些充满仪式感的点滴，都给新人们提供了足够的信心。 小F：月会有什么值得分享下的吗？ 老Y：首先需要明确月会的目的是什么，针对新人与mentor的作用是不同的。针对新人的前面已经说过，为的是新人互相以各自的视角给到他人的代码建议，这个过程中可以锻炼新人过去理论以及与mentor沟通时的掌握情况。另外，在新人互相沟通的过程中，因为大家经验相近，所以相对于mentor，大家提出问题或者接受建议的压力会更小，从几次讨论来看，过程都比较激烈。明显也能看到大家在这个过程中，可以提出有建设性的建议。 对于mentor的月会，主要目的还是了解新人的进展，以及过程中是否有需要对机制进行微调的部分。最后有一点很重要，每次会议的结论都会在群里同步。 小F：最后一个环节是源码剖析，如何保障大家的文章交付质量？ 老Y：在最开始确定源码剖析是最终考察时，我们就确定了一个目标，每篇文章能够发表在ByteTech上，这点本身就对文章的质量提出了一定的要求。同时还通过几个方面来保障整体的质量，初始时，我会在群里给大家建议，应该如何写源码剖析文档，并给了一些网上不错的例子。开始写文章之后，每周小灶的会上mentor都会与新人一起对齐文章的进度，并给到一些建议。初稿完成之后，我给每篇文章分配了一名reviewer，为每篇文章提供建议。我也花时间看完了所有同学的文章，并给出大量的评论。最后，我在群里分享大家文章遇到的普遍问题，为大家的写作指明方向。经过几轮的修改之后，所有的文章都写的不错，并顺利发表在ByteTech上。 小F：看你经常在群里长篇大论，会担心大家觉得自己啰嗦吗？ 老Y：被你发现了，不过我认为大部分是有意义的啰嗦，所有发言都希望言之有物，能够给到大家启发。当然，也会面临石沉大海的情况，这是不可避免的，只要认可这件事的意义，认可行为的意义，我觉得就够了，不一定需要得到所有人的认同，要避免这种心态。大家都是成人，可以独立判断信息对自己的价值。 感触颇深的结果 小F：三个月下来，整体的效果怎么样？达到你的预期了吗？ 老Y：整个过程很长，效果体现在三个方面，一是过程，比如大家在1on1中所讨论的内容，话题群中的发言积极参与，以及最后源码剖析的认真对待。二是结果，计划初所设定的理论学习目标基本完成，最后的源码剖析交付质量也不错，全部发表到ByteTech中，其中有两篇还尝试代表团队为ByteTech十月刊投稿。最后，我们还设置了一份问卷，mentor与新人双方互相评价，以及对整个机制的评价都反馈非常正面。当然也不可否认，大家的反馈可能还是会偏向往正面写，但从过程与结果，已经远远达到我的预期了。 另外，我们发现这个机制并不仅仅是提升代码质量，它从更多的角度帮助了新人培养，很多环节所涉及到的能力提升并不仅限代码质量，比如1on1中的沟通，观察mentor如何做需求，源码剖析中的表达等。 小F：这次小灶班花了这么多心思，对你有什么启发吗？ 老Y：是的，过程中有挺多感触的。这个方案几经周折，一直没有达到满意的状态，最后还是与几个同学的1on1中受到启发，才逐步完善。但这里有一个最重要的原则，如果没有它，小灶班不会达到我的预期，这个原则便是「可落地」。最初的代码review规范没能实施就是因为它不好落地，最新的方案也都是围绕着「可落地」的原则一一展开。如果不能落地，不要增加必要的流程，在没有满意的方案时，宁可不做，我认为这个坚持是对的，公司也倡导的是求真务实。 第二个感触：「具体」与「抽象」，我们经常说要「抽象」，层次要更高。但有时「具体」很重要，这次的小灶班中有很多「具体」的环节，比如每周小灶、最终考核。1on1讨论的内容与日常1on1不同，内容很具体，明确了需要沟通什么。当事情「具体」之后，便能做到言之有物，它是可落地的保障。而「抽象」是能够确保能够看到更高的层面，它与「具体」相辅相成。 第三个感触，没有银弹。没有任何一个机制可以简单的解决所有的问题，为了保证效果，我们根据团队的现状，配套设计了理论学习、月会、分享、话题群等，在我们精力的范围内，所有可能帮助到大家提升代码质量的方法，都运用在了这次的机制中。小灶班即使对我们团队有用，也不一定完全适用于其它团队。 最后，也是最大的感触，任何一个最终呈现，大家所看到的可能仅仅是冰山一角，它背后的波折、思考、纠结等都是未展示出来的，但有时又很有意义。所以我计划将我们这次对话记录下来，算是作为小灶班的花絮吧，也许对一些人会有启发。 小F：这是第一期小灶班，后续还有计划继续做吗？ 老Y：这和团队现状有关，目前团队梯队已经比较稳定，新同学较少，所以不会再大规模的组织。但个别的新同学可以与mentor一起，从理论、每周小灶及源码剖析三个方面来选择开展，效果也会不错。 小F：还有什么对参加小灶班的新同学说的吗？ 老Y：最想说的一点是，成长是自己的事情，机制可能会帮助你更好的执行，但效果如何，还是取决于这个过程中的自己。小灶班虽然结束了，但在成长的道路上，它仅仅是一个开始，大家依然可以主动与mentor一起按自己的节奏继续开小灶。 小F：如果团队没有组织这种小灶班，但我想参考小灶班的形式，有什么建议吗？ 老Y：如果你是新同学，可以直接找mentor，其实这里面最重要的机制是三部分，理论学习、每周小灶及源码剖析，其它环节都围绕着这三点，对于理论与源码剖析，新同学可以独立完成，每周小灶可以找mentor帮助。如果你是mentor，希望提升新同学的代码质量，也可以两人一起挑选有用的并尝试这个计划。 小F：非常感谢你的耐心解答，我也打算尝试下这个机制，希望能够解决目前的问题。 老Y：不客气，欢迎随时交流～ 写在最后的唠叨 很喜欢看八九十年代香港电影的片尾，因为片尾中经常会展示电影拍摄过程中的各种花絮，有被忍痛舍弃的镜头，有笑场的NG，有与角色充满反差的演员日常，甚至有时导演会将这些镜头拍成一部纪录片，为观众讲述电影背后的故事。《星际穿越》的导演诺兰特别擅长此道，他的很多电影都有与之配套的高分纪录片，比如《走进「星际穿越」》、《黑暗骑士的完结》等，这些背后的故事让观众能够更好的理解影片，看完后会对电影有很多不同的感受。 工作中经常遇到的流程、决策也类似，最终展示出来的结果只是冰山一角，有时很想了解这些决策背后的思考是什么，为什么如此设计每一个环节，是一时的兴起，还是深思熟虑之后的结果。这，便是本文的初衷，希望讲述有关新人培养的思考，想展示这个简单计划从最初闪现到最终落地的波折，以及想透过它传达出的理念，这篇文章权当代码质量小灶班的花絮了。 至于为什么采用虚构的对话形式？这大概是一时兴起，希望为讲述增加一些趣味，同时用对话更轻松的将各个话题串连起来，读起来大概不至于枯燥吧。 然而，纪录片也许早已注定了它很小的受众，但，对于热爱那部电影，想了解关于电影一切的观众而言，它却是极为珍贵的补充，这也是本文意义的所在。 (全文完) feihu 2024.10.20 于 Shenzhen