Stay教你如何学习Android

在接触一门语言之前,应该做的准备

Stay教你如何学习Android
2053人加入学习
(14人评价)
价格 免费

stay的开发流程很具体,从 产品需求到设计、编码、测试、还有维护,很好的方法论,最后还有自己的代码库,很棒的项目思路和沉淀。

[展开全文]

如何工作:

分析-调研-设计-架构-拆分实现

[展开全文]

写代码前要先做以下事情

需求分析

结构设计 分析要建哪个类哪些属性

TODO串联 把上面的属性和类串联起来同 

TODO实现

测试

优化扩展

 

[展开全文]

App完整流程

分析-原型-UI/UE-设计-架构-测试-构建-QA-运营

按官方规范引导UI设计

 what:这个问题是什么?

 when:什么情况下发生

 why:为什么会这样发生

 how:如何解决 

[展开全文]

WHW

WHAT:能做哪些事?

HOW:采用的什么方式实现?

WHY:为什么有这样的需求还有没有更好的方式?

[展开全文]

搜索-复制粘贴-debug-实现-debug(low)

分析-搜索-借鉴-适配-实现(现在的我应该做到的)

分析-调研-设计-架构-拆分实现(架构师)

 

高效工作流:

产品效益最大化

反复敲定与建模

产品预研与拆分

方案确定与任务分配

业务大于UI

面向接口编程

耐心填坑与沟通

[展开全文]


你是如何工作的?

1.工作初期:

产品--》需求

开发--》google

开发---》developer(debug)

cann't  fit

debug

代码实现

交予产品审核(不满意)

重新debug

 

 

2.工作有一定经验

产品--》give 需求

开发--》 anasylse 分析需求,需求点在哪里

开发--》search搜所关于这些需求点,借鉴别人的以实现的相关功能技术点

开发--》 将这些代码适配到自己的应用中来

 

3.架构设计阶段

提升竞争力

产品--》give需求

开发--》 analysyse分析需求,你可能已经分析出这个需求可能会用到那些技术点,然后有针对性的去调研学习

 

 

分析modul,设计分层,解耦,抽象化设计(封装,抽象,多态)

 

架构,拆分实现,将调研到的东西分开实现

 

测试稳定性

 

工作方式决定了你的工作效率,决定了你的竞争力!

 

[展开全文]

what 

how

why


需求,少有创新,找到原型,矩形,试图理解背后的原理。再考虑技术实现

 

设计原型,团队协作,动手,编码,测试,解决问题,记忆索引

[展开全文]

写代码前该做什么:

1.需求分析(做好确认工作)

2.结构设计(如何解耦,设计模式,继承多态等一系列东西)

3.todo串联

4.todo实现

5.优化扩展

 

[展开全文]

分析问题

一个问题出现,必然有它的原因,场景,触发条件。想要解决问题,首先需要冷静分析。

WHAT WHEN HOW WHY

这个问题是什么?它在什么场景下发生?上下文是什么?它是如何被触发的?为什么会发生?

 

问机器,你要尽可能简单,并且自己做好分词。最好不要搜索句子,别放标点,语气词,助动词这些无意义的字。并且每个词之间加上空格来手动分词,避免被错误分词的可能。

 

国内现在有很多好的技术分享站,从个人代表(郭霖鸿洋大头鬼胡凯等)到优秀技术文章协同收录站(掘金干货集中营codeKKAndroidWeekly等) 有时候甚至都不需要google,有问题直接就在这些网站就能找到高质量的知识分享。经常浏览上面的文章,扩展自己的眼界,找自己感兴趣的知识来补充。是非常省时间的事。

 

要注意的是,如果只mark,不实践。那它只是一个知识节点,没有与你的知识体系交织到一起,很快你就会遗忘它。别信自己会先收藏再消化的鬼话。

 

google,stackoverflow,github

 

如果是搜demo或lib,eoe, csdn算是个选择,不过大多数也是从github上翻下来的,如果你想实时更新,尽可能还是英文的好。把lib的包名在github搜下就出来了。

 

别一上来就想着搜个源码直接用,也不要一开始就去画UI。Stay一般是这样规划的:

  1. 先想清楚产品到底要一个什么样的功能,这个功能对产品来说是否真的那么重要,有没有什么更能放大这个效应的做法。
  2. 与产品讨论,理解他们通过APP想表达的诉求,将它们转化成真正的需求,并画出流程图与产品反复确认。
  3. 需求理解好了,可以先拆分调研相关技术点。先不要急着去表达这个功能实现不了,这个效果要花时间。不妨客观的分析下(反正都要实现,为什么不把它做的好一点呢)
  4. 有个大抵的了解之后,团队在一起讨论下,采用什么具体实现,谁来实现。(务必让每个人都对代码有整体上的认识,不要各自维护自己的小模块,不利于成长,也不利于团队)
  5. UI一般都要比业务逻辑改动的频繁,所以最好不要急着画UI,只要有一个大致的UI框架就可以了。先把业务逻辑完善(网络交互,cache,点击事件,跳转)如果有盈余,可以写unit test来测试C层或者P层逻辑的正确性。没问题了再写UI实现。
  6. 剩下的具体实现呢,如果没有现成的代码可以用,可以再拆分成几个task。先自己将tasks通过workflow串在一起,不管是流程图,还是TODO伪代码都行。再针对每个task来搜对应的解决方案。
  7. 所有技术问题不可能是无解,只要耐心,肯定能找到解决方案。别怕麻烦,别图省事,碰到的每一个问题都是你进步的阶梯。如果真不能解决,那就换个折中的解决方案嘛,沟通灰常重要的!
[展开全文]

debug步骤:

1.what-是什么bug

2.when-在什么情况下会出现

3.why-为什么会这样

4.how-怎样解决

[展开全文]

学习语言的最佳方式

一个面向对象的程序(oop)实际上就是一个相对去中心化的、模块式的程序。

模块应该是单一的、高内聚的,模块之间应该是低耦合的。

模仿api设计,编码规范

封装

what how why

[展开全文]

授课教师

前台

课程特色

视频(4)
图文(1)