友情提示 本文字数为5800 预计需要15-20分钟的阅读时间

可以阅读下面的【提纲】并挑选感兴趣的内容了解细节

欢迎各位掘友在评论区与我交流 感谢你的时间~

写在前面 & 提纲

简单介绍下个人背景：23届校招生 7月份以暑期实习生的身份加入阿里巴巴 并于九月转正

本文旨在总结下这段时间的成长并对不足之处加以反省~

充满曲折的2022已过，在迎来2023的全新成长节奏之前，就让这份略有些迟到的小结，作为实习三部曲的终章，我2022年终总结的最后一块儿拼图吧~

---

在阿里实习了三个月，写过业务、做过技术需求、也犯过一些错误踩过一些坑，本文将从几个角度回顾下这段时间的成长（采取的叙述方式为实习期间做过比较有感触的事儿 + 对应的收获、教训 比如 1.1-【业务需求】移动端webview开发这件事儿就对应着 【代码质量】严谨的代码规约... 等感悟）希望能对大家有所启发——

• 1-改bug、写需求
  • 1.1-【业务需求】移动端webview开发
    • 【代码质量】严谨的代码规约、代码仓库管理规约、Code Review流程
    • 【未来发展】了解前端技术体系
    • 【项目管理】更好地把控开发周期
    • 高度密集任务处理能力
  • 1.2-【技术需求】完善了一个组内用于回溯文档的工具
    • 协同文档的技术原理
    • 了解、改进一个技术型项目的过程
• 2-熟悉部门的核心业务
  • 2.1-了解较为核心的业务、我现在&未来的工作与这些业务的关系
    • 拓宽视野
    • 对未来的自己所处的赛道更清楚
  • 2.2-以一名实习生的角度体验部门产品，发现优点、挑出缺点
    • 了解了调研产品的方式、思路
    • 锻炼了产品思维
• 3-程序员生活的一些碎片
  • 3.1-开发、交付日常
    • 找到记录开发文档与敲代码的平衡
  • 3.2-入职初期 新人如何平稳落地？
    • 和主管、师兄、同事们快乐地沟通、学习
  • 3.3-待人接物
    • 不卑不亢 低调务实
  • 3.4-刺激的转正答辩
    • 在日常工作中提前准备好答辩材料（日常要注意量化好工作量）
    • 如何进行一场高质量的答辩？
      • 详略得当的ppt、答辩话术
      • 提升总结能力！不要反复说车轱辘话！

提纲差不多就是这样，那么 下面来总结下这段时间的收获吧~

第三段实习——大钉钉事业部~

1-改bug、写需求

1.1-【业务需求】移动端webview开发

从【修改缺陷、迭代小需求】（目的：熟悉项目代码、架构）到【参与重要版本迭代】，业务需求占据了我实习的大部分时间，这段时间的开发经历也让我收获颇丰

下面来具体聊聊这些收获👇🏻

• 【代码质量】严谨的代码规约、代码仓库管理规约、Code Review流程
• 【未来发展】了解前端技术体系
• 【项目管理】更好地把控开发周期
• 高度密集任务处理能力

【代码质量相关】代码、仓库管理规约 & CR那些事儿

• 【代码规约】：阿里这边的代码规约貌似和Airbnb那一套是一样的，肝业务的同时别忘了写出优雅的代码哦（当然了 代码写得太丑Code Review也过不了）~

• 【仓库管理规约】：需要注意的是如何有效地在一个大型项目中进行协同开发

  • 我所在的项目组采取的是两周一迭代的方式，一个小模块有时可能会有三四个人一起开发，养成小步提交并及时进行cr的习惯可以避免在封板前还要手忙脚乱地解决冲突、重新做cr
    • 另外把大需求划分成小块进行commit也更方便自己量化产出 答辩时候更好说~
    • 话又说回来了 其实大部分同事还是会选择开发完一个大需求再去做cr、合并入分支hhh 总之把握好一个平衡 保证自己可以按时完成任务就好咯 个人认为打出点提前量也是个解决思路

• 【Code Review】为什么要进行CR？合理、高效的CR流程是怎样的？如果有疑问的话 可以读读这一篇——一文梳理Code Review方法论与实践总结

  • 分享下部门的CR流程：请两名本次迭代相关的同事进行review（我们一般是直接找组内同事看一看代码规范、有没有优化空间、会不会有风险）最后再找一位项目负责人做最后的质量把关 这样“费时费力”做CR的目的上面这篇文章说得很全面——提前发现缺陷、统一规范和风格、进行知识分享，学习同事们优秀的编码思路并了解各个模块的业务细节、达成团队共识...总之 如果cr流程执行得合理 好处就是很多~

【未来发展相关】了解前端技术体系 拓宽个人技术栈

2014年迎来无线时代，移动端逐渐成为业务的主要阵地，前端的技术重点也逐步从PC转向无线

客户端的能力可以给页面带来更大的提升，React Native等跨端框架可以让前端将能力延伸到客户端领域

回顾下我这几段实习经历过的业务——

• 京东实习那段时间做的中后台 无非就是借助组件库实现各种表单 各种列表 复杂一些的场景涉及一些可视化库的使用
• 美团实习时的业务则与搭建平台、低代码平台强相关 主要业务场景是移动端
• 在阿里这段时间同样是聚焦于移动端 借助国际化库实现多语言

这几段实习下来，也让我对前端人未来的职业发展，需要深入挖掘的技术专长有了更多思考——我应该如何塑造作为一名前端的不可替代性？

拿我来说 未来（加入钉钉之后）我的技术栈应该会与webview开发&一些团队产品相关，并在完成这些业务的同时尽可能地拓宽技术广度（了解一切能提升开发效率、质量的技术）——

• 【工具】用于打包、自动化测试等工程化工作的库...
• 【体系化方案】前端监控平台的使用 根据平台反馈数据及时发现问题并找到解决方案...
  • 找到问题并解决的过程需要一定的经验 还是多踩踩坑吧~
• 【性能】可用于提升项目性能的技术 注重加载性能、渲染性能...
  • 如何减少白屏时间？
  • 如何高效渲染海量数据？
  • 如何合理利用缓存？

高度密集任务处理能力

• 同时接手几项任务，如何保证按时完成所有内容？

短时间内写了好多要求严格（且需求变化频率极高！！经常写着写着1.0版本就把需求迭代到新版的2.0版本了。。）的业务 然后自然而然就把处理高度密集任务的效率提上去了

所以 为了少做无用功 写着写着发现需求不太合理 我们应该在开始做之前想好对应需求大致的实现方案并及时与产品、后端、UI沟通好细节

另外 个人觉得高效处理任务的方法论可以按照👇🏻下面这样 按照较为严格的项目管理方式进行思路清晰的开发工作 规定好需求排期 在一个大迭代中留好buffer（缓冲时间）避免耽误整体开发进度！

【项目管理相关】把控开发周期的方法论

• 入职初期经常出现错误评估需求用时的情况另外就像上面提到的一样 碰到过几次写着写着需求就变了的情况

反思了一下 觉得出现这些问题是由于自己项目管理、需求评估能力有所欠缺 遂请教了一位同事，得到了如下的方法论——

• 【1】拆分任务——画脑图；
  • 抽丝剥茧 细化任务
  • 
• 【2】把控风险——使用应用表格-表格视图、甘特图视图记录排期，使用Teambition及时沟通风险；
  • 强推一下使用多维表（的表格视图、甘特图）进行记录排期的操作 个人感觉这个方案不管在协同场景还是在个人场景 都是很高效的！——
  • 
• 【3】开发过程
  • 根据prd与设计稿构思出技术方案并简单记录；
  • 及时与设计、产品、后端进行沟通，避免被动、照本宣科地完成需求，而是在开发过程中不断思考：
    • 这个需要是否应该这么做？
    • 这个需求该怎么做？
  • 不仅仅要开发任务，更是要以owner意识去看待这部分内容、仔细梳理需求的数据链路

1.2-【技术需求】完善了一个组内用于回溯文档的工具

• 协同文档的技术原理
• 了解、改进一个技术型项目的过程

这个技术需求的细则这里就不提及了 主要聊聊这个过程中一些可通用的方法论——

协同文档的技术原理 & 做技术型需求的过程

感兴趣的朋友可以看看下面这个技术分享 其中第一段就是有关于协同文档的原理——

在线Excel表格技术难点讲解

这也是做技术需求的第一步：了解基本原理 那么接下来就是做技术型需求的流程——

• 写好技术方案并让有相关领域经验的同事给把把关
• 确定一下技术需求做出来是否有实际价值 如果价值不大 思考一下应该如何提升其实用性
• 排好期 开始开发~

当然了 我做技术需求的经验还比较少 回溯工具的通用性并不高 后期还需要再了解更多效率提升相关的技术需求~

2-熟悉部门的核心业务

2.1-了解所在部门较为核心的业务、我现在&未来的工作与这些业务的关系

• 拓宽视野
• 对未来的自己所处的赛道更清楚

钉钉，让进步发生~

实习期间 我对自己所在部门主要业务有了一个全面且细致的了解 同时也对公司整体的市场状况有了基本认识 多少是有点命运共同体的感觉hh

当然了 虽然嘴上说着“要接触核心业务 要了解哪块儿业务更核心 领导更看重” 但是 作为互联网研发新人 要先把通用的coding能力、职场软素质锻炼好 在业务上先独当一面再说咯

至于所在赛道钻研的深度 还是需要慢慢来~

2.2-以一名实习生的角度体验部门产品，发现优点、挑出缺点

• 了解了调研产品的方式、思路
• 锻炼了产品思维

• 背景：刚刚加入团队的新人对于钉钉文档产品的心智大多都是一张白纸，这时候看问题的角度比较有参考价值
• 任务：输出一篇文档初体验
• 动作：
  • 一、从不同使用者的角度，阐述对钉钉文档的使用体验；
  • 二、细化到钉钉文档产品的各个模块，谈谈自己对这些产品的第一印象、个人认为的产品优缺点（并提出一些改进建议）

上述过程也是让我接触到了产品的一些工作日常——调研一些友商产品并站在全局的角度上思考产品是否有哪些可以提升的点

整个过程还是很有意思的！尤其是当时提到的一个改进小建议，这两天发现被采纳了 感觉成就感和参与感满满！

回想一下自己三段实习 心态也是有一系列的变化——

• 从刚到京东时的“来啥活儿干啥事儿，闷头写代码”；
• 到美团期间被主管提醒着“多以产品的思维去看问题”，但是依旧有点不明所以；
• 再到钉钉之旅：终于是对产品思维稍微有了一些认知
  • 平时在使用任意一个产品的时候，都会很敏感、主动地去找寻痛点、bug，从而进一步思考应该怎么改，技术方案可能是怎样的？
  • 接需求的时候思考：这个需求的意义，该不该有这个需求？是否应该换种途径、展示方式实现需求？

3-程序员生活的一些碎片

3.1-开发、交付日常

找到记录开发文档与敲代码的平衡

之前提到 我在美团实习那段时间 每个需求都要求严格走完一套流程——拉人开需求分析会并确定排期、写技术文档、开发、自测、交付给测试

在钉钉这段时间 惯性地延续了之前的开发方式 发现 诶 怎么好像时间有点不够用？经过几次紧锣密鼓地需求开发之后得出结论——在大量的业务需求面前 一些流程可以从简

• 比如需求分析会 在需求开发之前 有疑问在小群里沟通好即可 有疑问及时提出来就好 大家时间都很宝贵 再协调时间去开会。。
  • 时间变成碎片之后 大家效率都低 这就没必要了
• 比如技术文档 不一定非要记录下来 自己看一眼需求 心里有个大致的解决方案就好 太复杂的那种需求 可以简单记录一下 也不用特别规范（毕竟组内是没有这个要求的）

3.2-入职初期 新人如何平稳落地？

和主管、师兄、同事们快乐地沟通、学习

很幸运很幸运地又一次碰到了超负责超nice的主管和师兄（之前京东美团同样得益于此 获得了很棒的实习体验）这段时间也是经历了一系列的成长过程👇🏻

• 从最开始被动地在需求评审会上接受任务；
• 到自己开发过程中不断踩坑、慢慢主动向设计、产品、后端同学自信地输出自己的想法；
• 再到养成较好的owner意识，主动去找到问题并与产品沟通后进行处理；✅
• 不断迭代后，获得新的需求记录方式，形成了任务跟进的方法论
  • 接需求 —— 在开工之前想清楚有没有什么坑 与其他模块是否会有冲突 是否有可以复用的地方
  • 跟进需求 ——
    • 合理排期
    • 如果遇到可能出现的风险与问题 要及时与产品 后端 UI沟通，不要踩了坑浪费了时间再去提问
  • 完成需求 ——
    • 自测下是否有bug
    • 小步提交每个模块的代码并注重代码质量 合理拆分commit
    • CR时候做好注释 方便同事看

3.3-待人接物

不卑不亢 低调务实

我这人属于比较人来疯 社交牛逼症那种感觉 另外就是有时候有点咋呼 乐意跟朋友们吹牛x啥的 沉不住气~

这一点吧 说来惭愧 也是因为和同事们一起玩耍的比较多 才能发现自己这方面的问题 在此也是非常感谢主管大大没有放弃我 真诚地给出了一些待人接物方面的建议 现在哥们儿多少是沉稳一些了😄

总结了下 之后待人接物要注意把握一个度 —— 不能太卑微，也不能太高傲；不能太张扬，多低头做事，但也不能一直埋头苦干、不去沟通。——“不卑不亢 低调务实”

3.4-刺激的转正答辩

我算是23届校招生all in转正的一个鲜明例子 所以这段实习期间压力其实还蛮大的 这里分享一些转正答辩的经验 希望能对你有所启发~

当然了 转正答辩与晋升、述职答辩有一些通法 在这个过程中 希望可以一起思考🤔一下

在工作的过程中提前准备好答辩材料

下面这部分内容借鉴了云谦大大知识星球的内容 也有一些自己的感触~

• 就像上面【待人接物】模块提到的一样 不能一直埋头苦干
  • 平时肝需求的时候要留意一些硬指标（比如代码量 组内沉淀的文档量）
    • 可以养成小PR的习惯 合理拆分commit 一个commit做一件事儿~
    • 多沉淀文档 教学相长&扩大自己在公司技术圈里的影响力
  • 要清楚自己所在这条业务线的目标 比如我所处的业务线是DingTalkA 那就不光要忙活好自己手头这点DingTalkA下面的小需求 还要知道DingTalkA这个业务的规划 多和同事、老板聊一下
• 要善用技术达成业务目标
  • 想想我们DingTalkA这条业务线有哪里有可以提升的空间
  • 找出提升点并主动向主管提出自己的想法 一个技术需求也许就诞生了
• 寻找数据支持
  • 上一点的技术需求完成之后是否有数据可以佐证——做这个需求之前如何 做这个需求之后如何
  • 平时可以和运营、产品多聊聊 了解下大老板对于某块业务的重视程度 了解下一些具体的数据 这些都是非常非常有说服力的点
• 我们在DingTalkA这个业务线中扮演着怎样的角色 我们的重要性、不可替代性体现在哪里~

如何进行一场高质量的答辩？

• 详略得当的ppt、答辩话术
• 提升总结能力！不要反复说车轱辘话！

上面这两点我做的就不够好 有的话反复提及 不够有总结性！所以~练习下一句话总结这段实习过程的成长——

通过这段时间的实习，达到了一名前端开发工程师的初步要求：可以规范、按时地完成开发任务，并不断思考、成长。

唔 这个感觉 差不多对了~

写在后面

为阿里 为钉钉打个Call

得益于阿里浓郁的企业氛围和针对实习生制定的一些小活动 这段时间我的实习生活是相当开心的~简单分享下这段时间的快乐实习生活的一些碎片——

• 绝版的EFC职场（阿里云的小伙伴搬去了云谷 唔~）快乐的办公环境（周末去舍友的办公室溜达了一下）👇🏻

• 组织实习生一起看电影的活动（冲鸭！实习生）

• 这个是钉钉组织的看电影活动 占据了一下篮球🏀场 环境惬意得很~

• 作为程序员 身体肯定是第一位！（工区配置了引体向上装置&组织了运动相关的活动）

• 作为一名周边狂魔 来到阿里真的太幸福了~

花里胡哨的办公桌一角👇🏻

展望未来

这段时间的工作学习让我拥有了较为清晰的职业规划——

Not only a Front-End Developer, but also a Software Engineer!

• 短期（工作1-3年以内）

  • 【1】扎实的前端基础能力，作为解决需求的基石
  • 【2】持续提升研发工程师基本功，包括但不限于：
    • 优秀的编码思维
    • 扎实的计算机基础知识-计算机网络、操作系统等、...
  • 【3】多看优秀的代码、工程，阅读优秀的文章 并及时沉淀学到的内容
    • 向具有良好代码素养的同事学习 了解他们的coding方式、思路、对应模块需求 渐渐提升自己对整个项目的熟练度
      • 举例（之前在内网读到的一篇文章中有提到这个点）：我负责的需求可能要写100行代码 但我了解了与这块需求相关的1000行代码 日积月累 就能大大提升对这个项目的熟练程度
      • 最终目的：在某（几）个项目能做到独当一面 能轻松解决绝大多数需求
    • 书读百遍 其义自见✅ 每日学习、输出感悟
  • 【4】对组内项目深入地了解、思考（初步确定下自己的兴趣、组内&部门对于这部分业务的重视程度）

• 长期（上述的短期“业务多面手”任务完成之后）

  • 深耕某一领域
    • 可以从老板的OKR里找一个有思路&感兴趣的点[doge]
    • 可以从组内项目某一个值得注意的点着手
  • 找到自己感兴趣的内容，深挖下去
    • 不断尝试各个方向并与对应领域的优秀前辈聊，慢慢找到感觉

感谢看到最后的你~

最后由衷感谢下实习期间同事们给出的无私帮助 希望大家之后都能前兔似锦~

也感谢读到这里的你 如果有什么想要交流的 欢迎在评论区留言 希望我们的灵感可以碰撞💥出更绚烂的火花~