自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(24)
  • 收藏
  • 关注

原创 Working Practice-保持高效的习惯

已经在新的公司工作了几个月,与同事相处的过程中,发现效率高低很有不同。我进行了简单的对比,如下工作习惯高效率:雷厉风行,马上进入状态实用todo list整理工作先完成任务,再消遣(上qq,看新闻。。)低效率:表示知道了这个事情。慢慢进入状态,边上网,边工作紧迫感高效率:完成工作是第一任务想尽早的完成低效率:完成工作只是一

2013-12-29 22:30:40 545

原创 软件工程-估算软件规模之代码行

本文参考自自张海藩老师和牟永敏的《软件工程导论》代码行技术:比较简单的定量估算软件规模的方法。代码行优点:所有软件项目都有的“产品”很容易计算代码行数代码行的缺点:源程序只是仅是软件配置的一个成分,源程序不能等价于程序。用不同的语言实现同一个软件,所需要的代码不同。

2013-12-24 00:12:49 4828

原创 软件工程-面向对象方法学的优点

本文参考自张海藩老师和牟永敏的《软件工程导论》,面向对象方法学的优点与人类习惯的思维方法一致。稳定性好。传统方法所建立起来的软件系统的结构紧密依赖于系统要完成的功能。当功能需求发生变化时将引起软件结构的整体改变。面向对象方法基于构造问题领域的对象模型,以对象为中心构造软件系统。当功能需求发生变化时,往往仅需要一些局部性的修改。可重用性好。重用是提高生产效率的最主要的

2013-12-22 21:34:38 7510

原创 沟通-让对方愉快的达成目的

沟通也是一门技术,想成为优秀的人,要能够更高的要求自己,宽容别人。微笑友好的表达自己的想法。倾听对方的抱怨。站在对方的角度看待问题。让对方愉悦的接受自己的观点,达成沟通的目的。不抱怨别人的缺点,言辞诚恳。

2013-12-21 22:37:04 492

原创 制度化-给未来的自己发送一个提醒

本文参考《高效人士的116个it秘诀》不使用记忆力:记东西很累。记东西不可靠。使用google 日历简单的办法:记忆频繁重复的事件。可以设置不同的提醒时间。可以使用不同的提醒方式:发送邮件、发送短信。pc ,cell phone同步。

2013-12-21 00:54:27 498

原创 软件工程-可重用构件的特点

本文参考自自张海藩老师和牟永敏的《软件工程导论》目标:在各种各样的软件系统中方便的重复的使用需要满足的要求:可靠 经过反复测试,被确认是正确的。具备一定的健壮性。模块独立性强具有单一、完整的功能应该是不受,或较少受外界干扰的封装体。具有高度的可塑性具备适应特定需求的而扩充或修改已有的构件。修改或扩充相对简单。接口清晰,简明

2013-12-19 22:39:59 2397

原创 软件工程-软件重用

本文参考自自张海藩老师和牟永敏的《软件工程导论》重用:定义:同一事务不作修改或稍做修改就多次重复使用。重用的元素:知识重用:例如软件工程的知识。------属于“知识范畴”方法和标准的重用:如:面向对象方法。---属于“知识范畴”软件成分的重用。代码重用源代码剪贴import或include。继承设计结果的重用:重用某个软件系统的分析模型。分析结果模型:

2013-12-19 00:10:32 1634

原创 软件工程-软件的可维护性

本文参考自张海藩老师和牟永敏的《软件工程导论》软件可维护性的定义:维护人员理解、改正、改动或改进这个软件的难易程度。决定软件可维护性的因素:可理解性:定义:表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。如何提高可理解性:模块化结构(高内聚、低耦合)详细的设计文档可测试性:模块的环形复杂度越大,可执行的路径就越多,全

2013-12-17 22:00:53 1823

原创 Working Practice-必要的时候,请求协助

当一个人负责某个项目或feature的时候,发现进度低于预期,deadline之前很难搞定时,可以向同事或经理寻求协作。时常评估自己的进度,避免项目末期忽然发现项目会delay。先完成紧急并重要的case。非必要且极端的case可以作为enhancement或bug处理,在项目里标记为TODO。向同事或经理请求协助。清晰的分析当前的已经完成的,正在进行的,还未完成的工作。根据同事的情况

2013-12-16 21:12:09 476

原创 Working Practice-保持数据的纯洁性

一些UI相关的view可以封装成类,单独的放在widget里,但是,自定义view的类,需要保证:有意义的,重用率高的组合控件,可以封装在一起作为一个自定义的 view,方便重用。关系紧密,数据处理较多的view数据,有必要封装在一起。不应该涉及其他非UI相关的类,如Activity,Fragment减少数据的耦合。使用尽量简单的方法实现,(例如,可以通过不同的控件组合使用,优先于使用

2013-12-16 00:13:50 464

原创 Working Practice-先实现再改进

我总是想一次把软件的结构设计成最好,却吃尽了苦头,我应该使用另一种心态:先实现再改进想一次把结构弄好:没有解决“有”的问题,却focus在“好”的问题上。耗费了太多太多的时间。想一次把结构设计好,翻来覆去,却总是设计不好。delay了其他更重要的工作。严重打击了信心。先实现再该经:保证“有”的问题。在有的基础上,稳定进行的改进,是一种增量型。这种方法,开发会有良

2013-12-14 21:36:09 435

原创 Working Practice-尊重领导的意见

作为员工,自己的想法有时候会跟领导的产生分歧,这个时候需要注意:非原则问题,尊重并服从领导的意见。有时候,自己认为对的未必正确,自己的视野,经验可能有一些局限性。很多时候,即便自己的想法是正确的,那么这个正确的重要性尚不能赶得上配合领导工作。服从是一个配合,每一个当领导的都希望员工能够支持配合他的工作。可以舍身处地的换位思考。对领导好的地方表示肯定,认可。

2013-12-14 00:49:38 698

原创 Working Practice-简单的项目未必简单,困难只是没有预见

最近一个同事在做一个看似简单的项目,我的估计是2天内就可以搞定,真正做的过程中才发现一些问题,这些问题有这样的特点实践之前,这些问题总是想不到。实践中,发现一个疑问,记下来,随着时间跟进,会发现更多的疑问。这些疑问并不能总能找到好的解决方法。集思广义:开个会议是解决问题的最好最快的方法。

2013-12-12 23:53:36 467

原创 Working Practice-快速原型模型

快速原型模型的特点:原型:软件的一个早期可运行的版本,反应最终系统的重要特性。它是增量模型的另一种形式。在真实系统之前,构造一个原型,在该原型的基础上,逐渐完成完成真个系统的开发工作。快速原型的步骤。建造一个快速原型。实现客户或未来的用户与系统的交互。用户或客户对原型进行评价。进一步细化代开发软件的需求。通过逐步调整原型使其满足客户的要求。快速原型的产生的原因:

2013-12-12 00:56:10 824

原创 Working Practice-花些精力把东西放好,有助于提高效率

以前,我总是需要花很多时间来找东西,每次都要花很多时间去寻找:花点精力去放好东西是值得的,事实上,放好东西也花不了太多精力。把公交卡放在固定的,易放的口袋里。(这个习惯极大程度上改变了以前出地铁,到处找公交卡的习惯)保持桌面清洁。文件,起的名字要全面达意,也就是通过名字能够清楚是什么东西。(否则使用的时候,有的苦头吃)文件夹要有固定的存放方式。每天花一点时间保持桌面卫生,抽屉整洁,受益

2013-12-10 00:05:32 451

原创 Working Practice-表达代码的方法

常用的表达代码的方式:直接使用代码片段表示使用代码段,省略非重点,突出重点。伪代码。使用UML图表示。使用流程图,结构图表达。使用专业术语:单例策略

2013-12-08 23:44:56 406

原创 Working Practice-完成工作是员工的第一要素

做为员工,最本质,最重要的是完成工作任务。也就是要有好的执行力。

2013-12-07 23:45:12 741

原创 Code Fragment-封装重复代码的代码

封装重复代码的方法有:提取方法:在一个类里提取重复部分的code生成方法,在其他使用的地方直接调用。pull up方法:把两个兄弟类中重复的方法,放到父类中实现。提取成类:使用组合的方法。封装成静态的工具类。使用单例。重载类型的方法,参数少的去调用参数多的,在多出的参数里传入默认值。

2013-12-06 23:53:07 5746

原创 Working Practice-程序中添加必要的log

程序中添加必要的log,方便调试,定位问题以及找bug应该添加log的地方:网络请求请求地址参数。生命周期Android中例如Activity的生命周期。关键的事件点击事件滑动事件关心的各种通知push通知断网来电异常case发生异常时候数据不符合期待关心的数据结构已安装应用列表已下载应用列表流程过程相关

2013-12-05 22:06:05 552

原创 Working Practice-使用清单记录总结代码审核的问题

用脑袋记录一些事情,并非好的方法。对于Code Review,总是有一些经常范的典型的错误实例,把这些case总结成册,下次使用的时候,直接拿来使用,有下面几种好处:case清单记录在册,减少了脑力的耗费,可以使用脑袋记录更有意义的事情。清单记录在册,保证了case的完整性,文字相对记忆,更具有可靠性。清单的记录总是一种增量型,有利于经验的积累,记忆却未必。使用清单,是体制化的体现

2013-12-04 23:25:27 535

原创 Working Practice-Scrum是一种工具而非一种负担

今天我重新接触了Scrum,重新接触的意思是指以前接触过,并且放下了。我特意分析了一下两种状况: 之前现在如何接触team leader部署想使用好的,高效的软件开发方法心理抗拒乐意去做个人原因太注重个人的感受(未完成或延迟完成时造成的心理负担)想把Scrum当作一种好的工具来使用,来开发团队原因

2013-12-04 00:39:06 552

原创 Working Practice-使用错误记录器记录错误

本文参考自《Head First 软件开发》软件错误应该记录在错误记录器中哪些软件错误:编程的错误。忽略的功能。免费的软件错误记录器:BugillaMantis记录软件错误以外的事情:错误的优先级和严重程度记录每件事情关于错误的讨论,测试,代码变更以及处理决定的历程。整个团队都可以查看错误的进展情况如何做的测试。了解开发人员怎么修

2013-12-02 23:49:19 589

原创 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 503

原创 Working Practice-可以检查系统的三种方式

本文参考自《Head First 软件开发》不同的人用完全不同的角度或观点看待你的系统Black box人群:用户角度:用户从外面看系统。用户在乎的是系统的功能。重点:输入和输出实例:功能性用户输入验证。输出结果边界案例Grey box人群:测试人员角度:通常会做相对深入的研究。重点:寻求的东西通常与黑盒测试一样,但需要深入一些。实例:

2013-12-01 00:01:58 487

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除