转正答辩思路

一、做了什么

经历了 10 个迭代，总共涉及了 n 个需求，项目囊括了管理后台、crm、和 share-h5，到后期会开始接触 op 那边的一些项目，比如 op-h5 和 web-pos。在这些需求当中，需要与后端对接的占 xx%，需要与 ui 对稿的占 xx%，其他。从开发难度上来说，我所接触到的任务总体上并不属于特别难的。

二、学到了什么

从参与的这些大大小小的需求中，会遇到很多大大小小的问题。在这些问题中，也反映出了各种大大小小的可以改进或学习的地方。在这个中秋假期，我重新去梳理这些问题，明白自己学到了什么，反省自己可以改进的地方。学到了并不代表我做到了，很多时候这是一个思维层面上的事情，因为经年累月养成的不好习惯，就算理智上意识到了，但也未必能及时有效地能在当下意识并纠正到这个错误。只能尽量不断地去克服，让自己重新养成良好的开发意识。

1. 团队协作的流程 / 熟悉迭代运作的流程，明白业务交互逻辑

根据任务的轻重缓急和预估工时的长短，分门别类对需求进行合理的评估和拆解，结合禅道，制订符合自己开发效率的任务规划表，使得开发具备计划性和条理性。同时，开发过程中，可根据突发状况或预估偏差等对开发任务进行动态调整与修正，不必死板地照着预期的规划走。当和团队其他部门成员共有的需求还不能展开对接时，前端应确认各端工作预估完成的时间，同时根据当前现有的资源，在本地启用灵活的开发策略，使得开发流程能够被有序推进，而不受到中断。例子：当 ui 还未出稿时，可以先去对接后端协议。或者当后端未出协议时，可以先进行切图；当后端协议未完成开发时，动态调整前端的接口数据模拟方案；当后端和 ui 都未准备好时，可以暂不考虑样式，自行构造数据结构模拟，尝试串通完整用例流程，之后再进行相应的调整。

2. 不能把目标单纯放在实现功能上，要更注重代码的可维护性和复用性。

并不是说代码能够运行，开发任务就完成了。粗制滥造的代码会对项目日后的开发与维护埋下不可预知的隐患。应注重代码书写规范，避免产生歧义与混乱；常写注释，方便让之后接手的开发人员能够迅速有效地明白代码作用和逻辑；注重特殊或极端情况发生的可能性，做好兜底处理，常用 try catch 等，保证代码的健壮性，避免出现由于某一行运行出错，而导致整体流程中断和报错的问题。另外，在某一功能的实现上，要常思考可能存在哪几种实现方案。当无法从可维护性和复用性等角度上，确定使用哪种方案更好时，应及时与团队领导成员进行沟通确认，避免日后因选择了不适宜的方案而导致代码需要进行调整甚至重构。例子：在保留页面状态的需求上，对本地存储、keep-alive 和 url 参数传递等方案的选用策略。

不要太想当然。多沟通，多跟其他人一起讨论怎么实现会更好。容易埋坑。

有一个需求是在订单列表页配置了筛选项后跳转到详情页，当从详情页重新返回到列表页时，需要保留这些筛选项的值。

3. 不要一心二用，在特定的时间段就专门做好一件事情

东做一点，西做一点，无法知道自己的准确进度在哪里。

4. 想到就去做，不要延后看似不重要的事情

在开发的过程中，当遇到隶属于该任务下，但相对不太重要的工作时（如样式调整），应在当下及时进行处理，而不要想着先把其他比它更重要的工作都做完后，再抽时间集中对这些看似不重要的问题进行处理。勿因事小而慢为。选择对看似不重要任务的延后处理，一方面可能会因为忙于其他工作后直接忘记处理该工作（哪怕标记了 TODO），另一方面也可能会由于预设了该工作不太重要，而低估了任务实际所需的工时，使得之后回过头来统一进行处理时难以在 DDL 前全然完成，从而造成拖慢团队开发进度，乃至项目出现延期的风险。例子：某一页面存在取消和确认按钮。点击取消按钮应返回到上一页面，点击确认按钮会调用接口进行数据的提交更改。由于取消按钮的点击事件相对来说不太重要，所以对其延后到确认按钮功能联调完成后再处理。结果之后就忘记加了上去，测试也忘记测了，导致上线后需要重新为了这个小问题提一个 hotfix。

前置性

5. 走好测试用例，检查确认流程无误。不要忽略看似不重要的事情

在设计到样式调整和用例测试时，应保持足够的耐心和细心，尽量避免对一些细节的忽视，不要因为麻烦而选择跳过某一步骤的验证。例如，在对稿时，应将元素的所有样式属性一一进行比对，包括像 line-height 等一些平常可能不太重视的属性。通过走完一套完整的验证与核查，尽可能一次性解决掉本不该出现的问题。这样一方面对于之后进行对接的人员（ui、测试等）来说，不必再浪费时间在设计稿或测试用例已清楚说明的地方上；另一方面对前端自身来说，有效减少了之后维护与修复的工作量，避免因存在过多细节问题需要调整，导致项目出现延期的风险。例子：重新梳理禅道上的 bug 发现，如果能够耐心细致地对整个测试用例一一进行测试验证，其中接近三分之一的 bug 本来是能够规避掉的。

三、工作规划

1. 近期（半年）

扎根业务，定期回顾，及时做好技术沉淀、笔记总结与反思，提升开发效率。培养前端知识体系。

尽量避免犯重复性的错误，培养良好的代码习惯。

保持好奇心，在业务之外钻研技术背后的原理，学透用透当前使用的技术。技术栈的迭代或更新，保持好奇心。

2. 中期（一年以上）

拓展自己的知识体系，打牢技术深度和广度。灵活运用技术，能够负责独立模块的实现，并使其具有一定的稳定性和扩展性。

能尽量的规范开发流程就尽量去做，包括代码 review、性能分析、数据埋点分析、异常捕获处理等等，根据业务的实际情况来推进。

思考在相同业务上能否实现代码复用，避免重复的工作量。在不同业务上能否实现基础组件或方法的通用。

不要将三年工作做成一年经验。

学习产品思维，会帮助你从用户的角度审查你开发的产品，找出用户体验不优、交互不好的地方。

3. 长期（两年以上）

关注业内新技术的趋势，与当前业务能否结合，以提升效能。

四、寻求帮助

1. 业务上

联调接口的时候，后端除了部署到测试环境外，希望可以一并部署到开发环境。

2. 规范

制定统一的一套前端规范，比如样式、组件的命名规则。