-
面对较大且重复的选择项的时候，应该着重分析其中一个选项，忽略其他，构建完整的流程----比如分析圈选sdk的时候，忽略其他未圈选情况以及，忽略hover情况完全以click情况进行分析。
-
最小实践原则先完成后完美，有的优化方案，如果确实是比较难，就先放下，优先去跑通整个流程，优先跑通整个流程。
-
对于较为庞杂的系统，分析是，砍掉所有与当前目标模块无关的。
-
感性思维和理性思维要兼顾一下，程序需要进行调试，不要只看
-
不清楚的还是要，回归文档进行查询，工具有些细节点很多，需要结合文档去回归。
-
对于官方的实例，不要全信，要自己独立去思考，它为什么这么做
-
对于不清楚的原则，可以通过数学方法定性描述.
-
对于一些旧有事物，如果自己写的时间，小于直接去修改，那么选择直接自己写，并且要写的更加的简洁清楚。
-
对于一些上手较难的东西，工具产品，思考怎么降低入门门槛是一个很好的方向和思考。
-
化归思想，看到一段话，学会把这个转化为自己熟悉的语言。
-
做的东西如果没有价值，不能解决用户的需求，那就没有什么意义。
-
同样的错不要再犯了，因为下一次的代价可能只会越来越大。
-
分析问题不要多线程，一次就总结一个。
-
对于需要花费大时间的方案，但是实际效果并没有我的投入多，那么直接舍弃，如果一个事情，完成预计大概。
-
之后用的方案，要理解它的底层逻辑，否则一味的采取，复用，听别人的方案只会导致后面给自己埋坑，不同的应用，不同时期，方案也要与时俱进。
-
之后要多和各个领域非常顶尖的人去学习，不断的优化自己的思维，提升自己的认知和执行力。
-
凡是以后某个细节很短几分钟内能做的，立刻去做，不要去拖。
-
用户体验：从公司的性能优化以及各种琐碎的交互设计，都完全是从用户的角度去出发的。
-
以后对于自己不足和认知行为错误，除了要看表像，更要去理解背后的深层次原因，很多可能是认知和理念差异造成的误解，比如react和vue之间的同一数据更新，但是模式完全不一样。
-
重视反馈和迭代，这个是我进化的底层逻辑之一
-
选择合适的方法，工具，什么样的场合，领域，要用符合这个特点，因地制宜，没有完全完美适应的工具和方法（组件使用有感）
-
思考问题以终为始，可以屏蔽一些无用的细节。
-
要按照价值来排序，，不要在一些无用的细节上，浪费太多的时间，做事前进行优先级排序。
-
做事出发点除了满足想做，能做，可以做 ，还要关注底层核心逻辑，不要因为一些非核心，不长久的
-
切入新领域，要有数据分析思维，结合实际市场需要进行开拓
-
抓住变动点，不变的进行保留复用---复用思维--标记-jscodeshift。
-
逆向思考，当我一个正向处理的问题，比如需要手动操作，能不能逆转思考，反向自动化操作，而且一定要抓本质的逆转，因为比如这个唯一di，本质是唯一，而不是纠结于什么属性，因为属性会重复，有点像 react18 里面的uid, 不以击破本质问题为目标，将来还是要偿还对等的代价。--记于--data-consider-id--用jscodeshift 反写源码
-
敏捷迭代,快速验证：初步的方案落地，以及各大厂的内部赛马，机制，personal career ，初期都是，选定一个方向，快速落地，验证，千川诞生也是如此，初期过多的纠结，include facebook small practice and get feedback and promve daily ,wexin also
-
变更修改原则，提前拉通当前拍板相关人员，做之前多沟通，确立好几个方案，然后确定某个，如果修改要基于一些原则，
-
避免返工原则对于一些需要做的事情，提前拆解好，按照优先级，以及紧急程度来进行排序，同时在做需求，前一开始拉通对齐，避免相互信息不互通以及误解，效果做到中途，要及时验收，避免后期大量返工，对于一些中等及以上的改动，发信息，或者发邮件
-
弱者不值得追随--跟随弱者是在浪费自己的生命。
-
黄金圈：对待需求思考应该是先思考为什么，是什么，最后一步才是怎么做，这个也是苹果的一个思考：
-
当同样的方法一种条件可行，另一种不可行，捷径就是研究那个可行的方式为什么可以。
-
临场发挥，如何更好：1. 刻意练习，拆解需要讲解内容，多个时间段内，重复多次自己演习讲述，不借助任何资料，同时心态上，预期放低，假设以自己不过的前提，能更平静的去准备资料，进行讲解，同时前期资料的准备，最好问问相关人员，寻求反馈，至少要改三版，要多方视角，去审视你的资料。
-
精益求精：同类竞品，同花顺之类，单单从访问页面速度这点，其实是比较慢的，口碑和体验差距，就是一点点，遇到难点，多做一点，每个产品都多积累一些优势，积少成多，最终才能在同类竞品中，厮杀出来。
-
拆解，纵向拆解，还可以多角度横向挖一下，形成网状思考--记于日历组件按周滑动需求。
-
代码一行，一行度，步骤一步，一步来的耐心培养--记于日历旧组件代码理解。
-
对于一些含糊不清的需求，最多可以接受去调研一下。不紧急的直接拒绝 --- 业务组件库背景。
-
如果遇到真的怎么都难以解决的问题--原则：不要死磕--分阶段，结合具体困难点汇报，上级一定要知道这个问题客观的复杂性和风险，最忌讳的是闷声，到最后截至，合作方，上级才知道问题，如果最后还不行，尽力即可，不要自己闷头死磕，做好，确实做不出来的准备。
-
琐碎，临时需求：协调好实现，优先给一个可用版本，后续迭代，往后拖，不要影响主体目标和成长。
工作层面
- 会占用较多时间，优先向上汇报，因为其它人有自己工作，无义务帮忙，小的可以适当寻求协助。
- 遇到非常不确定的内容，申请或者自行调整优先确保自己能做的，大部分可做工作，提前做好，做精，不确定的，不要投入过长时间，或者说，划分到每天一部分，不要天天在那看--记于日历组件开发
