用式样让你完整实现机能
目录
感悟
领导语录:
- 直接写code是最简单的事情了,因为已经明确了怎么做、做成什么样、需要和谁交互等等
- 真正好的程序员一定对于产品有着清晰的认识以及自己的想法,不是说程序员就一定是天天code,也不是说做产品有多么多么的不好,在完成功能过程中,对产品的合理以及不合理进行及时反思QA,这样才是自己level的提升
- 大家都在说30岁转产品转产品,你30岁之前做过那么多项目,你自己有产品思维吗,或者说你从产品经理的角度想过吗?好比程序你要找一份java的工作,你都要把基本的java语法学习了并且做几个java项目。那你想转项目经理、转产品经理这不是一个道理么
- 年轻人有想法是好的,不能头脑一热提出一个不切实际的想法,要自己做过 调查、反思,然后才可以进行疑问点提出
用式样让你完整实现机能
-
公司中,我们每个人肯定负责的都是一块业务,而针对这一块业务不可能是你想怎么做就怎么做,这就需要一个标准,大家都遵守这个标准来实现产品,那无论对于 程序员还是项目经理在于沟通以及实现上都是事半功倍的。可能你是新人什么事情都可以问带你的人或者你的一层上级,但是实际上这些人也不是制定标准的人。你问你的领导,你的领导问领导,肯定有一个类似于 “书”的标准!!
-
式样书出现了,含义就是满足机能要求明确的需要达成的事项的集合
通俗一点就是说明书
-
式样是客户、产品经理、开发人员的共同认知。在每个阶段按照明确的式样做正确的事情,那结果就是好产品
1. 要求式样书
-
通常由客户提出,大致写了应该实现什么功能,很简略,通常只对正常流程处理
比如:要有设置预设电台的功能
-
当要求式样书不明,可以选择参考已有的BaseModule然后进行和客户QA
2. 机能式样书
- 基于要求式样书做成,从机能的角度把机能细分,包含所有应该实现的机能
- 通常开发人员直接看的就是 机能式样书,我们实装的内容也要和机能式样书一致
- 当式样书不明,及时和前辈沟通
3. 操作式样书
- 基于要求式样书做成,从画面实装角度将每个画面和动作细分
- UI开发人员必须详细阅读,东西很对很杂
- 当和机能式样书冲突,必须及时QA
4. 流程式样书
- 有点类似 机能 + 操作,针对于每个case的流程,进行制作,包括每个case出现时候的条件以及画面显示,用流程的方式展现
- 如果你想熟悉一个项目,具体机能流程,看这个是很好的选择
5. 基本设计式样书
-
在机能明确的情况下,根据式样书,和关联组进行充分检讨,包括时序、接口等
-
改式样书由开发测进行制作,对于设计侧应该充分考虑和关联组的交互;对于关联组,确定是否满足设计侧的需求。两方需要对最终式样书进行一起确认
-
这个时候还不到代码设计阶段,仅仅针对于和外界交互,这里
-
一般包括 具体机能、Block Component图、Class 图、Sequence图、UseCase图。一般UseCase和Sequence进行结合比较好
-
比如公司中可能你负责一个 机能,但是机能的实现需要通过和其他模块的交互来完成
这也就是基本设计需要的事情,确定如何和其他模块进行交互,画出时序图,制定好关键类以及接口的形式
6. 详细设计式样书
- 根据这个式样书可以进行代码的 coding了,设计到机能内部的代码设计
- 画出所有重要Class 图、Sequence图、UseCase图,因为这个图就代表了你的代码了,在 Class你需要设计你的class族,耦合关系等等,怎么创建模块,需要几个模块
7. 单体测试式样书
- 写程序一般都会有条件出发某个场景,有的时候可能我们在自己测试的时候存在漏case的可能,单体测试就是为了保证程序的每一条case都走到
- 工具有很多 gtest、Junit等
- 这里说一下,现在单体测试有一种不可取的形式,就是单纯针对函数里面几个判断,不断使用反射进行参数转换,来实现case覆盖率,但是这样就违背了我们 保证每一个程序case走到,我们应该按照机能的角度来进行单体测试
8. 结合测试式样书
- 负责的模块coding结束,那么针对于 几个明显 case进行简单测试,这里的case需要将关联模块交互都涉及到,确保联动没问题
9. 机能测试式样书
- 没错就像机能式样书那样,针对于机能式样书 + 程序,每一条case、每一个机能、包括不同判断条件,进行一一编写,并测试
10. 总结
通过式样书看流程,自顶向下。不仅让我们体会到一个产品如何做成,还因为针对这种在什么阶段明确做什么事情的准则,让机能正确
一个圆,圆内是你会的,圆外是你不知道的。而当圆越大,你知道的越多,不知道的也越多了