LastEditTime: 2019-03-31
在一些日常的问题中,start模式几乎是解决问题最简洁和有效的方法了。今天就来详细解析一下这个模式。
STAR
- Situation(分析情景)
- Task(制定任务)
- Action(行动)
- Result(总结结果)
上面是star模式的主要四个步骤关键词。顾名思义,也就知道每一步的主要重心了。接下来展示一个实际场景化应用示例。
3-31日更新
what why how do
觉得star的每个含义记起来不够简洁, 今天刚好在别人的总结里看到了what why how do。
觉得更加的实际,在解决问题和学习的过程中。一个物品或者系统的学习,即它是什么,它为什么产生,它应该怎样使用和解决,它落地后产生的结果如何得到优化。其实这就是人类分析问题和学习概念的基本流程。
实例
假设我要设计实现一个组件。
1. 首先思考组件所使用的场景,以及明确在动态情况下所关联的突发场景。如项目所使用框架,多人开发否,是否为弹框类组件或者全局组件,复杂程度,是否有子组件,父组件,是否组件通信,是否被继承,是否被组合,是否有全局处理,异步处理,开发周期etc。
在进行组件抽出时考虑是否设计该组件为多个场景下使用,组合大于继承,当复杂程度过高时,组件使用成本增高,对后续的修改灵活性也会造成压力,比如iconCool中的一个组件的设计,最后通过使用组件组合的方式来替代了单个组件直出,使得灵活性增高,顺利产出。
2. 其次进行任务布置,即进行组件分析,制定组件主要逻辑编写,关键数据etc。
3. 然后开始编写组件代码,按照任务布置一步步从html,css,js方式丰满组件。
4. 最后进行成果查询,组件是否实现成功,是否有bug,设计过程中有什么不足,针对不足进行修复,对于组件设计过程中每一步的公共部分类抽出,加入组件类的star设计模板中。
公共部分抽出设计:
如第二步,组件主要逻辑编写以及数据模型:
逻辑编写:
数据模型:
- 实际上star中通常是在t步骤中进行设计,即在注释中编写伪代码以及主要逻辑和注意点。
- 实际上不一定每次都会四步全走,熟练使用后经常使用的即12步。34步会跟随进行。
- star法则可用于更丰富的生活,事务方面