博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
平时用到的比较好的工作流程总结
阅读量:2352 次
发布时间:2019-05-10

本文共 4004 字,大约阅读时间需要 13 分钟。

背景

平时工作中,自己不仅要有技术意识,也要有自我项目管理意识。

要注意不断梳理总结出好的软件开发方面流程规范制度。这些要比工作所用到的核心技术要重要多了。好的流程规范,就像好的土壤,土壤好了,才能培育出好的产品花朵。

平时用到的流程总结

部署性能优化方案方面的流程

首先:设计性能测试case,明确性能优化的具体实施目标和场景。

这一步应该放在首要位置的,性能优化工作的重心在于挖掘并展示性能优化数据,比如提升性能具体多少。这些比较依赖于自己设计的测试case和测试工具,还有更重要的是自己发掘的具体性能优化场景。

这个是性能优化工作的特色之处,毕竟不像解稳定性bug或者做功能开发那样,数据表现展示并不是刚需的。

所以做性能优化方案之前,必须得知道自己的性能优化目标场景在哪里,预期会有多大的性能提升收益,有无比较稳定的测试方法可以帮助提炼性能优化数据。

第二步:编码并设计性能优化方案。

写到这一步,还想说的是性能优化工作其实并不像稳定性工作一样,会局限并专注于某个技术层面的工作,比如专注于内核。

做一个性能优化方案,需要对自己所处的行业内产品业务场景比较熟悉,知道手机哪方面的使用场景最需要进行性能优化。同时技术层面,不仅仅要会内核,而且fwk也要会点。

因为fwk离业务层很近,产生价值更快更直接。

所以一个好的性能优化方案部署成功,需要一个从fwk层到底层内核都熟悉的人存在。

第三步:进行性能测试验证和优化效果数据展示

这个是性能优化工作的成果展示阶段。需要自己不断完善自己的性能测试case和脚本工具,去在千变万化,多种多样的用户手机使用场景中,找到其中一个契合自己优化方案的场景,并做有效的测试验证和性能数据挖掘工作。

这一步可能碰到的困难点:比如性能数据有波动,这是正常的,因为性能问题通常都会受手机中各种因素的干扰影响。所以需要你去做比如固定cpu频率,存储芯片频率,还有其他排除数据波动的工作。

第四步:做进一步的代码review和稳定性测试验证

前面3步做完了,恭喜一下,性能优化方案有成果了。但是还要下来做进一步的代码review工作和稳定性测试验证,以免性能优化方案进版后,会有负作用出现。

第五步:进版后,需要及时关注用户反馈数据。

这一步也是相当重要的,有时候性能优化方案比如涉及到对内核的改动,很难在本地全部发掘到其完整的作用表现,有可能不排除进版后还会有一些负作用表现。

所以复杂的优化方案,需要通过mqs挖掘用户端的反馈数据表现。没时间做那么复杂时,也要在进版之前,就要想到怎么在用户端有效地挖掘出其作用数据表现(积极的 and 负面的)。

具体方法有:

1 比如可以在同平台的,一个机型上部署该方案,另外一个机型上不部署,然后对比性能优化效果表现。

2 可以事先做一些性能打点log, 去收集该方案在用户端的perf data表现如何。

产品版本控制方面的流程

一 开发版与稳定版区别:

产品版本通常分开发版和稳定版。开发版的为了追求开发效率,很多机型共线的都用一个打包分支开发。稳定版保守起见,为了质量考虑,通常一个机型或者一个平台一个独立的打包分支。

开发版每周都会出新版本,推送到用户那边。稳定版通常每隔几个月,会出一个用户版本。产品的用户群体多了,还区分内测和公测。内测会有用户主动申请做版本体验测试,公测就是推给该产品的所有用户去使用了。

二 需要注意的:

1:开发版changes进版后,按照流程,呆够几天后,没有质量问题后,要及时同步到稳定版上,避免稳定版用户再报同样的问题。

2:稳定版进版changes是有比开发版更严格的进版流程的。通常稳定版会尽量严格限制进changes数目, 毕竟以稳定为主,确保版本质量。

稳定版进版需要做的进版补充说明如下:

------------------------

1):进版必要性说明​

​这个change是在XXX急性上加入XXX功能的,该功能是今年做的重要优化功能,主要解决XXX,我们尽可能的支持该功能。
另外在稳定版之前已经合入该功能的情况下,作为共线的产品打开这个功能的支持具有工作量小,风险小,收益高的特点。
2):测试重点
已经带changes编译打包,在XXX稳定版上​进行了XXX功能测试和MTBF稳定性测试,均已通过。
打包链接和详细的测试结果见下面邮件。
3):发版策略
XXX开发版已经进过碎片整理功能changes, 当时测试验证过已没问题。
需要进的当前changes也是开发版的changes merge过来的。​计划下一个稳定版带入该changes.

--------------------------

3:准备进版的changes,通常自己先做初步测试效果验证。然后发给其他开发者做review +1工作,然后发给测试,做verfiy +1工作,然后下来都成功后,再发给主管做review +2, 主管通过后,就可以合入版本了。

代码review规范见另一篇wiki:。

职场利益合作伙伴有效沟通方面的流程

沟通在不同环境下有不同的表现方式,首要的,职场利益合作伙伴之间的沟通肯定有区别于私人朋友间的。

职场利益合作伙伴之间的沟通特点表现在:

1:或者双方彼此都不熟悉,都是初次见面,自己有求于对方。

2:或者双方虽然是合作同事,但是彼此生活和工作习惯有大的差异,朋友圈子没有交集,但是为了商业合作利益,不得不在一起工作。

职场利益合作伙伴之间沟通需要注意的:

1:首先要主动探查和搞清楚对方的需求。

彼此都不熟悉,甚至双方行业背景差异都比较大的人在一起沟通交流。举个例子,比如面试求职场景中,自己肯定有求于对方,这时最高效地沟通方法是自己不要先急于表现自己,要主动通过提一些问题,比如询问对方招聘职位工作内容
和最需要招哪方面人等,这样一方面熟悉了对方的行业和公司做事业务方面的背景,最重要的是搞清楚了对方的实际招人心里需求。只能先成功了解清楚需求了,才能对症下药,更好地展示自己。
今后怎么办:
探求对方思路和底牌,除了要听懂对方的表达之外,自己也要主动探究对方的真实背景情况,特别要给出一些有高价值,高优先级的问题询问。
比如求职面试时,要明白自己应该高优先级来询问对方公司什么问题。小公司,首先问的是对方的商业盈利模式,是做体制内项目,还是体制外项目,盈利模式如何,而不是首先问什么技术和开发氛围如何。

2:不能被对方的思路所控制和左右。

尤其是你被一个贵人面试时,自己要记住,可能贵人通常面试时间都是很宝贵的,另外人家很有可能出于对你不了解,所以对你并不重视,或者面你比较随意感性化。这个时候,要记住自己一定要珍惜这个宝贵机会时间,要自己提前整理出
一套比较好的思路和流程,不能被对方随意和无意识的考察所耽误。否则,对对方通常没伤害,不行他还可以面下一个。但是对自己,却是失去了一个宝贵的机会。

3:沟通时要语言简洁,说话思路有条理性。

一个是要语言简洁,最主要原因是通常贵人们的时间都很宝贵的,没人愿意耐心坐下来好好考察你。这个时候,自己如果语言简洁的话,就可以一方面对方能更快地听懂你要表达的意思,减少误会沟通,一方面语言简洁了,自己也顺便能多问对方很多问题,或者能多表达一些自己优点,让对方更信任自己。
今后怎么办:
要明白工作中最有价值的,最能出成效的方法思路,往往都有一个特点:简单简洁容易明白。干活不能凭激情加班卖力,得聪明灵活起来,懂得如何用更少的成本完成更大成果的事情,而不是要琢磨那些什么高深内核技术,非得干出什么大事业。

另外一个是表达思路要有条理性。就是注意表达思路要清晰。因为贵人们知道无论是工作还是干其他的,都要从小事做起。如果你连基本的表达思路都不清晰没条理的话,纵然你说你自己多么刻苦加班工作,自己私下研究了多么高深内核技术,对方只会嫣然一笑,婉约拒绝。理由只有一个:你本末倒置了。

从另外一方面也验证这个注意点的无比正确性。国内it工作没没有处于全球产业链的高端,80%的工种就是以杂活,比较浅的技术为主。所以大环境下,什么是最需要掌握的对自己最有利的技术,往往是一些我们都忽略的那些小事。
今后怎么办:
1) 还是上面的,要聪明的干活,注重劳逸结合,会合理地休息,高效的产出。不要光凭什么激情加班卖力。
2)多元化发展,一切从小事做起,明白小事一团乱,大事也很有可能做不好。平时看看演讲口才书籍,要有点生活气息,而不是单纯的技术控。

4:不能当沉默人或者一团和气先生。

这点也是相当重要的。比如自己跟直属领导沟通时,要大胆质疑和提出一些问题,要大胆跟领导在敏感话题和其他相关延伸方面展开沟通讨论,不要过度相信领导。
可能80后从小受的教育观念,就是在学校听老师,在家听家长。但是长大成人走入职场中,如果当这样的老好人或者一团和气先生,可能自己总是那个活雷锋和被牺牲者。
特别是在民营企业里,领导也不喜欢那种一团和气先生,因为这种人不善于表达自己的真实想法。一旦领导不熟悉你,错误的给予了你一个年终回报。你提出要走人,然后真的走人了,其实对领导和雇主是个比较大的损失。
领导通常喜欢有想法,有主见的,善于表达的人。因为领导自身也很有压力的,他自己承担整个项目风险,难免有对项目考虑不周的地方,这个时候,领导很期望你能帮他纠正错误。
今后怎么办:
胆子要大点,同时充满微笑,自己要明白领导也很希望自己主动表达出自己的观点看法,主动发现领导的项目方面一些失误,并积极和领导进行探讨。

其他方面好的思路及流程

关于推动别人做事方面

首先自己发现出了其他模块的质量或者代码缺陷。其次有比较详细的测试数据说明确实该缺陷导致了用户端出的质量问题严重性在哪里。最后,在交叉中间地带的模块出问题时,要有数据表明自己也在该模块上做了多少改善质量的努力工作。

转载地址:http://wurvb.baihongyu.com/

你可能感兴趣的文章
GitLab安装说明
查看>>
Git查看、删除、重命名远程分支和tag
查看>>
PHP类中的抽象类,抽象方法,abstract
查看>>
PHP接口类interface的正确使用方法
查看>>
Sencha Touch之Hello World
查看>>
Tab Layout 之单个Activity实现
查看>>
Tab Layout 之多个Activity实现
查看>>
FrameLayout之我见
查看>>
个人解读Activity之一
查看>>
实现自定义布局的Notification
查看>>
AlarmManager的学习与实现
查看>>
解读Content Provider之一
查看>>
解读Content Provider之二
查看>>
自定义UI实例
查看>>
推荐一个不错的自定义UI
查看>>
fedora16 设置 gedit软件的默认编码
查看>>
S3C6410 存储器映射
查看>>
Linux 3.3.0移植到S3C6410开发板上之一
查看>>
Busybox支持中文的解决办法
查看>>
Spring中BeanFactory和FactoryBean有什么区别?
查看>>