金沙棋牌官方平台

当前位置:金沙棋牌 > 金沙棋牌官方平台 > App的成长历程,我所理解的前端

App的成长历程,我所理解的前端

来源:http://www.logblo.com 作者:金沙棋牌 时间:2019-11-21 10:14

我所理解的前端

2018/03/21 · 前端职场 · 1 评论 · 前端

原文出处: 李文杨   

入坑前端到今天也将近两年半了,这两天突然想到了第一次面试时面试官的一个问题——-你怎样理解前端的工作?

对于当时我一个小白而言完全是胡说一通,词不达意,搞得面试官一脸懵逼,现在想想那可能就叫尬聊吧……时隔两年在不断爬坑中对这个问题有了自己新的认识,今天趁着上午没什么事情,写下这篇博客,想到哪写到哪,谈一谈我所理解的前端。

金沙棋牌官方平台,技术方面:

第一阶段(新手村)

一个前端初学者必须所掌握的核心技能HTML,CSS,JavaScript,这三项是前端最底层的技术支持了,如果你看几年前的回答应该还会有一项jquery,但我个人觉得现阶段的前端圈jquery可以不作为必备技能,虽然Jquery对新人很友好,但现在mvvm框架满天飞Vue, Angular,React三分天下,用起来要比直接操作dom的jquery舒服很多,当然在这个阶段是打基础的阶段框架,类库什么的可以往后靠。原生Js永远都是重中之重,只会用框架不懂底层原理永远达不到精通,推荐红宝书Javascript高级程序设计,吃透红宝书打牢基础再去学习其他框架,妈妈就再也不用担心你的学习。接下来还有一项额外的技能PhotoShop,要知道ps可以不用去做,但必须要会,而且在一些小公司里UI只会丢给你一个PSD,没有什么Sketch之类的东西,也没人帮你切图,这些都需要你自己来处理,所以ps是额外的必备技能。

第二阶段(副本开启)

进入告诉成长阶段,开始打怪升级,这个阶段的时间持续最长,在这期间你需要爬无数的坑,积累各种失败的经验,一关一关的往下刷,关于HTML和CSS你需要知道各种UI框架的使用,如BootStrap,ElementUI……,关于不同图片的格式标准,浏览器的兼容性,移动和pc端的区别,响应式布局,flex布局,栅格布局,对设计审美的提升…等关于提高你页面开发效率的各种技能,UI框架这一块比较杂选自己感兴趣的看看就好。

Js方面这时候已经可以开始挑一种主流框架进行学习了,前面提到的Vue, Angular,React都是不错的选择, 并且对面向对象编程,对象封装,原型继承,闭包,同步异步差异,等一系列的js进阶知识应该进行深入了解,同时对es6标准也需要了解,可以参考阮一峰老师的es6入门,书中包含了es6的各种新特性,默认参数,模版表达式,多行字符串,拆包表达式,改进的对象表达式,箭头函数 =&>,Promise,块级作用域的let和const,class类,模块化等常用特性.可以做到自己封装组件,编写维护性高,可读性强的代码. 而且在平时需要多看别人写的代码,汲取别人的优点,并且阅读大量的技术文献,最重要的是要总结自己的问题,比如说你遇到一个bug,迷迷糊糊的就解决了,下一次你又遇到相同的问题,这个时候有没有对之前问题进行总结的效果就看出来了.

第三阶段及更高级

了解各种设计模式,看得懂各种框架源码,前后端通吃,可以自己手写js框架…好吧,我还没到这个阶段就不写了…………..

在工作中

一个完整的的工作流程应该是:

立项–项目研讨–需求确认—-产品出原型—-后台开发同时设计师拿到原型进行UI设计–前端开始开发–测试提bug–改bug–重复n次–产品验收

上面只是一套笼统的流程,至少在前端这方面我们需要做的有梳理业务逻辑并理解业务逻辑,这对你后面的开发很有用处,同时根据需求进行应用技术的选择,项目结构的划分,需求模块的划分,完整项目的搭建,当然现在有很多可以自动化构建工具可以节省你很多时间, 现在的前端开发已经不再仅仅只是静态网页的开发了,日新月异的前端技术已经让前端代码的逻辑和交互效果越来越复杂,更加的不易于管理,模块化开发和预处理框架把项目分成若干个小模块,增加了最后发布的困难,没有一个统一的标准,让前端的项目结构千奇百怪。前端自动化构建在整个项目开发中越来越重要,但新手入门还是应该去尝试自己一点一点的去构建一个项目,等你多做几个项目觉得每次都这样重复好烦,自然而然的就入了自动化构建的坑,毕竟这样能让你更深刻的理解,为什么要使用自动化构建……比如我们主栈是vue,我们最常用的就是vue-cli,自动化工具有很多选择如Bower、Gulp、Grunt、node、yeoman,我们应该根据需求选择最适合自己的去研究。

沟通

前端是团队里最应该学会沟通的人,界面有问题需要和UI沟通,数据有问题需要和后台沟通,功能有问题需要和产品沟通,测试的时候给你提bug你还需要和测试沟通……emmm心累

沟通ui

前端是最接近用户的人,用户对一个网站,软件最直观的感受是反映到前端的,可能你会说最直观的不应该是UI设计师么,你要知道我是前端我为设计师代言!!!

和UI的沟通,在工作中我们不应该是被动的实现UI的设计,而是应该合理化的提出自己的想法,不然日后返工浪费的是双方的时间,比如最开始刚来公司的时候,项目里对一些小图标的图片还在使用雪碧图,但很明显随着浏览器的支持越来越好,svg和字体图标慢慢占据主流,我在阿里巴巴图标库建了一个项目把UI也拉了进来,UI把他用到的图标直接添加进项目,前端直接从项目生成字体图标引入到项目,绝逼要比自己慢慢切图,扣图标,合并雪碧图要省事的多,而且用起来也特别爽,想改颜色就改颜色。再比如你需要做一个图表,用到了echarts,你完全可以让UI基于echarts去设计样式,而不是让他在那里自由发挥,因为你永远不知道设计师的脑子里装了多少创意,这样节省的是两个人的时间,不会出现他做好样式而你实现不了的尴尬。

沟通产品

一般来说程序员和产品经理之间是最难沟通的,只有相杀没有相爱,毕竟子曾经曰过:’这个需求很简单,怎么实现我不管,明天上线!’,

下面引用lensuntop的一篇文章,我觉得写的非常好

记得有一个段子:

产品汪:程序猿,我们来实现一个紧急需求?

程序猿:请说。

产品汪:请根据手机壳的颜色,来实现APP启动的颜色。

程序猿已经在风中凌乱。。。

从这个段子中多少能折射出产品和技术之间的各种激情“火花”。产品经理眼中简单的需求,而在我们看来是不可能实现的。而程序员也无法理解产品经理为什么要实现这样的需求。那么,站在一个程序员的角度应该怎么样和产品经理沟通呢?

1.深刻理解需求,清楚需求的动机和缘由

我们程序员一定会在问,产品经理为什么想要根据手机壳的颜色来动态实现APP启动时的颜色。既然想听解析,那就先别急着说出自己的结论——技术上无法实现!既然有疑问,那就先将自己的疑问解决。

2.换位思考

产品有产品的角度。作为程序员我们追求的是什么?逻辑正确,更快,更容易扩展。产品追求的是什么?说实话,我自己没有深刻去思考过这个问题。站在一个惯性的角度思考可以想到:一个产品为什么存在,他的存在能解决什么问题,他的用户体验好不好。这些才是决定一个产品的核心价值。毕竟工作性质影响了一个人的思维逻辑,所以这时候,我们能站在一个产品的角度去思考每一个需求,便显得尤其重要。

3.不放过每一个细节

作为程序员想必对这句话都是深深认同的。因为一个标点符号或者类型的错误,会导致一个自己意想不到的bug。产品经理在设计一个产品的时候,都是从大方向去想问题的,大方向没有错就行了,细节脱离不了大方向。这是他们想的。但是对于程序来说,却万万不能。因为一个细节的逻辑往往决定了整个大方向。举个例子:有一个需求,用户的作品需要提交审核,经过审核才可以让所有人看到。当产品经理交这个需求给你的时候,你能察觉到什么问题了吗?这里面有几个细节:1.用户提交审核后,用户可以不可以再编辑作品;2.作品是否会多次审核;3.需不需要记录审核历史;4.用户作品是否需要有版本的控制,如要产生版本,版本又是如何产生的;5.审核通过后,用户可以不可以再修改作品,若不可以,那么是不是其他人就看不见用户作品……话说回来这只是一个简单的逻辑需求!但是涉及的细节却是太多太多。我们往往在编码的时候写不下去,就是因为给的需求太模糊,没有细化到点上。

4.换一种方式说“不能实现”

不能实现,这句话想必我们都是经常说。但是直接对产品经理说,没准会让产品经理抓狂。因为我们会让他们觉得他们提出的任何需求,我们都不能实现。但是事实并非如此,因为不能实现是有条件的,比如时间不够。所以我们要先认同产品经理的观点(“能实现”),再提出自己实现他的需求的条件是什么。因为现实产品经理也不会经常犯傻,经常提出一些不合理的需求,但是面对需求,我们需要评估实现的时间,而且这个时间不是那么容易评估准确的。

5.当遇到不合理的需求时,积极寻求替换方案

就拿段子里面的需求来说,让我们提供几种APP皮肤给用户进行选择,肯定比原先的需求容易实现,而且也更加符合人性化。说另外一个故事,有家智能家居的公司,要实现厨房水龙头,根据人声说水温几度,就可以达到几度。换个角度想,你会感觉出40度和45度水的温差吗?而且根据人声判断,这又涉及到声音识别系统,你要兼容多少种语言?其实我就觉得左右切换就挺智能的,完全没有必要搞的那么复杂。所以程序员要找到一种更好更容易实现的方法。别给产品经理的想当然自乱阵脚。

6.必须遵循文档精神

在开发的时候,我们往往会另外与产品经理进行细节化的讨论。但是这种讨论结果,我们并没有记录到产品原型里面或者需求列表里面。但是过了几个月后,我们自己往往会忘记我们当初为什么会讨论出这样或者那样的一个细节。所以一切的需求必须是根据的。从另一方面来说,也保障了双方的利益,别等到出问题的时候,不知道是谁的责任,而在这一方面,程序员往往很吃亏。

6.对自己的程序有一颗艺术的心

有人说过,当需求影响到代码扩展性的时候,会首先砍需求,而不是改代码!在一定程度上,我是认同这句话的。在我看来,程序是一件思想上的作品,要达到艺术的境界,从功能、体验和逻辑上都必须是合情合理的。就像一件艺术品一样,看起来是浑然天成的!因为一件看起来很“丑陋”作品,一定是不符合人的逻辑和习惯的。

写到最后,感觉绕回到程序员自身了。其实跟产品经理沟通,最重要的是要明白到:我们是在解决问题,而不是在制造问题!主要抱着这个核心,一切问题迎刃而解

一般来说和后台沟通没那么多的麻烦,约定好规则后,一般来说你们是通过api来沟通的,但当你调试接口时,出现一些未知的,你感觉不是自己问题的时候,及时的沟通后台是最明智的。

责任划分

相信大家在这一点上都深有感触,因为前端是最后一关,所有的需求都是在前端手里变成一个具体的产品的,这样也就导致你很容易变成背锅侠,导致项目延期的情况有很多种,设计图不及时,后台数据出现问题,产品临时改需求,如果你不能证明是这些问题导致项目延期,这个锅你必背无疑,唯一的方法就是–à口头确认–à发email到责任人确认–à通知上级,千万不要觉得这个麻烦,出问题的时候会比这个更麻烦的,

写不动了,以上就是个人爬坑后对前端的一些理解(ps:虽然我还在坑里),也算对自己工作的一个总结吧,写的比较絮叨,不喜勿喷,最后祝大家2018升职加薪,找到女朋友!!!

我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:

1 赞 收藏 1 评论

金沙棋牌官方平台 1

app开发

角色

PM(策划)→交互→视觉→开发→测试(QA)

策划阶段

我们需要形成一份策划案,通常由我们的投资方或者说管理层对产品或者说项目进行拍板,之后PM需要对产品或者项目进行分析,策划以及评估,形成书面的文档,通常或者一份pdf格式的文档或者是一份word文档,之后我们开一个会议,将和项目相关的人员全部请来,就这一份产品或者是这个项目进行评审,评审之后我们要开始着手去启动项目,相关人员需要做准备,负责交互模型的人员需要根据PM的策划案或者项目启动书去准备APP的交互稿,通常就是我们所说的产品原型图,当然有时原型图也是PM需要做的,当然UE或者UX这部分设计关键还是要关注到用户体验,有的企业会有独立的人去做,大部分企业的这部分工作是PM兼职完成的,这和一家企业对开发的分工有关。

UI

我们的UI当然要尝试去提出自己的视觉方案了

测试

准备基础用例

后端

准备和开发人员协商数据格式和数据内容,为书写接口文档而准备

开发

关键是技术预研,对于关键性的技术或者说三方SDK进行调试和研究

交互阶段

通常我个人是会用Axure去设计App的原型,当然有的人可能会觉着用Justinmind设计App的原因会更加专业,我通常会用MockingBot去设计App的产品原型,关键是这个软件能够帮我节约时间,能够直接导出一个原型的apk,还有就是能够提供常用的素材,节省我去网上找素材的时间,在这个阶段交互人员需要拿出一份交互稿,当然可能是一个url地址,需要描述清楚所有的交互需求,交互流程以及交互特效,搭建一个产品或者说App的基础模型出来,此时不需要太过注重控件的美感,只需要描述清楚控件所具备的交互功能就可以了,也就是搭建一个App的功能骨架,当然不仅仅是原型的设计,还有就相关的流程附上流程图,相关的思路附上思维导图,还有相关的互动逻辑最好也能用图形展示出来,尽量不要使用过多的文字去描述,这样能够更加直观,更容易被被人所理解,当然我们和项目相关的人员进行沟通才是最重要的,我们总说产品开发中最大的成本就是信息的不对称,PM在整个产品或者说项目的开发中必须保证每一个环节,每一个相关人员之间信息的对称性,这种对称性不仅仅是指发一个文档给每一个人告知一下项目的进度,而是要保证每一个相关人员的项目理解保持相对的一致性,这样才能保障团队协作的效率,避免浪费太多时间在沟通还未到位的工作上,当然可能一个配合默契的团队不需要做太多的沟通工作,我们设定的是一个刚组建的开发团队,对于有必要和其它人沟通或者解释一下的交互设计我们有必要和相关人员进行讨论,而不是直接交上去一份交互设计稿就完事了,这样可能会给后期的开发工作带来不便。

完稿之后的评审

评审的主要内容:

1.这个交互稿是否符合我们的策划需求

2.UI将自己设定的视觉方案进行嵌套,确定一下是否适应,以及确定其它相关的设计事宜

3.根据交互稿书写我们的用例

4.前后端开始搭建框架了,前后端接口协议确定,模块划分和分工

5.实现困难的交互方式和技术预研

6.当然作为一个项目经理或者说程序员当然也要关注项目的开发周期,我们需要根据交互设计稿去预设产品的开发周期,当然对于不可控的开发模块进行风险监控,假设不能明确一个开发时间,这个项目就不能做了。

视觉阶段

通俗地来讲就是我们在开发中经常使用的效果图,不同于交互稿的时视觉稿最终决定了产品的模样,而交互稿只能决定我们的产品轮廓,对于我们的程序员而言当然需要在理解和搭建产品轮廓的基础上去填充我们的视觉效果,这部分的工作主要是由我们的UI完成,UI这个工作在实际开发中不是一步到位的,准确地来讲应该是一款App产品在实际的开发中不可能一次定稿,可能会有调整和变动,可能还会有频繁的需求变动,这是我们程序不太情愿发生的事情,这就需要考验一个PM的能力和需求方的意愿了,UI完成设计稿之后通常也要进行一次视觉评审(我们也可以理解为小组会议),之所以要进行评审主要是就一部分细节达成一致性的意见,毕竟是不同的人在做事,每一个人关注点的和所做的事情不同,比方说Android开发中对dp和px单位的转换,当然现在我们可以直接使用px,程序员可以引入一个依赖包解决这个问题,当然这也要UI与我们的开发人员协商好,对于UI来讲可能需要设计交互特效中一部分素材文档,针对特效实现所需要的素材也需要再交互稿在评审时和交互设计人员以及相关人员沟通好,实现方式不同可能对于素材的要求也不同,所以UI可能会被各种切图需求所包围,所以在确定视觉稿之前还是要提前做一点沟通上的工作,要相关人员明确设计需求,确定视觉设计稿之后可能也要喊上大家一起进行评审,策划首先要认可视觉设计稿,假设需要修改,就要马上修改,之后对比一下交互稿,评定一下UI素材能够支撑起全部的交互效果,效果图可能还需要让我们的移动开发人员进行一下评定,开发人员对于效果不太明白的地方可以及时沟通一下。

UI和视觉设计

其实UI就是企业中的切图人员,只要基础素材足够,一个UI人员的效率是极高的,无非是切出不同尺寸,不同风格以及不同分辨率的组图,对于我们这种移动开发人员来讲,现在转换工具太多,我们基本上能够完成大部分图片的转换工作,对于UI来讲Adobe企业的产产品至少要精通PS,当然AI和AE能够精通也是极好的,其它的辅助插件此处就不讲了,还有矢量图的操作软件比方说CoreDraw软件,也被一部分人经常使用,我们通常不说UI是设计师,而说UI就是个切图的人,原因是我们的UI所做的大部分工作就是对素材进行各种拼接,修改和特效上的制作,而不是真正地进行原创性的绘图工作,其实这对于UI来讲也是一道坎,过这道坎必须有着好的美术功底,就如同我们程序员想要进行数据结构的设计和优化就必须有着算法功底,这对于我们程序员来讲也一道坎,其实我觉着UI更多需要承担App的设计工作,比方说配色方案,以及品牌设计,以及对app的主题进行设计,可能在日常的工作中UI会去做这方面的事情,可是企业却未能有重视这方面的工作,这让UI的地位下降了好多。

开发,测试阶段

其实前面我们一直忘了说,我们需要一套集成的项目开发系统,当然好多企业用了禅道的项目管理系统,当然我们也有好多其它的选择,对于我们开发人员来讲我们还需要关注到代码仓库的问题,通常我们也会将其托管到github上,有实力的企业也可以托管到自己的服务器上,我们通常会使用git进行版本管理,svn可能已经过时了,当然对于有的企业来讲也是一个选择之一,对于我而言我认为开发需要分模块,模块之间需要解耦,让分模块之前需要统一网络框架,代码规范以及工具类,当然在分模块时我们必须注意模块之间的解耦,不能建立太强的耦合性,否则两个模块之间的代码可能会造成太多的冲突,这是我们进行模块合并时经常会碰到的问题,也是最令人头疼的事情,所以在分模块时,我们就要重视这个问题,避免在之后的代码合并中造成重大的损失,老手应该规避这方面的问题,特别是开发团队中存在太多新手时,初版的app只要按照产品原型和效果图去做就可以了,对于我们而言我们不过是用原生的代码去重构一个在不同系统中运行的产品模型,开发中我们需要将代码上传给我们的测试进行测试,测试根据之前建立的测试用例对我们的代码进行测试,当然有的测试也会手动进行测试,所以说测试基本上和开发是同步进行的,开发写出来的代码和功能必须要经过测试的检验才行,这时我们也需要一个bug管理软件,当然在项目管理软件也会有这种功能,可是有的bug管理软件更加专业,用于测试将测试出来的bug提交给我们的开发人员进行修复,对bug进行描述和记录,开发人员其实对于效果图可能还会跟UI进行沟通,也会针对bug和测试有所沟通,当然实际开发过程中我们和测试沟通的机会基本为零,我开发和PM交流的次数可能会更多,PM是出策划的人,必须监督开发人员严格按照自己的策划去开发App,当然还会改需求,这对于开发人员来讲十分可怕。

关于后端

此时后端当然要拿出接口文档给我们前端的开发人员了,否则我们前端的开发人员是无法进行开发的,假设碰到了这种情况,我们需要将此事和领导说明一下,否则领导还以为你一直在拖时间,一定要汇报上去,曾经有个同事就被后端人员拖了好长的时间,结果这个项目最后流产了,老板也将后端的人员全部开除了。

关于测试

一个不能给App测试出bug的测试不是一个好测试,当然这不是绝对的,可是假设你未能测试出bug,App上线出了一个简单的bug,你这无疑是引火上身,所以测试通常要细心,所以就适合我们的女孩去做这项工作,现在有好多自动化测试的工具,而不用我们写太多的测试用例了,当然手动写的用例还是必须的,这也许能够帮助我们测试出业务逻辑上的漏洞,对于App而言我们可能还需要进行手动的点击测试,Android中的monkey测试还是不太靠谱的,在不同的设备上进行测试,对控件的效果,大小,样式以及互动功能进行各种变态的测试,当然资深的测试还会对网络访问的安全进行测试,特别是特别是涉及隐私的用户数据和用户行为相关的数据,还有就是网络框架本身的安全隐患。

关于我

一个Android开发工程师,励志成为一个不写代码的程序员,有时一杯咖啡,一次沟通能够给你的是一种方向,而有时仅仅是重复性地工作,我不太关注自媒体,尽管在互联网企业和这部分的人有所接触,可是猿天然地抗拒运营们油嘴滑舌的姿态,有时也只能被金钱(企业文化)所驱使,还请我们要尊重马斯洛的需求理论,作为一个程序员,任何一个角落,任何一杯咖啡,全部能成为我们设计程序的地点,关键在于我们的思维能够跟上别人的需求设定。

上线阶段

可以说上线我们必然要和公司的推广和运营打交道了,千万不要自以为是地去上线我们的App,这根本不是开发人员的事情,运营狗做的事情是不同的,比方说你能设计各种各样的衣服,可是卖动这件衣服的套路不是我们设计师能够掌控的,推广中涉及关键词的搜索,以及各种各样的推广手段,针对不同渠道的推广方案,当然对于iOS开发工程师来讲此时所需要做的事情只是等待苹果官方的审核,对于我们Android可能是打包各种渠道包,或者是通过Gradle打包各种变种包,总之一个打包工程师已经上线,当然我们可能会进行最为重要的一次测试,就是上线测试,我们可能也会用一下蒲公英内测服务,如何用大批量的手机进行App测试,可能就要花点钱了,我们的后台能够收集到App崩溃的日志,不要以为上线我们的工作就做完了,产品出来之后,我们要面对企业中各个部门的评价,也要面对上线之后用户和推广人员的反馈,对,迭代更新的重任来了,修复简易bug不影响用户体验可能还会用到热修复的技术,迭代更新不过是重复上述的流程,不再赘述。

声明

有时间可以加一下我的微信,仅限于技术沟通。

二维码

本文由金沙棋牌发布于金沙棋牌官方平台,转载请注明出处:App的成长历程,我所理解的前端

关键词:

上一篇:没有了

下一篇:没有了