试着去写测试案例

工作近十年了,也就是说快写了近十年的代码了。我承认之前的九年没有为自己的代码写过任何的测试脚本,或者是任何形式的测试案例。每次穿梭于书店或是网上博客等,我对单元测试,或是诸如自动化测试都十分的不屑。“代码要紧”,“完成工作要紧”这是我当年的信条。虽然我认同自己的开发习惯还是不错,编码风格也挺赞的,但自从阅读了一本名为《测试驱动开发》的书后,才发现以测试为驱动的开发过程的确是对人们自认为的开发过程的一种颠覆。无法完全的说明哪种方式的好与坏,但编写测试案例,写单元测试确实给我带来了不同的思考,并认为这是非常有必要,也会为之努力而实践的。

编写测试案例,让我们更细致的去分析问题。计算机对代码的执行不会欺骗任何人,我们开发代码的过程中总是力争将所有的点和面都考虑到,将所有可能的情况都涉及到。所以有必要模拟各种可能的场景去测试每一个细小的环节。而这个细小的环节就是我们程序中的小小单元,对一个个小小单元的全方位测试,才能力促整个程序逻辑的完整测试。所以单元测试是整个程序测试的根基,是实际业务的问题点,逻辑点。将复杂的问题分析到点,测试到点,会有助于我们在编写代码的时候理清关系,将点组成线,从而组装成整个程序。

编写测试案例,让我们更好的去重构程序。测试案例能为整个程序的正确性奠定了一个基调,任何可能的修改都不能违背单元测试的正确通过。而同样的有了测试案例,相关开发人员,可以快速方便的通过测试案例理解程序和代码的运行过程。同样的,对完美代码的无限追求下所做的改动,也能保证所做的代码重构没有改变原有程序的正确性。也不用过分的担忧代码结构的调整会造成严重的逻辑的错误,而这些错误的改动却没有被发现。当然,这里有一个前提条件,就是我们要适时的去维护我们的测试案例,并要保证我们的测试案例本身就是经得起验证并且是正确的,否则,上面所说的一切将都是不成立的。

测试案例的编写,能帮助我们快速熟悉业务,甚至可以帮助我们提炼出程序的运行过程,制定合理的程序框架。让我们在修改代码的时候,不易更改原有的逻辑,不会去污染原有的代码。可以提高我们写代码的正确率。能更好的服务系统维护,二次开发等等。说了这么多的测试案例的好处,但只有尝试和运用,你才会有这样的体会。也许一开时你会觉得写测试案例是如何的无聊和重复。但当你看一段没有测试案例的代码时,你又会感到无奈无助,更会为在这段代码上进行的修改或二次开发而感到不安。但肯定会为有相应的测试案例而暗暗叫好,并会为一段代码补上测试案例而开心不已。测试案例就好比前人栽树,后人乘凉。

那么问题来了,测试案例怎么写?

测试案例应该全面但不重复的,我们应该尽可能覆盖所有的程序代码,但我们不必为代码写重复的测试案例。测试案例应该简单明了,让人一眼就能看明白。你不必纠结英文怎么翻译,你甚至可以简单的就用中文的类和中文的方法名称来表示这个测试案例的含义,甚至可能是测试的目标名称(但我反对在生产代码里用中文,甚至包括中文拼音)。测试案例往往是并列的,列表状的,所以你能一眼看到测试的结果和未通过的测试内容,方便查找和定位。当然,你还要有好的测试工具,测试包之类的。最后也往往是最重要的是保证你的测试案例是最新最完整的。

测试案例看起来像是开发过程中的一个负担,但这只是你没有从根本上去发现测试的魅力和益处。只有你潜心下来去做,去完善你的单元测试,久而久之,你会发现,测试真的很美。

挑大梁的试用期

试用期还没有结束,还没有转正,我就已经快速的进入了工作角色。虽然很多项目的业务没有具体去熟悉,我都想好了,等碰到具体问题再详细去了解,这期间也陆陆续续的完成了一些开发任务,更新了一批bug及各种新的需求。看着任务单里一个个删除完成了的任务,那种试用期对业务和工作的懵懂和迷茫慢慢的消逝了。

是很忙,至少比我之前做的许多工作都忙,也许除了我的头两年工作,那些最初入行的日子,工作肯定是不轻松的。后来到了太古,更谈不上忙,除了短暂的两三个月由于数据库架构的调整所对应的项目重新纠正和开发忙之外,我认为自己都是那个略微显得空闲的人,同样的也就没有了值得去称赞的事迹。也正是在那样的日子里,我会经常的去更新博客,写写体会。而现在,从早上进入办公室起,到不得不加班的七点后,我都没有一整段的时间来静静的写点东西,思考思考。也许,这样的忙日子是对我之前工作十年的空日子的补充吧。也许我的时间并不值钱,真正加点班又有什么呢。

刚来就出差,而且也出色的完成了任务,这从多个领导对我的谈话里都透露了出来。领导也建议我看看能不能提前转正,我也报着试试看提交了转正申请的流程。也多少从领导那里得知月奖和年中加薪的各种激励政策,我也热切的期待那个时候的到来。旧同事也要离职,领导也把所有的活都让我试着接下来。没有怨言,也许这些都是我能做的。慢慢的我也会去评估工作量,也会向领导申请新的资源和后备力量,这么多项目总是有多个人知道会好些。团队稳定是我们项目组是否完成目标的关键所在吧。尽力的保证当前各个项目的维护稳定与反馈及时,是我现在努力去完成和实现的。

我当然希望自己能去参与一些新的项目,外围项目,比如电子政务,智慧城市,和大数据沾上边的都可以。也许到最终的开发工作和当前做的可能没什么很大的不同,但这种经历毕竟还是有很大区别的,这种项目经验会与现在的小范围的项目有很大的不同。统筹的,多角度的,决策范围的业务会让你更广大的视野,对自己的帮助和提升相信也应该是巨大的。希望能如领导所说,会有这个参与的机会,但这也只能等到现有的项目都能很好的服务,或者我们已从当前的业务转身,那就是另一种情景了。期待那一天的早日到来。

又有同事离职了,还未转正,又交接了很多的工作给我,自我感觉算得上是一个大梁。经验往往在胜任工作的过程中扮演着非常重要的角色,无论是具体的开发实践,还是客户沟通,同事间的相互协作等等。而这些也只有经过时间的洗礼,才会慢慢的成长。而我期待这种成长,能让自己完成质的跨越。

新工作一月记录

时间过的很快,在新的单位也足有一个月之久了。从当初的种种不适应到现在的勉强去适应,随着工作的深入,接触的东西与人也越来越多,所有的一切都迫使你沉下心来去做一些事情,完成一些任务了。现在记录下这一个月来的主要内容吧。

出差台州将近有十天之久。出差本身就不太适应,再加上一来这个单位就出差,心还没有静下来,又要人飞的感觉,一切都没什么底,但也要硬着头皮上的感觉。还好吧,工作也算顺利,也不是什么大的项目,功能也没有太复杂,也都陆陆续续的完成。只是后端数据这块变动太多,所以还未能将项目完结。接下来的任务也会慢慢的变少,但也要抽出不少时间去完善各种功能的。

顺着项目算是学会运用了些Struts,myBatis框架吧。只是我还不会搭,或是说从头搭吧。在原有框架基础上增加删除新功能对我来说并不太难。难点是那些未曾触碰的知识,比如大数据量下载的处理啦,tomcat调优啦,还有就是自己想去学习的这些框架的原理。Java基础不扎实,看这些源代码也是很吃力的事情,再加上各种设计模式,肯定会花很多时间的。能接触更多的知识无疑对我有很大的帮助,这能完善我在Java开发上的知识体系。

不习惯加班,不习惯打卡,不习惯写日志,不写周报。在这里都要统统说NO了。所有的这些都会被以罚款论处,所以无论如何也不能和钱说不去。每天总是时刻提醒自己有没有忘记打卡,有没有忘记写日志。甚至加班的时长也作为小组考核的依据,压力山大啊。有的时候,我会想趁加班的时候看看书,或写写日志,做个小结,把这个时间用起来是再好不过了。

都快一个月没写日志了,好害怕自己不再爱上写文章,不再喜欢思考。也许是没什么时间,再说真心不想成天盯着电脑啦。每次打开记事本的时候却发现想写的东西并不感觉到有什么价值。但又不想这么消沉下去。总要努力让自己在博客上发出更多的声音。

新的环境 新的起点

还没有来得及适应新的工作环境,就被领导安排着出差来到台州。我的心是忐忑的,因为我的java开发经验真正意义上不足两年,我没有系统的学习过SSH,用我之前写的博客里说的那样,我的java是自学的。但给了我这个机会,我想我会努力去抓住的。我想着尽快的学好SSH,然后有机会学习点分布式或是大数据方面的知识。我目前没有后悔放弃我的.net而转到java开发。这并不奇怪,我曾经也迷迷糊糊的学习了一点php知识。语言对我来说就是个工具,但语言背后的那些高深的技术的确是需要有人引领的。

纵使旧人如何说公司的不好,还有不断的员工离去,甚至项目组现在人缺的连我这个新人就被推上出差的前线。但我在这里短暂的几天,就发现了自己曾经想找的那些东西。这里还是挺崇尚技术,崇尚分享。只要有你兴趣,周周都有技术的分享交流邀请等你去接受。这里有你的导师,还里有不段上马的新项目,这里同样有很多你没学到和可以学到的知识。这里有年轻的新人,有新鲜的血液,大都90后啦。这里还可以毛遂自荐。我是新人中的旧人,我没有理由不开始努力一把,做的更多,做的更好。

所以我没想到领导会直接安排我出差的时候,我同样也没想到拒绝。之后也想到过各种困难,想到过各种不易,但想到曾经的自己也独立完成过很多项目。信心也不会少很多了。再加上有现有的程序可供参考,加加减减功能也变得不那么难了,再不会的困难,到网上找找也总是有答案的,或者就变个法子去解决吧。也许等回过头来再看,当初的那些疑虑是多么的微不足道,甚至是可笑的。有些事情就是怕你去做,只要勇敢的走下去,就真能闯出一片天地。

我迫不及待地想去发现另一份美好了。

为了这个改变

五年算一个轮回,我已经跨五年来到了六年的关口。想想生活,想到可能的压力和梦想中的未来,就开始默默地下了决心去做一些改变。但不能否认这个决心下的是有些艰难的。毕竟这里安逸,稳定,一切都能按部就班,如果工作不犯什么大的错误,也许真的能在这里待一辈子,想想也会很害怕。但往往优点里面也透着显著的缺点,工作缺少激情,谈不上创造,晋升和加薪幅度缓慢。也许,我有我性格上的缺陷,我不擅于交际,我甚至怀疑大的领导根本就不认识我。我没有百分百的努力,因为努力可能也带不来回报,这里有很多的人情事故,先后之别。

人生有多少个六年。六年前,我以比原单位高一倍的工资作为外包员工来到了这个单位。我之前的单位薪水太低了。虽说是外包员工,但工作的内容也并不繁重,公司内部的管理系统对我来讲很多也是轻车熟路,只是从Windows程序跳到Web开发一时有些不适应罢了。随着工作的陆续展开,一切都不再那么忙碌,除了偶尔的上线和出差外,闲暇的时间也多。在最初的那段日子,我试着去读去啃一些英文的原版书,去读英语的网页,让自己的专业英语阅读理解水平有了一定的提高。到11年未,我开通了博客,前期翻译了一些英语的文章。这都是那个阶段英文学习的具体措施。

之后在外包的一段稳定时期,领导的抬爱,每年都能给我增加一些工资,也让我对自身所处的环境有些满足。转变也来的很快,14年上半年,随着公司组织架构的调整,我被安排在开发小组,由另一个人当了我的领导。领导的做事风格不一,一来可能领导自身的压力影响到我们,二来也可能是自己未能马上习惯新的领导,那段时间的工作都是相当充实的,做了很多,开发进度很快。后来我们都做完了,才发现并没有完全根据我们的设想的去做,之前全当是投石问路,当然接下来的工作就更加的轻松了些。无非就是小的修修补补。有问题要开发,也要绕到各部分经理,再到开发转测试到发布,一个来回很多时候没有一个月根本无法走完。战线拉长了,事情也同样被稀释了,工作量相应的也减少了。大多问题都是小的改进和小的Bug修改。15年初的时候,我被借调三分之二的时间去另一个项目做开发。几轮的开发平台工具培训下来,都未掌握多少,这只能到后续的项目实际中去学习了。后来到六月份左右,项目的开发才算真正启动,我也开始了我的Java学习之路。其实谈不上Java学习,除了一个Api接口站点用通用的SpringMVC框架外,其余基本都是在Sites平台上做一些jsp页面和Template的修改。外加在平台后台中类似数据建模的概念。我做的工作自己算起来真不算多,但还是有几个算是需要独立去研究的吧。比如:资产的定期同步功能,产品修改后的流程自动发起功能等。对于碰到的新的功能与要求,我总会试着努力去解决的。

忘了说我在14年7月转到了甲方,这当然也是领导的抬爱,只是这次转正加工资的幅度是大大落后于之前的,但想到福利公积金,想到归属与认同感 ,其实还是挺好的,这当中更能体现领导对我的认可吧。从不敢说天不无不散之宴席,生活的压力和自己的未来时不时的再提醒自己是不是落后了,能不能再进步一些。15年的后面几个月我延长了自己的下班时间,就是为了能多一点时间给自己再充充电,为了自己未来的工作讨活多一点点吆喝的本钱。其实生活也并没有想象中的困难,但现实就是相当的残酷,如要改变,自己得先变。于是,我就这样慢慢的准备着。

家是最后最强的堡垒。在很多内心苦闷的时候,总是家人在后面开导我,激励我。虽然有些时候会感受到来自他们的压力,但终归是他们给我勇气和前进的动力。想到他们为家付出的努力与心血,我也应该奋力为他们开创更好的明天。

你的spring是自学的吧?

当我第一次参加java面试的时候,在一堆spring相关问题之后,面试官直接来了一句:你的spring是自学的吧。我没好意思说啥,甚至有些不太好意思,因为我自学的很不好。事实就是我没有很多的spring开发经验。唯一一个用spring的项目,框架也是别人搭好的。地基搭好了,我只是在上面添砖加瓦,所以spring的核心思想,及各种使用的办法都没有清晰明了的概念。又反过来回到面试官的问题,试问谁的spring不是自学的?工作好多年,新技术,新语言也基本上都是自己在学习,要是没有自学,也真不知道自己能不能应付当下的工作,和新的挑战了。

回到spring,这些天总在反复理解spring的概念,什么IOC,什么DI啦。我觉得这要从spring是用来做什么事情的来理解。spring是一个框架,它的代码本身与任何的业务系统没有直接的联系。通常我们的业务系统就不得不定义和声明一些类和接口,代码中完成类与类,对象与对象的关联与操作。代码之间存在类与类,类与接口之间的关系可称之为耦合。以前我们在实现业务代码的时候,各种new操作,set方法等等这些都造成了我们的业务代码不容易修改和重用。系统运行过程中,就往往过多的创建实例,造成资源的浪费,同时也增加了垃圾回收的压力,降低了服务器的真实性能。

而spring就是这样一种轻量级的框架,我们可以将业务系统中定义的各种类的实例化交由spring来管理,这样spring就相当于一个容器,存放各种相互依赖的对象实例。当我们的业务系统代码中需要用到某个对象时,就可以到容器中去查找是否有,如果容器中有就可以直接拿来使用,而不必在使用的时候在业务代码中进行实例化。spring会根据上下文的配置或是成员变量在代码中的注解,将对象进行注入(依赖注入)。通过依赖注入,业务代码中的各类之间降低了代码的耦合。而spring本身不关注业务系统的逻辑,它运用的是IOC和DI思想,并在此思想上构成了这样一个通用的框架。

spring的IOC可认看成是工厂模式的升华,可以把IOC看成一个大工厂,只不过这个大工厂里生成的对象都是XML或者是注解的代码中给出的,然后利用Java的“反射”机制,给合类名生成相应的对象。spring的这种机制,可以很方便的将其它的类引入到我们的业务系统中,在代码中自动注入并使用它的某些方法等。

IOC是一种设计模式,这种新式的模式并没有在GOF中。之前我也没有好好的读过《设计模式》,近日来的阅读,让面象对象的接口设计给我来的各种惊奇。工作中的碰到的不同场景其实都可以往设计模式上去思考一番,是否可以运用这样的方法来改善我们的代码结构,或者是重构等等。过往的开发,我们往往太注重业务实现,而没有在代码的结构,重构和可扩展上面考虑的很详细。自学spring让我在这些方面领会到了很多。

Btw:上速的依赖注入及spring的思想等,是自己翻阅各种资料理解的结果,未必完全正确。而这里说的spring指的是spring的核心框架,没有包括spring的aop,web,mvc框架等。

理解编译时与运行时

在面象对象的开发过程中,经常会用到面象对象的多个特性,比如:继承和多态。继承通俗的讲就是可以用子类去扩展父类的方法和属性,可以直接用父类的引用指向子类的对象。而在运行的过程中,程序会根据引用对象的根本类型判断应该调用的方法,有的可能就是重载子类的方法,这就是多态。那么要如何判定程序的编译正确与否,以及运行时是否正确的执行,这里我们需要理解两个概念,编译时和运行时。

编译时:指的是编译器将你的程序代码编译成机器能识别代码的过程。在这个过程中,编译器会根据各个语言的规范,指出哪些代码会编译出错,无法通过。无法通过编译的代码当然无法执行。看下面这个例子。

class Base{
public void func1(){ System.out.println("B-func1"); }
}

class Sub extends Base {
public void func1() { System.out.println("S-func1"); }
public void func2() { System.out.println("S-func2"); }
}

public class Test{
public static void main(String arg[]){
Base s = new Sub();
s.func2();//编译出错,func2没有在类Base中定义
}
}

如上代码所示,标准行出现了编译错误,func2没有在类Base中定义。s是由Sub类创建,但被基类Base引用所指向,所以s只能调用Base的方法和成员属性。无法调用Sub类的成员方法。这时要调用就要加上强制转换再调用:


((Sub)s).func2();

编译时,不仅会检查各种定义,调用的规范,有的编译器还会对代码进行编译优化,比如:那些不变的静态变量的计算过程及赋值,可能直接就被计算结果所替换。还有一些泛型类或是C#中的语法糖都会编译成原始的代码处理方法等等。

运行时:有些基类的方法在子类实现了继承,而在代码中往往用的是基类的调用。这种情形下,只有在运行的时候根据调用对象的根本类型来判定调用的是基类方法还是重载方法。比如下例代码:


public class Test{
public static void main(String arg[]){
Base s = new Sub();
s.func1();
}
}

s调用了func1()函数。因为Base中定义了func1()成员函数,所以编译通过不会报错,但此时s调用的是Base类中的func1()方法,还是Sub类中的func2方法呢?s本质是Sub类对象,这可以通过s.getClass().getName()方法来得到。Sub类重写了Base类的func1()方法,因此这里在运行时,s会调用其根本类的即Sub类的func1()方法,而不是Base类中的func1()方法。这也是面象对象多态的特性之一。

编译时往往检测的是代码编写是否违反语言规范,而运行时指的是对象的动态执行过程。理解编译时与运行时有助于对我们对继承与多态的理解。

使用Xmind思维导图工具

最早知道这个工具是在公司的ITIL培训上。培训导师在讲课的同时特意引入了这个工具,说得非常简单和方便,一个tab加enter键就是基本完成所有的操作了,一定让我们在课下或是工作中好好的用用。但最重要的不是工具简单,而是这个工具能将你的思维扩大,能够激发你的大脑视野。最直观的是从你原先线性条带的要点,转换成图形,表格,鱼骨,甘特图的样式。让你记忆深刻,同时在观察分析图表的过程中,能找到问题的重要点,划清主次,找到问题的解决办法。

这个工具有免费的,也有收费的。大部分的免费功能还是能满足日常基本的要求,比如思维导图,组织结构图,树状图,鱼骨图等等。在没有使用这个工具之前,在学习或是看书的过程中,我往往都是流水的形式将重要的概念以多文本的方式记录下来,而简单重要的词汇概念在单行的记录中是看不出明确的意义的。而在Xmind思维导图中,一个概念,一个重点词汇在这个图中,它所代表的含义反而得到了鲜活的体现。任何在导图中出现的词语都可能是非常重要的,有明确的含义,都有其上下文关系,好似时空中的一个点,与其它各个点关联在一起,深深嵌入你的脑海,就像一个立体的空间那样令人深刻。一旦你的思维存活在这个立体空间里,便可以游刃有余了。

最早下载使用这个工具是在我的一个旅行计划里面。从旅行计划的时间,地点,人物,交通工具,住宿,景点,用餐等等计划安排上计算了旅行的大概费用。虽然这个计划最终没有实施,但仍让我对这个工具的有了一个直观的认识,并能让自己在分析一件事情上如何考虑的更加全面。第二次用这个工具分析了下一个PHP工程师应该知道的哪些技术,并以此来判断自己应该在哪些方面下工夫学习。这对制定目标与计划有很好的帮助,也为我后来制定2016年度计划提供了参考:如何分门别类,如何分析工作量与可行性。用Xmind制定工作计划的时候,可以加入各种图标,比如完成进度,优先级,表情,月份,可以标识结点间的关联关系,让图表更加的鲜活和有价值。以往在学习看书的时候,往往如之前所述的那样逐行逐句记录本文,或是拷倍作为读书笔记。如今,我在思维导图上以大纲的形式将之记录,将各个要点串边起来,从而书本的纲要都呈现出来。在回顾的时候,只要根据纲要分别各个击破,书本的知识就能全盘掌握了。这种纲要也更易于选择性的学习,将那些熟悉的知识快速略去,再深入那些未完全掌握的知识,从而让学习变得更有效率。

除非你认为你需要更强大的功能,那么收费版本可能更适合你。习惯免费的我一时不会去花这个钱,也许有一天真正需要的时候,我也可能成为一个付费的用户。有的时候,我们很执着的用着自己熟悉的方法去学习,而对他人的建议不管不问。但真的有时候,一个好的工具能让你变得更有效率。只是,能提醒告诉你的人可能很少,而当有人真正告诉你的时候,千万值得去尝试一番,也许他真能给你带来翻天覆地的变化。

春节二月记

随着年龄的增长,节味的感受却相应的淡了。而越来越知事的女儿却在这个春节玩的不亦乐乎,戴着她妈给他买的飘逸的披风头箍,活脱像个美丽公主或是仙女,久久不愿取下。女儿大了,她有她的小伙伴,也不会像更小的时候那么粘你。而自己却也没怎么玩,一来自己不便参与各种赌局,二来乡下条件有限,也没有什么娱乐活动场所。过年的天气到是大好,多半晒晒太阳,乐得清闲清闲。

假期过后,便直接回了杭州。春节额外的休假对我们而言是一种挺奢侈的行为。一来一年中可用的假期本就是寥寥,二来未知的各种琐事,杂事所需要的时间都要预留起来,不便在年前便休完了。节后上班心是浮的,很多同事还在休假中并没有回归,各项工作还没有走上正轨,所以也乐得自己学习学习,看看一起基础,以备今年的各种变化。

针对这些变化,还是要做些充足的准备。现在却有些迷茫于到底是.NET还是Java。前者稍微熟悉一点,后者刚入门但想继续学习。只能让机遇去决定一切。多多学习与准备总是没错,看了些面试的书,又刚看完了《Agile JAVA》,算是入了门吧。之后也是全面铺开Java的学习啦。而.NET还是要去保持的,忘记了的内容应该补充上,不能捡了芝麻,丢了西瓜。总之,做充分的准备,然后努力去实现更高的目标。

我总是想现在的工作并未能激发自己的能力,甚至想抱怨现有的项目是如何的缺少活力而变得毫无吸引力。我更乐得快速完成分配给我的功能后,去学习一些知识和技术,做点自己喜欢的事情,写写博客也很好。因为这能让我有个短暂的思考,思考我需要什么,我应该怎样。也许春节的结束才真正意味着新年的开始,所以我也要奋发一番,为下一段历程做最充分的准备。

Agile Java学习笔记

从开始做一些Java应用程序开始,却没有完全的仔细看一本Java基础知识。网上找了很多,要么太厚,啃起来费力,要么评价不怎么好。直到看到《AgAgile Java Crafting Code with Test-Driven Development》,评价也不错,还是以测试为驱动的(之前并不了解何为测试驱动开发)。因而就有了很大的兴趣去学习。在学习的过程,也使用XMIND来记录一些重要的大纲,这样就可以一目了然了。下面简要示例之:

测试驱动首先从Junit开始,熟悉一般的TestCase类的写法,会写可测试的test方法:public,void返回,方法名称小写test开头,不带参数。jUnit中的setUp方法,可以初始化一些通用的成员变量,从而减少每个测试方法中很多相同的初化代码。jUnit会在每一个测试方法执行前,先执行这个setUp中的代码。各个测试方法中用到的setUp中初始的对象是不同的,彼此也是不公用的。

Java中构造函数的默认访问权限是public,如果类中没有构造函数,Java编译器会自动为类添加一个默认构造函数。如果父类有一个带参构造函数,则子类必需声明一个构造函数,用来调用父类的某个构造函数。如果父类有带参构造函数,子类想默认调用父类的无参构造函数时,父类需要显示声明这个无参构造函数,反之则不需要。

成员变量可以在声明的时候初始化,也可以在构造函数中初始化。但是并非所有的成员变量都能够在构造函数中初始化。比如引用类型的变量,如集合等往往在成员变量声明的时候就初始化,这样在构造函数中这些成员变量就可以直接使用,而不会出现空指针的错误。

Java中的包名通常都是小写的。牢记保持类的功能单一性。

final修饰符表示变量的指向不能够改变,即不能指向另一个值,如果是引用对象,对象的内容是可以改变的。

import可以一次引入某个静态成员变量,但无法一次引入所有的静态成员。如import static sis.report.ReportConstant.NEWLINE;

在Java中单精度数必需以f(F)结束,否则默认是双精度浮点数d(D)。大部分的浮点数都是一个近似值。switch可以用在enum类型上,当然还可以用在int,char,short,byte等类型上,但无法用在long与String类型上。switch的分支最好不要太多,如果很多,可以考虑用多态的方式来处理。enum枚举类型也可以有自己的实例变量,构造函数,也可以定义成员方法,就像其它类一样。对enum的限制就是其无法像普通类一样扩展。

模板方法就是在基类定义一个方法,但这个方法的调用要根据对象的不同,调用不同子类的对该方法的重写方法。

除去这些,陆陆续续在XMIND上记录一些Java的其它特性与功能。equals与hashCode方法等引出的其它特性与功能。相对应的也将这个表格图上传到我的微博。后续也去看看一些Java的面试题,来进行一些查漏与补缺,进行知识的回顾与完善,并加大对多线程,IO方面的知识学习与掌握。从而将Java的基础学扎实。

Agile Java 学习笔记
Agile Java 学习笔记