【实习三部曲第一章】一名前端实习生在京东的成长小结

5.19更新 commit规范的补充

5.22更新 重新回顾下全文，修补一些细节（看到有很多朋友读了文章，诚惶诚恐~尽自己所能优化文章咯）

这里是一名23届的在校学生，自一月初以前端开发实习生加入京东科技的前端研发组以来，到现在已经是有三个月了，我也结束了这段充实的实习，准备返蓉回到校园，去准备期末考试、实验课之类的事务。

首先感谢组内同事，特别是我的mentor教授给我的知识，感谢他们不厌其烦地带着我完成任务、解决问题。

另外也是回过头来反思了一下：自己是否有帮助到团队解决什么问题？自己是否从这段实习中有所收获？静下心来思考沉淀了一下，希望能让自己有所收获，让大家有所共鸣吧。

本文简单分为以下几部分：

• 在京东学习的“三个阶段”‘

  • 学习规范、读文档阶段
  • 代码质量优化阶段
  • 编码速度提升阶段

• 工作以外的个人学习、成长

  • 代码规范、分支管理规范

• 工作中，通过写业务、写bug（x）得到的一些收获

• 展望未来，之后工作中要避免踩的一些坑

  • 写业务的时候要考虑全面，把自己想象成产品经理，直接面对需求，你写出来的代码，能用麽？有bug麽？最开始不注意自己代码的质量，提测之后会很难受哦~

在京东学习的“三个阶段”‘

学习规范、读文档阶段

用时：两周

• 从学生到程序员的转变，首先把规范定下来，写漂亮优雅的代码；

• 学习分支管理规范，进一步了解git命令，不要提交脏commit，使用git flow工作流；
• 锻炼读文档能力，为后期快速查文档实现需求打下基础。

代码质量优化阶段

用时：一个月

首先感谢下每天帮我review我的 * 山代码的mentor，您辛苦了 orz （希望mentor大大不要逛掘金 要不直接社死现场 QAQ

• 合理地封装组件

  • 减少与业务强相关的变量、方法 通过业务组件的传值解决这部分需求
  • 追求更好的扩展能力、使封装好的组件更加灵活
  • 迭代新需求的时候要不断思考可以把哪些内容封装成通用组件

• 保持代码高内聚、低耦合

  • 逻辑函数之间关联性尽量低、功能尽量集成度高，之后定位错误改bug更方便

• 合理使用Hooks，保证页面不进行无意义的刷新，同时可以保证交互功能（拿状态管理举个例子，不能说你全用了useRef，状态改变之后不进行重新渲染，页面会出问题的~；也不能全用useState，改一个状态就会导致一次重新的渲染，造成无意义的页面刷新不说，还有可能踩到useState异步更新的坑😂）

• 合理使用状态管理方式——第三方状态管理库/Hooks？这要看有多少组件要用到这个状态~尽量不要不加考虑就使用MobX/Redux这类的状态管理库存储状态，根据业务需求，综合考虑用哪种方式存储状态。

编码速度提升阶段

从这个阶段开始，mentor会给我一个页面，让我独立完成并且评估时间，关注点主要在于：

• 能否快速精准地实现业务需求
• 写出的代码是否健壮性强&合理高效

工作以外的个人学习、成长

• 代码规范

  • 虽然平时写业务的时候有ESlint的帮忙，但是代码规范这个基本功肯定还是要具备的，在写一些小demo、完成一道力扣这样的过程中，规范的代码都体现了一名程序员的基本素养~

• 分支管理规范

  • 分支管理 Gitflow工作流文档

    一个功能一个分支，写完了一个功能就提pr 提完pr就删除分支~

    相关文档：my-git/git-workflow-tutorial.md at master · xirong/my-git (github.com)

  • commit命名规范

    • 【22/5/19更新】参考 Git commit message 规范

      • 为啥要更新呢，因为。。最近在提交commit的时候发现有的前缀不太会加了，回过头来看一下～

    • 每天一提交的commit，这个还是要保证基本的规范滴，要不然想追溯之前的版本，就懵逼了XD

    •  # 主要type
       'feat', // 新功能 feature：产品、技术需求、技术优化等功能开发
       'fix', // 一个错误修复
       
       # 特殊type
       'docs', // 仅文档更改
       'style', // 不影响代码含义的更改（空白，格式，缺少分号等）
       'build', // 构造工具的或者外部依赖的改动，例如webpack，npm
       'refactor', // 重构代码
       'revert', // 执行git revert(回退版本)打印的message（之前我进行版本回滚的时候就很不规范，导致commit记录很乱）
       
       # 暂不使用type
       'test', // 添加缺失的测试或更正现有的测试
       'perf', // 改进性能的代码更改
       'ci', // 与CI（持续集成服务）有关的改动
       'chore', // 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
       ​
       // eg: 'feat: 添加了图表功能'
       // 工作日常的commit肯定比不上开源仓库中的规范，以直观为第一目的～
      

  • 不要在代码仓库中使用强制回滚的命令~

    • 有一次为了修改一个脏commit，强制回滚了我这个分支的线上版本，结果触发了警告，给咱吓坏了😢

工作中得到的一些收获

• 一套完整的完成项目流程

  • 与多个方向的同学一起合作完成一个板块的开发
  • 原型评审-mock数据进行页面开发-前后端联调-提测-修改缺陷-正式上线

• 合理封装组件

• 写出健壮性更强、更优雅的代码

• 另外就是上面三个阶段中的收获啦，主要其实就是更快更好地完成业务需求并与后端、产品、测试高效合理地沟通

展望未来，之后工作中要避免踩的一些坑

写这篇总结的一个原因是为了回顾下自己上段实习的收获，而更重要的一个原因是为了从上段三个月的实习中找出自己存在的问题并争取不要在下次实习再犯，这里也简单列出来吧——

• 好多时候工作效率不够高，总喜欢写会儿业务耍会儿手机

  • 解决方案：工作时远离手机，并碎片化地分割任务计时完成，做到心里有数地高效完成任务。

• 总是想当然地编码，好多时候与实际需求相悖，或者存在明显的bug，经常把mentor气笑 😶‍🌫️

  • 解决方案：理解了产品需求之后，构思好页面如何实现，再去写代码。

• 如果有一个卡住自己很久的bug不知道怎么修，困扰了自己很久的需求不知道怎么写，要及时问下mentor，避免无意义的时间浪费。

  • 当然了，问问题之前要先查阅文档，看看是否有很显而易见的解决方案~

写在最后

再次感谢京东科技我所在的前端研发组的各位有爱的小伙伴，这真的是个超级棒的团队鸭！疯狂打call，大家有缘再见啦！