一、自己需要培养一种整体把控项目的能力
关于数据结构
- 哪些是一开始就要和后端定好的？为什么一开始就要定好？之后定不行吗？
- 无论是否需要和后端定好数据结构。一开始自己都应该更具业务需求定好数据结构。
现在是怎么做的？
想一个大概，然后需要一个数据结构了，就又添加。
期待自己怎么做？
尽可能地在一开始就想全面，然后定好完整的数据结构，万一有遗漏了，有需要添加的时候再添加。
这样做的好处！
①整体数据结构不会来回的变化（比如原先是数组，突然改成key-value格式了，那么前端对应的方法可能都要变）。②在构造需要提交数据结构的变化时，假设有多个分支的情况，每个分支的数据结构构造都类似。可能就会更改好多地方，可能会在在好多类似的地方都要添加相同的字段。实际上这在一开始如果想的周全是可以尽量避免的。数据结构的设计，前期准备要做充足。充分从业务层面去考虑你所建构的数据需要哪些字段。
封装组件
- 封装陌生组件。对于陌生的组件，你是如何划分(拆分)它的功能的？哪些需要抽象成一个方法?哪些需要向外抛出来,一开始都应该有一个规划。
自己欠缺在对其功能的了解模糊不清。很多时候设计的图稿未必是最终标准，前端会有自己的想法在里面，然后更改之后可能就会导致没有设计图，自己瞎想。所以我给自己的忠告是，组件要实现什么功能，预先在脑子里写好然后落实到笔头上。然后根据这些功能再继续拆分细化这样就会好的多。组件形态不清落实到草图上，组件功能不清落实到笔头上。 - 封装的组件具有关联性，一开始需不需要考虑相互的关联性问题？？？？比如一个是轮播，一个是时间轴。轮播有一个preBtn和nextBtn但是一开始就应该留好接口，比如跳转到第几页。而我的思考过程仅仅是完成这个轮播，当时根本没有考虑把时间轴联想过来，后来才开始遇到问题：点击事件轴进行切换，我需要轮播提供什么方法。
关键点就在这里了。虽然当时 时间轴的形态没有确定，但作为一个对象，他们之间的联系实际上是确定的，双方彼此需要提供的方法实际上已经既定了，这个是不需要形态直接就可以调用双方的。 梳理一下，就是
点击preBtn和nextBtn,轮播自身切换。时间轴切换。
点击时间轴。时间轴切换，轮播切换（当时未考虑，这就是轮播组件应该向外提供的方法，一开始就应该加以考虑）。
所以，我姑且把这算一种无形态的两个组件间的交流。现在应该打破思维定式，不是它有了形态，我才设计它的方法。而是只要它是一个组件了，就可以当做完整的一个对象来考虑了。一定要有联系思维！其他组件需要我提供什么，我需要为自己提供什么？
我发现自己必须把轮播好好写一遍。自己对于轮播的思路太过凌乱了。并不清楚哪些是需要抽象成一个方法的？
二、培养自己的抗干扰能力和专注能力
三、培养与人沟通和了解别人需求的能力
常规方式四步走：
1.了解别人需求（想实现什么？）这一步也很重要，而我经常跳过这步。下次应该去深入了解一下这步。这步是相当于把自己做到了产品经理的角度。看对方想实现的功能到底是什么。
2.实现过程中遇到什么问题？ 代码实现逻辑不清晰问题，代码不知道该怎么实现（功能如何转换为代码形态），api不熟练问题，帮助新同学定位好问题在哪里。
3.重复别人的疑惑，以确认问题所在。一开始并不知道对方的需求是什么。这个确认是加深自己印象，让自己更加了解问题的一个步骤（对于初次辅导别人我觉得这一步骤非常有用。）
4.阅读别人代码，逐步沟通确认，解决问题。
按对方需求的方式
对方寻求的是解决问题的思路？还是报错解决不了？还是具体的代码实现？说不清楚的，就可以直接以代码的实现的角度来给对方讲解。如果能直接说清楚，就提供一个解决问题的思路。
而且我发现我的步骤应该是先解决问题，再讲解问题。不要一边讲解一边解决问题。现在我还没有达到那个水平。一开始先降低对自己的标准，先给对方解决了问题再说。
