从四月入职阿里，到现在不知不觉到现在即将跨入8月，短暂的实习经历也将结束，这段实习经历中，我独立支持过一个项目，也协助参与过几个项目的前端开发。在这段经历即将收尾之际，总结了些收获与思考，愿与各位共享。
（下文提到的“口碑力”指我主要负责项目的代号）
前端在开发中需要有主动性、需要熟悉业务
其实在我以往的前端开发过程中基本都是被动的接需求，设计师出图或者是产品经理出了原型图再和后端对好接口规范后就进行开发了。但口碑力项目的开发却是很不同的，从最开始的项目评审、排期到每周的周会我都有参加，会议上也不只有PD、或者业务方发言，后端、算法包括前端同学都可以提出自己对项目的建议。而从离用户最近的前端开发的角度出发，我们其实可以提出很多优化用户体验以及交互逻辑的建议，就比如我在口碑力中提出了很多图表修改、以及交互动作的修改建议都有被采纳。我我觉相比于之前单纯的切图还原，具有主动性不仅是能更好的提升业务价值，另一方面也能提高自身的竞争力。
合理设计代码结构是对日后维护很重要
在口碑力项目中其实有很多这样的场景，一个路由页面下有很多个图表需要渲染，多数图表都有一个单独的接口去请求数据，一开始我做的所有接口和数据处理都放在路由主页面内处理，图表组件编写为呆组件，仅用来展示数据。但后来发现这样的组织结构并不好，排查某个图表问题的时候很难快速在一堆逻辑代码中找到其对应代码，后来我将大多数互相关联性不强的逻辑代码和他们对应视图代码进行归类拆分为一个个具有内部独立逻辑的组件。尽可能以高内聚低耦合的模式去编写代码，事实证明在后续定位bug、尤其是进行逻辑修改的时候都有很大的帮助。
拥抱变化而不是抱怨变化
之前在其他公司实习的时候经常遇到的事情就是来自产品经理突然改需求，“小余呀，你看这个功能这样做是不是更好，这个按钮这样，再这样..这样”后端同学也时不时发来消息“xx接口数据格式改一下，xx接口路径要修改”。在没来阿里之前我认为这样“神奇”的操作在大公司里因该会没有吧，但事实是这样的事情依然存在。我也和师兄们讨论过这个问题，我个人一开始认为这种经常对的修改真的是很不合理的，多次的修改对开发人员也是一种折磨，相信大家都不喜欢自己写好的代码还没发挥作用就要面临被删除的命运。但经过和师兄的探讨我对此有了不一样的认识，首先就是其实所有人都想把事情做好，也都想一开始就把所有事情能确定下来。但事实是，对于任何新项目来说，很多东西都是不确定的，业务方的新需求、市场的变化....如果让我去做产品经理其实不一定做的有他们做的好。同时由于最核心的业务模型天然在后端，所以一般来说，都是我们前端尽可能的去配合后端同学。因此，我们应该做的是尽可能的去适应变化，而不是抱怨。
我也在寻求在前端开发中是否有更好的方式去更快的迎接变化，降低试错成本。就比如我之前谈到的合理的代码组织结构，就能减少在进行变更的时候所需要的更改的代码。最近也在尝试在项目中使用一种MVC模式的编码方式（www.tangshuang.net/7777.html）并探索在前端开发中使用DDD模式开发的可能性（khalilstemmler.com/articles/ty…）
培养多样技能的成长
培养自己多样技能的成长也是我这段实习经历中除了技术思维转变以外成长最大的地方。我们是一个技术人没错，技术是我们每个人的立身之本，但是在工作中我们又不是单纯与代码打交道：
-
我们有PD，需要向他们了解需求的整体交互
-
我们有业务，需要全面了解需求的背景
-
技术团队内部，我们需要相互之间沟通进度，交流技术方案、设计方案
-
技术团队外部，我们需要对相互之间的交互方式，上下游进度不理想如何去推动
-
出了问题，我们需要知道对外应当怎么说，对内应该怎么做
-
有一个想法，应当如何以正确的方式去落地，而不是我有一个想法直接说也不说、讨论也不讨论干就完事了，
凡此种种，都需要经历和成长，曾经我也以为程序员只要把代码写好就好了，来了这里，才深刻地感觉到写代码真的只是工作的一部分而已。
我相信无论你在50个人的小公司还是在5000个人的大公司，身处3个人的技术团队还是30个人的技术团队，没有一个人是单兵作战的，这个行业对技术人的要求从单纯的技术要求已经越来越往综合素质去靠，所以，关注对自己多样技能的培养，相信无论对当下还是对未来，百利而无一害。
个人职业发展
我也曾经很多前端的同学一样，时常会觉得焦虑，甚至喊出学不动了。但后来这篇文章（juejin.cn/post/696567…）给了我很大的帮助，这位作者也是阿里的前辈哈哈，最早在内网看到这篇文，后来发现他在掘金和公众号也有发。
文中讲到的这段话真的非常让人赞同呀！
我们在工作中通过踩坑甚至把一个项目做失败得出的经验，可能只是设计模式这本书里提到的一个常见误区；我们在设计一个非常复杂的系统时，用到的模块通信设计，可能只是操作系统设计里的一种常见通信方法。一个能理解操作系统复杂度的人，基本上可以处理与其等价复杂度的软件工程问题，而软件工程的复杂度其实很难超越操作系统，所以与其在项目里试错，不如从这些基础知识里找答案。
现在感觉确实不那么焦虑了，有空学学基础知识、设计模式什么的，再钻研数据可视化的方向。