已曩昔

2022 年现已来到十月,还剩 3 个月数字就要跳到 2023。从事前端职业现已 4 年多，知道和了解这个职业后，仍然保持喜爱和热心。但在生活和学习过程中未免会发生一些焦虑感。

7月份时分换了份作业，为什么换作业呢？说来在上家公司呆了差不多三年时刻，触摸过后台办理项目、移动端、小程序、Node项目。离开原因总结下来主要原因有几点:

1.公司事务简略，重复度高。
2.可以依据自己的喜好做一些相关的基建项目，但是短少标准，有时分感觉在单兵作战。
3.对前端了解和认知比较浅，实践项目中也短少场景，短少”有挑战性”的项目。

挑战

现在入职的团队规模翻倍和处理的事务场景杂乱度提高不少。总结下来现在遇到的挑战有如下:

1.技能栈转化, 从 Vue 改为 React 及其相关的生态。
2.事务场景杂乱且影响面关系杂乱，对项目不了解、对事务不了解，导致开发过程中功率低、简单改错东西。
3.多人协作，随着团队规模变大，共同开发时分难免搭档之间会相互修正到互相的代码，需求处理抵触防止，简单发生副作用。

试用期遇到的问题

起先会有一个练手的 Demo 项目给新人做，主要是给新人了解下 React 相关技能栈，代码提交规范以及一些环境依靠的配置的了解和运用。(个人感觉这个时刻可以缩短，早些触摸实践项目)。

到了真正接手公司项目，由于此刻对公司产品不了解，以及开发过程中对功用的影响面不清楚。在需求评审完感觉作业量不是很大。实践开发过程中，和后续改 Bug 中发现这个和难度是直线上升。

来说说我遇到的问题点吧

  1. 最直接的感触是事务不了解，pd 说的很多点都不知道入口在哪，所以造成修正时只看到自己做的当地，不知道影响面有哪些。
  2. 其次是技能栈不了解，React、RTK 及相关技能，包含公司内部有些自己的库和东西。开端有种一堆道具扔给你，你却没时刻看说明书的感觉。
  3. 项目杂乱，事务杂乱，在看项目时分只看到冰山一角，还未形成全体的结构和头绪。开发过程中功率低，处理方案不够通用，修正时造成多处副作用(改了 A 影响了 B)。
  4. 不了解 immutable 的更新方法，在 Vuex 中都是直接通过直接操作 state 来修正 store 数据，在 redux 中引入 immutable 更新的方法，包含在公司项目的开发过程中都要选用该方法。带来的优点如下:
    • 方便调试，因为未来的操作不会影响之前创建的目标，所以行为变得可猜测。
    • 下降 mutable 带来的杂乱度
  5. 还有一点我觉得挺要害的，以前开发不需求你十分懂事务，大概了解下功用做什么的即可，属于完结任务型开发。但是现在会觉得你得了解事务场景，这些功用点的全体运用，毕竟你还有事务群解答问题，以及你可以跟产品去 battle 到底这个功用要不要做。

处理方案

针对上面遇到的问题点现在有如下处理方案。

  1. 项目代码杂乱，依据具体模块测验画出对应模块的代码执行的流程图，模块及配置项之间的关系图。了解项目全体头绪。
    • 了解顶层抽象的通用逻辑。
    • Debug 承认 hooks的执行顺序和影响点。
  2. 了解产品运用文档，了解产品功用点，以及功用点实践处理问题点，可以站在产品和用户的视点考虑功用的实用性。
    • 学习了解 sql 语法，了解事务操作对应后端的 sql 具体做了啥。
  3. 加强 immutable 的开发方法练习，学习 lodash/fp 的运用，可以更好的写出 immutable 的代码。

规划

虽然在新公司呆了两个多月，但是感触也是跌宕起伏，从开端以为简略的换个技能栈应该问题不大，到触摸实践项目的压力倍增有些喘不过气，调整心态对项目和产品有了开端的认知后重新开端继续奋战。
考虑自己短期之内的规划方向有以下几个方面:

  1. 加紧完结产品的常用的运用场景的了解。
  2. 项目区块梳理和自己担任模块的代码深化了解。
  3. 有规划的做一些自己的项目，和开端有规则的输出一些自己学习和成长过程中的沉积和感悟。