Java快速教程

Java快速教程

作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明。谢谢! 

Java是一款面向对象语言。Java语言于1995年出现,由Sun公司出品。James Gosling领导了Java的项目小组。该项目的最初目的是为家电设计一种容易移植的语言。Java在获得了Netscape浏览器支持后,随着Netscape的流行而得到推广。Java现在属于Oracle公司。

Duke,Java吉祥物

Java的设计受到C和C++的强烈影响。Java语法与C++相近,但Java中移除了C++中容易出错的一些特征(指针,多重继承)。Java的垃圾回收功能可以有效管理和清理内存,将原先属于程序员的清理内存工作转交给编译器,从而减小了程序员的编程负担。Java语言具有良好的可移植性,JVM的运行机制让“一处编译,处处运行”成为现实。这对嵌入式和移动开发,都具有重要的意义。

Java程序员是一个庞大的群体。近年来,Java在服务器端和移动端(Android)都有不俗的表现,吸引更多的程序员加入到Java的队伍中。Java程序可以实现高产出,同时具有相当不错的运行效率。Java又是一门完全的面向对象语言,所以是了解其他面向对象语言的一个好范本。

我在这里呈现一个快速的Java教程,以说明Java语法中的核心概念。基础部分将专注于Java作为面向对象语言的最重要的一些方面。希望对大家有用。

Java基础01 从HelloWorld到面向对象

Java基础02 方法与数据成员

Java基础03 构造方法与方法重载

Java基础04 封装与接口

Java基础05 实施接口

Java基础06 组合

Java基础07 包

Java基础08 继承

Java基础09 类数据与类方法

Java基础10 接口的继承与抽象类

未完待续……

作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明。谢谢!
 
 
标签: 系列索引

对TDD,Unit test的看法

 在程序开发中推行TDD似乎是一件不容易的事情,有的人很热衷,觉得这是拯救项目开发质量的利器,有的人不屑,觉得这不过是给没安全感的人心理的安慰。

  很多东西能不能推行就看能不能制定相应的政策进行约束,政策能不能制定就看项目需要不需要。

  我们到底想要从TDD中得到什么?unit test能够保证写出来的代码达到质量要求吗?unit test要做到多细?由此带来的额外时间开销是不是能够接受?

  项目开发通常陷入debug的泥潭,古来如此,但原因却常常各家不同。

  有的可能是开发人员水平不足。

  有的可能是开发周期太短,赶工。

  有的可能是项目过于复杂。

  有的可能是因为项目建立在原有的项目基础上。

  TDD会是万众期待的救星吗?

  就我自己的体会来说,我觉得TDD并不能拯救项目。

  原因有几个:

   1.只有要经常改动的地方,才应该加入unit test,但这种常常需要改动的code往往十分不容易加入test。

      经常有时,code一改动,unit test跟着改动,unit test的作用只限于当次迭代,这样的test意义何在?

   2.大项目里,代码类,函数之间,通常依赖严重,打破依赖是TDD的前提,但这个代价往往很重,甚至让人望而生畏。

      而且这般改动也常常带来难以忍受的副作用,如,让代码变得分散,逻辑更多,更难理解。

   3.能够测试的代码,通常不容易出问题。

     这点是很矛盾的,比如数据库,GUI相关的代码,容易出问题的,往往不是背后的逻辑,而是数据库,GUI。

     而这些涉及交互的,基本没法加入unit test.

     对于容易加入测试的代码,用写test的时间拿来自己测试,也能保证程序的正确性了。

   4.测试用例有时难写全,写代码的人,如果没有意识到自己代码里的错误,他写的测试也倾向于遗漏这些关键点。

  

  很多时候,我们寄希望于unit test能检查出我们的修改带来的问题,这个愿望是十分美好的,但不容易实现。

  写程序是一种创造性的活动,很主观的事情,难以像流水线上的工序一样,机械的加以把控。

  

  如果只是纯粹出于对代码质量的要求,code review更能发挥作用。

  程序员主观把握自己的代码的质量,能更加有效。

  TDD的推行者,Kent Beck曾在stackoverfloat上回答过一个关于unit test要做到多细的问题:

  http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests

   他的观点让人有些跌眼镜:老板请我来做开发不是来写测试,要尽可能少Unit test,写出自己有信心的代码

   这里的观点是比较内涵的,如果你对自己的代码有足够的信心,那又何必unit test?

   但这不代表就是对unit test的否定,TDD更不是一无是处,做任何事情,适度就好。

   对于TDD,不应该把它当成救星,项目质量最根本是在程序员本身,unit test某种程度上就像QA,他们只是反馈问题,并不会改善问题。

   unit test的作用应该定位于及早捉住程序员不经意犯的愚蠢错误。

   而不是程序质量的把关者。

   程序员要对自己写的代码有信心,当然这个信心不是盲目而来,这个信心来源是:严格的代码把控及code review。

  前段时间,简悦风云在微博上与网友就TDD有一个讨论,他的观点,我十分的认同:TDD不是救世主,不能为了test而test,反而容易把人的创造力限制了。

  

   

 
 
分类: blabla
原文地址:https://www.cnblogs.com/Leo_wl/p/2992403.html