出自一个前端小菜鸟的感慨，共勉

出自一个前端小菜鸟的感慨，共勉
初入社会，我只是一个前端路上飞行的菜鸟，经过一段时间的工作之后，才知道，我踩了无数的坑。。。希望，看过我写的文章的同胞们，不要再和我犯同样的错误。（纯属个人思考）

1. 当负责项目中一个模块的开发时，不要忘记，它只是项目中的一个模块。

当我拿到项目经理安排好的工作计划书时，开始对自己负责的部分的需求进行熟悉，这时的我选择按照需求文档进行开发了。没错，这正是我开始接触项目时的表现，完全没有意识到，它只是项目中的一个模块，等到后来开发完成后，才发现自己负责的模块其实与其他模块一环扣一环，相互有着不同的影响，于是，开始了改bug的漫长之路…

后来才慢慢意识到，系统系统，环环相扣才叫一个系统，我们不能只熟悉自己负责的模块的业务流程，应该着眼于项目的大局，熟悉整个项目的核心流程，数据的来源与去向，系统权限控制带来的影响等等。

2. 问问题之前首先自己思考、查阅，不要轻易问需求

不懂就问，这是好的，没错。但是，不懂就盲目的问，这就有问题了，如果对一项业务的流程或者页面展现方式不够清楚，你会选择怎么做？曾经，当我遇到这个问题的时候，我在简单的思考之后选择了去问产品需求，希望得到确切的答案。这样做感觉上是没错的，但实际上，我忽略了一个问题，包罗万象的网络。后来，我才意识到，我应该先认真分析需求，分析业务路程，思考过后，如果不懂，再上网去查一查，不到最后，不要轻易问需求。

3. 反思页面功能如此实现的原因，尽量优化显示

一个系统，或是一个网站，我们都应该记住：页面才能直观的体现一切！！！ 不管后台怎么运作，不管数据如何流转，与用户交互的，永远是页面。所以，我们不能只照搬需求上的页面布局，数据显示方式，也应该思考思考，需求为何要这样显示，这样显示好处在哪里，有没有更好的显示方式，只有在思考之后，不断优化显示，才能写好页面，给用户一个好的体验度。

4. 改bug时，注意bug的牵连性，避免跷跷板现象

我不知道其他人在刚进入工作的时候，有没有遇到过这种现象，改完一个bug，发现这个bug修改后，导致另外一个bug的出现，这种bug的跷跷板现象，我遇到了。后来，我的处理方式是，改完这个页面的其中一个bug， 随即对整个页面进行一次全面的测试，以此来避免这些现象。或者，很多人会有更好的处理方式，但对于还属于菜鸟的我来说，这是我最简单粗暴的处理方式 了。

5. 注意提交测试页面前首先自己反复测试，无误后提交测试(前端)。

我参与的项目，都是由前端来进行功能集成，然后提交测试的。在这个过程中，要小心了，之前说过了，页面才能直观体现一切，所以，测试测出bug，一般情况下，都是会归于页面问题，前端人员就会有很多的bug了。也许不同的公司会有不同的处理方式，但我遇到的便是这样。在经过一段时间的工作之后，我深刻意识到，在将页面提交测试之前，一定要反复测试页面是否有bug,数据展现、页面交互、样式规范，包括服务器端造成的页面问题等，都需要谨慎小心的处理，等到再三确认页面功能完全正确了，再提交测试。这样，会大大减少bug数量，因为自己也进行了详细的测试，出了问题能够及时解决，不管是前端还是后端，都会减少很多bug的压力。

以上就是我的个人感悟，不多也不深，仅仅是踩过坑之后的一些想法。觉得有问题我们可以一起讨论，也可以不用在意，看过就忘了也好。一个菜鸟的感想。

出自一个前端小菜鸟的感慨，共勉