Working Practice
time_hunter
这个作者很懒,什么都没留下…
展开
-
Working Practice-可以检查系统的三种方式
本文参考自《Head First 软件开发》不同的人用完全不同的角度或观点看待你的系统Black box人群:用户角度:用户从外面看系统。用户在乎的是系统的功能。重点:输入和输出实例:功能性用户输入验证。输出结果边界案例Grey box人群:测试人员角度:通常会做相对深入的研究。重点:寻求的东西通常与黑盒测试一样,但需要深入一些。实例:原创 2013-12-01 00:01:58 · 500 阅读 · 0 评论 -
Working Practice-Branch Trunk 和 Tag
本文参考自《Head First 软件开发》标记:大多数版本控制工具提供了一个好的方法。跟踪与该版本相应的有意义的事件。发布或一个开发循环的结束。某个时间的代码快照。在标记目录,我们有代码version-1.0标记,我们可以在任何时候拿出1.0版本。分支:代码的副本,可以对副本进行修改。分支是不想放到主干中的修改。修改代码的地方。应该把代码提交到branch而不原创 2013-11-30 00:37:50 · 446 阅读 · 0 评论 -
Working Practice-要有好的心态
今天经理过来,让我看看tablet上效果图。当听到以后,心里第一反应就是:怎么让我做?怎么又让我做?后来发现自己怎么会这么想?我应该用更好的心态理解这个问题:经理信任我,让我做这个事情。经理让我做很放心,我可以担当大任。信任我-》交给我任务-》做好任务-》(才可能更好,更快的升职加薪!o(∩∩)o...哈哈)另外,工作不是简单的任务,而是把它当作自己的东西,做好。原创 2013-11-15 00:17:23 · 409 阅读 · 0 评论 -
Working Practice-工作量完成情况趋势图说明开发进展情况
本文参考自《Head First 软件开发》工作量完成状况趋势图:作用:监控软件开发进程。为按时交付提供保障。示例:原创 2013-11-28 23:07:37 · 865 阅读 · 0 评论 -
Working Practice-每日碰头会
本文参考自《Head First软件开发》每天的碰头会,应该:跟踪任务:让所有人说明事情的进展。更新工作量完成状况。提出议题:鼓励每个成员提出任何面临的问题,以便作为一个团队去着手解决这些问题。让议程保持简短。原创 2013-11-28 00:51:41 · 527 阅读 · 0 评论 -
Working Practice-开发时间效率值
本文参考自《Head First-软件开发》开发时间效率值定义:一个比例,给定X天,其中有多长时间是在从事生产性工作。大小:对于一个新的团队开发软件,在第一次开发循环时,假设团队的开发时间大约是总时间的70%。成分:每10天的工作时间:3天是假日。软件安装文字工作电话其他非开发任务计算:完成工作需要的天数 = 工作天数 * 时原创 2013-11-26 00:57:26 · 523 阅读 · 0 评论 -
Working Practice-开发人员数目与绩效的关系
本文参考了《Head First软件开发》很多人都知道一个90天/人的项目,通常并不代表3个人,30天就可以完成。实际上,开发人员通常比实际上花的时间更长。下面的关系图参考自《Head First软件开发》:原创 2013-11-24 22:13:48 · 556 阅读 · 0 评论 -
Working Practice-使用todo list跟踪工作计划
使用todo list规划自己的工作,非常有用,最近使用这种方式感觉效率变高很多,收益如下:todo list帮助我梳理工作,轻重缓急。todo list有助于及时把跑题的自己呼唤回来,让自己清晰自己现在应该做什么。todo list是一种制度化的方式,我们把思考的时间留给了真正的问题,而不是思考,我下一步干什么,使用todo list,我们只需要看看,下一步我们该做什么了。每个完成的原创 2013-11-11 00:14:24 · 1085 阅读 · 0 评论 -
Working Practice-不要心存侥幸
今天在做程序的UI的时候,感觉自己计算px和dp中可能有问题,但是心里不想去,不愿去直视问题,而是心怀侥幸,希望这个问题应该不存在。结果:在我完成了很多UI的时候,发现位置和大小是错误的,重新返工。应该的处理直视问题,不逃避,不回避,不存侥幸心理。有可能影响较大的问题,那么花点时间写个demo还是值得的。原创 2013-11-09 23:38:33 · 456 阅读 · 0 评论 -
Working Practice-代码独立成块
代码独立成块,也就是代码中类能够独立开来工作:UI相关的控件类,应该只涉及UI,通过listener进行通信。底层模块,只提供基础的功能。(不要涉及高层的业务逻辑)底层提供接口支持,高层提供算法和策略。逻辑不相干的类,不进行通信。通过基本类型参数进行通信,能够减少耦合。提供小而精的框架而不是多而杂的框架。保持类的纯净。原创 2013-11-09 01:06:58 · 598 阅读 · 0 评论 -
Working Practice-保持小步前进
Feature 开发和Code Refactor保持小步前进:把稍大的目标划分成小的目标。达到小的目标就check in相应的code。通过不断实现小的目标达到实现大的目标。小步前进的好处:小的目标更清晰,更明确,更容易达到。每实现小的目标,便对自己便有一种无形的激励,并享受这种快感。实现小的目标时,我们的精力更多的放在某个单一的小目标上,精神更加集中。小步前进更能原创 2013-11-23 23:51:21 · 549 阅读 · 0 评论 -
Working Practice-统计是重要的数据
新的公司移动软件有很多统计,这些统计各式各样,这是一种很重要的资产:根据用户的喜好和用户的行为习惯发展特定的业务:根据数据调整战略,占领市场先机。提高广告的定位有效率。熟悉自己业务的发展情况,对自身有较好的认识。可以统计的数据:使用总时长,使用频繁度。页面停留时间。用户经常点击的模块。用户搜索的数据。使用时间段。原创 2013-11-23 00:05:18 · 544 阅读 · 0 评论 -
Working Practice-遇到问题的时候多多质问自己
遇到问题的时候多多质问自己,有助于自己跳出问题的泥潭,找到正确的方向。遇到问题时常问自己的:我现在在干什么?我为什么要做这个?有没有其他的方案?问自己,我怎么才能解决她呢。为什么B正常?两者之间有什么差别?这个问题是啥导致的呢?整个流程是啥样的呢?我是不是想的复杂了?有没有简单的方式?我可不可以向别人寻求帮助?从座位上站起来,到处走走,慢慢思考。记住:很原创 2013-11-08 00:14:38 · 592 阅读 · 0 评论 -
Working Practice-通过开发循环达到目标
通过开发循环达到目标(参考自《Head First软件开发》没有开发循环没有持续与客户核对的开发方法。很大的程度上偏离客户的想法,并非一点点。有开发循环持续与客户沟通持续集成重大进展的时候与客户沟通确认开发循环产生可工作的软件每个开发循环都是一个微型项目,都有自己的需求,设计,编码,测试等阶段。可以使开发循环一直保持在相对正确的轨道上,即便有些问题,也会比较小,原创 2013-11-20 21:31:34 · 614 阅读 · 0 评论 -
Working Practice-中午午休有助于提高效率
以前,我本不习惯午休,在下午工作的时候,总是习惯性的打盹,脑袋一个劲的点头。后来发现,当我每天中午停下来花些时间午休,对于我下午的状态有了很好的改善。原创 2013-11-18 00:16:05 · 20034 阅读 · 0 评论 -
Working Practice-完成工作是员工的第一要素
做为员工,最本质,最重要的是完成工作任务。也就是要有好的执行力。原创 2013-12-07 23:45:12 · 776 阅读 · 0 评论 -
Working Practice-表达代码的方法
常用的表达代码的方式:直接使用代码片段表示使用代码段,省略非重点,突出重点。伪代码。使用UML图表示。使用流程图,结构图表达。使用专业术语:单例策略原创 2013-12-08 23:44:56 · 418 阅读 · 0 评论 -
Working Practice-花些精力把东西放好,有助于提高效率
以前,我总是需要花很多时间来找东西,每次都要花很多时间去寻找:花点精力去放好东西是值得的,事实上,放好东西也花不了太多精力。把公交卡放在固定的,易放的口袋里。(这个习惯极大程度上改变了以前出地铁,到处找公交卡的习惯)保持桌面清洁。文件,起的名字要全面达意,也就是通过名字能够清楚是什么东西。(否则使用的时候,有的苦头吃)文件夹要有固定的存放方式。每天花一点时间保持桌面卫生,抽屉整洁,受益原创 2013-12-10 00:05:32 · 471 阅读 · 0 评论 -
working Practice-多问一句为什么
工作中讨论问题的时候,需要多问几句为什么?对问题会有更多的了解。可以进一步深入的分析事情的原委,而不是一个没有脑子的家伙。避免问什么,总是回答“不知道”。给组织贡献分析。时间长了,便成为一个真正有用的参与者,决策者。原创 2014-02-19 22:50:54 · 533 阅读 · 0 评论 -
Working Practice-非紧要业务不要使用模式对话框
今天定义需求的时候,产品给一个环节设定了一个模式对话框,一致认为这是个非常差的用户体验。(必须需要用户主动点击关闭才能进行下一步操作,带来了极大的不便)经过讨论,做了改善,如下:使用PopupWindow或者类似控件。点击任何区域隐藏控件。设定控件显示一定的时间,用户一定时间无操作时,隐藏控件。原创 2014-02-10 22:27:25 · 578 阅读 · 0 评论 -
Working Practice- 一些Android应用的测试case
1.横竖屏切换,检查UI数据完整性。2.网络请求模拟弱网下的访问。3g网络下的访问。3g和wifi下的是否需要不同的策略。短网以后恢复(下载数据是否具有完整性)。无效网络的连接请求。(如网络未链接但是开启的wifi)3.版本兼容Android2.3,2.2以前版本的兼容。新版本的兼容4.设备兼容大小密度兼容。大小尺寸的兼容。tablet和ph原创 2013-12-01 09:33:55 · 517 阅读 · 0 评论 -
Working Practice-必要的时候,请求协助
当一个人负责某个项目或feature的时候,发现进度低于预期,deadline之前很难搞定时,可以向同事或经理寻求协作。时常评估自己的进度,避免项目末期忽然发现项目会delay。先完成紧急并重要的case。非必要且极端的case可以作为enhancement或bug处理,在项目里标记为TODO。向同事或经理请求协助。清晰的分析当前的已经完成的,正在进行的,还未完成的工作。根据同事的情况原创 2013-12-16 21:12:09 · 493 阅读 · 0 评论 -
Working Practice-保持高效的习惯
已经在新的公司工作了几个月,与同事相处的过程中,发现效率高低很有不同。我进行了简单的对比,如下工作习惯高效率:雷厉风行,马上进入状态实用todo list整理工作先完成任务,再消遣(上qq,看新闻。。)低效率:表示知道了这个事情。慢慢进入状态,边上网,边工作紧迫感高效率:完成工作是第一任务想尽早的完成低效率:完成工作只是一原创 2013-12-29 22:30:40 · 565 阅读 · 0 评论 -
Working Practice-先实现再改进
我总是想一次把软件的结构设计成最好,却吃尽了苦头,我应该使用另一种心态:先实现再改进想一次把结构弄好:没有解决“有”的问题,却focus在“好”的问题上。耗费了太多太多的时间。想一次把结构设计好,翻来覆去,却总是设计不好。delay了其他更重要的工作。严重打击了信心。先实现再该经:保证“有”的问题。在有的基础上,稳定进行的改进,是一种增量型。这种方法,开发会有良原创 2013-12-14 21:36:09 · 449 阅读 · 0 评论 -
Working Practice-保持数据的纯洁性
一些UI相关的view可以封装成类,单独的放在widget里,但是,自定义view的类,需要保证:有意义的,重用率高的组合控件,可以封装在一起作为一个自定义的 view,方便重用。关系紧密,数据处理较多的view数据,有必要封装在一起。不应该涉及其他非UI相关的类,如Activity,Fragment减少数据的耦合。使用尽量简单的方法实现,(例如,可以通过不同的控件组合使用,优先于使用原创 2013-12-16 00:13:50 · 481 阅读 · 0 评论 -
Working Practice-尊重领导的意见
作为员工,自己的想法有时候会跟领导的产生分歧,这个时候需要注意:非原则问题,尊重并服从领导的意见。有时候,自己认为对的未必正确,自己的视野,经验可能有一些局限性。很多时候,即便自己的想法是正确的,那么这个正确的重要性尚不能赶得上配合领导工作。服从是一个配合,每一个当领导的都希望员工能够支持配合他的工作。可以舍身处地的换位思考。对领导好的地方表示肯定,认可。原创 2013-12-14 00:49:38 · 749 阅读 · 0 评论 -
Working Practice-简单的项目未必简单,困难只是没有预见
最近一个同事在做一个看似简单的项目,我的估计是2天内就可以搞定,真正做的过程中才发现一些问题,这些问题有这样的特点实践之前,这些问题总是想不到。实践中,发现一个疑问,记下来,随着时间跟进,会发现更多的疑问。这些疑问并不能总能找到好的解决方法。集思广义:开个会议是解决问题的最好最快的方法。原创 2013-12-12 23:53:36 · 501 阅读 · 0 评论 -
Working Practice-程序中添加必要的log
程序中添加必要的log,方便调试,定位问题以及找bug应该添加log的地方:网络请求请求地址参数。生命周期Android中例如Activity的生命周期。关键的事件点击事件滑动事件关心的各种通知push通知断网来电异常case发生异常时候数据不符合期待关心的数据结构已安装应用列表已下载应用列表流程过程相关原创 2013-12-05 22:06:05 · 568 阅读 · 0 评论 -
Working Practice-使用清单记录总结代码审核的问题
用脑袋记录一些事情,并非好的方法。对于Code Review,总是有一些经常范的典型的错误实例,把这些case总结成册,下次使用的时候,直接拿来使用,有下面几种好处:case清单记录在册,减少了脑力的耗费,可以使用脑袋记录更有意义的事情。清单记录在册,保证了case的完整性,文字相对记忆,更具有可靠性。清单的记录总是一种增量型,有利于经验的积累,记忆却未必。使用清单,是体制化的体现原创 2013-12-04 23:25:27 · 551 阅读 · 0 评论 -
Working Practice-快速原型模型
快速原型模型的特点:原型:软件的一个早期可运行的版本,反应最终系统的重要特性。它是增量模型的另一种形式。在真实系统之前,构造一个原型,在该原型的基础上,逐渐完成完成真个系统的开发工作。快速原型的步骤。建造一个快速原型。实现客户或未来的用户与系统的交互。用户或客户对原型进行评价。进一步细化代开发软件的需求。通过逐步调整原型使其满足客户的要求。快速原型的产生的原因:原创 2013-12-12 00:56:10 · 844 阅读 · 0 评论 -
Working Practice-Scrum是一种工具而非一种负担
今天我重新接触了Scrum,重新接触的意思是指以前接触过,并且放下了。我特意分析了一下两种状况: 之前现在如何接触team leader部署想使用好的,高效的软件开发方法心理抗拒乐意去做个人原因太注重个人的感受(未完成或延迟完成时造成的心理负担)想把Scrum当作一种好的工具来使用,来开发团队原因原创 2013-12-04 00:39:06 · 567 阅读 · 0 评论 -
Working Practice-使用错误记录器记录错误
本文参考自《Head First 软件开发》软件错误应该记录在错误记录器中哪些软件错误:编程的错误。忽略的功能。免费的软件错误记录器:BugillaMantis记录软件错误以外的事情:错误的优先级和严重程度记录每件事情关于错误的讨论,测试,代码变更以及处理决定的历程。整个团队都可以查看错误的进展情况如何做的测试。了解开发人员怎么修原创 2013-12-02 23:49:19 · 604 阅读 · 0 评论 -
Working Practice-尽早集成
最近参与一个项目,项目时间很是紧张。最后提测的时候,需要把此模块集成到主项目中,集成的过程中发现了很多问题,这些问题在模块独立使用的时候,没有这些问题:build error(编译依赖,非预期问题)显示异常:本来显示ok的图片资源,集成到项目时候,发现显示出的资源有误。运行时异常:对于一个本定义好的资源,却显示找不到次资源id。为什么会导致这些问题:开发工具本身就存原创 2013-11-16 21:27:22 · 699 阅读 · 0 评论 -
Working Practice-不使用怪癖的算法实现
做feature的时候,有时候,为了实现一个功能,会使用一些怪癖的算法或方法实现。怪癖的算法是有缺点的,通常意味着:较高的理解难度。较高的维护成本。较低的稳定性。另外:使用怪癖的算法实现一个功能并不意味着高技术能力。好的算法应该易于理解,清晰,可维护。尽可能多的保持简单。原创 2013-10-22 22:47:20 · 548 阅读 · 0 评论 -
Working Practice-倾听员工的抱怨
在工作中时常遇到一些员工的抱怨,抱怨的问题常常会涉及方方面面。我就是一个经常抱怨的员工,至少以前是。当遇到员工的抱怨时,应该怎样的处理呢?欢迎抱怨:我们应该把提问题和问题本身区分开来。对于员工能够讲内心的疑惑和不解表达出来,我们应该欢迎这种方式。希望员工将来能毫无隐瞒的说出问题,帮助员工也帮助企业共同成长进步。站在员工的角度看问题:管理者与员工站的位置不同,利益不同,思维的角度也不同。原创 2013-10-05 15:34:09 · 670 阅读 · 0 评论 -
Working Practice-多方位学习
在毕业后的三年里,我的学习的对象主要是技术方面的。工作中遇到一些事情,我开始渐渐思考,工作除了技术以外,还有很多事情值得学习。 不久前,我跟一个测试的同事关于bug的处理产生了分歧,事情的缘由不重要,重要的是:我坚持认为我的处理是正确的,而测试的同事坚持认为她的要求是合理的。我们无法达成一致(或者说,我们根本没有想去达成一致,都固守自己的想法)。最后,我把当时的这个项目的原创 2013-10-01 22:49:12 · 517 阅读 · 0 评论 -
Working Practice-善于使用静态代码检查工具
本文参考了IBMDW 常用 Java 静态代码分析工具的分析与比较要善于使用静态代码检查工具,这些工具能够通过对源码或字节码的扫描,能够非常有效的找出潜在代码设计逻辑或编码缺陷。有很多免费的静态代码检查工具,不同的工具可能有不同的视角,对于同一个项目,我们可以通过使用多个静态代码检查工具查找问题,因为:无论从哪个工具能够找到问题,我们从不排斥发现问题,我们欢迎发现问题。支持ja原创 2013-09-17 13:09:02 · 643 阅读 · 0 评论 -
Working Practice-破窗理论与写代码
参考自《百度百科-破窗理论》破窗理论:一扇窗户被打破,如果没有修复,将会导致更多的窗户被打破,甚至整栋楼被拆毁。理论说明:环境可以对一个人产生强烈的暗示性和诱导性(美国政治学家威尔逊和犯罪学家凯琳观察总结)。工作中:看到写的不好的代码,就会降低自己的代码质量的要求,这个非常不好!原创 2013-09-16 21:56:36 · 741 阅读 · 0 评论 -
Woring Practice -每次修改进行code review
Code Review是软件静态测试的手段之一,通过code review收益会非常多,如下:发现bug通过review发现的错误更具有确定性。发现的越早,修改的成本越小。代码的作者重新审视代码,有助于梳理作者的思绪,因为代码需要给别人看,更能够进一步保证质量。与别人分享自己的才能,提高别人对自己的认识。通过code review,达到了技术分享的交流,长远看,原创 2013-09-15 23:38:13 · 608 阅读 · 0 评论 -
Working Practice-设置免打扰时间
本文参考了《卓越程序员密码》设置免打扰时间最初在《卓越程序员密码》中看到,当时感觉深有体会。当我在学习和工作中遇到了问题,我常常通过通宵加班和周末加班的方式补回来。我发现这种方法真的很有效。通宵加班的时候,我常常能够一晚上把比两白天的事情完成。这是为什么呢?通过阅读《卓越程序员密码》,明白了:琐碎的事情会浪费精力处理。琐碎的事情会增加一定的烦忧,如果没有了这种烦忧,就如同如释重原创 2013-10-01 00:19:19 · 716 阅读 · 0 评论