My Java Programming
Version :1.0
一．编程技巧（培养写流程——>写架构）
一．一．给代码加上注释
一个大型工程项目文档可能要上万页，当然它不可能是被一个人完成的！即使个人完成我是不会相信他有这种能力：记忆每一条代码语句的作用的！一个高级程序员的出现，我相信他们都应以万行为单位抒写代码后才达到这种成就！在本文档中我们就不要考虑那些卓越的特例人物了！那么在你开发一年的项目后让你去看你年前写的代码时！假定你没有写注释，我感觉不仅是别人，就连你自己也会指责为什么不去写一些注释!人应该适当保守一点，如果你谩骂的话，骂到自己会出笑话的！
所以，我们抒写代码一定要加上注释，看看开源项目的代码注释和java的源码，注释的内容要比源码多的多！可以这样考虑，很多人的思维习惯是大相径庭的，但每个人都会有自己的特点，以及不同于其他人考虑事情的方式、方法，你所抒写的程序不加以解释，让别人去花一些时间去理解你的程序，假如写的不错也罢！如果看来看去很不值得一看你会遭到指责的！还是抒写我们的注释吧！
基于团队合作的角度考虑，我们为了让工作更有效率，让我们的同伴更好的加和我们的优点去发挥到极致，这是我们合作的最终目的，我是这么认为！那么在这其中注释有它不可磨灭的作用——与人进行信息传递！
一．二．给代码分段缩进
无论是你写java代码以及javascrip、css、标记语言还是其他，都希望你会出现段落的提示信息，不是去抒写出段落信息，而是你代码风格让人一看就知道哪些成分是一个逻辑单元！思考的时候也把此模块往一起去想！
一．三．使用空白
域（属性）之间加一个空行，方法之间加一个空行，努力这样去做你的代码将会被人传阅，即使你的业务逻辑不是完美无瑕！想一想当你的师弟师妹或同组的搭档，在看你的代码，由于你的代码不美观而给你一种不好的评价你将多么的悲哀啊！
一．四．遵循10秒法则
学习期间有些程序员会以抒写出复杂的代码为荣，别人越看不懂我越牛，这是错误的！因为这样不仅不能保证拓展性也不能保证维护容易的目标！我们应当遵循10秒法则，让你的搭档在10秒钟之内能看懂你的函数逻辑！不仅简单明了，而且，易于维护和拓展！当你在写每一个方法的同时都去考虑这一点，我相信在不久的将来你将会成为一个不错的高级程序员！
一．五．说明消息发送\运行的顺序
这一点类似流程图的作用！如果你明白流程图的作用那么你只需把流程图的图解翻译一下就ok了！虽然，怎样写也不如流程图看起来那么直观，让人容易理解，但我感觉在你的逻辑体写上这样的注释，是一个非常不错的方法！毕竟代码里面是不能画图的嘛！
在程序块出现错的时候我们将会轻松的定位错误，并把它解决掉。想一想当你的主逻辑程序出现错误，你此时又累又饿又困，但项目必须今天完工明天一早上线！在这上线之前出现了逻辑错误！你在一步一步的debug．．．．．．将会多么的痛苦！我的很多朋友在项目开发都遇过这个问题！
写上这个关键的东西吧！你可能没遇到过另外一种考验!你做的项目是严谨性要求极高的项目工程，在开发、测试、乃至试运行一年半载都没问题这显然让人很高兴！假如在投入正事运行第一天出现了系统错误！出错的程序块是你写的，从打电话通知你到问题解决给你30分钟时间解决掉，否则全面下线，这时你什么感觉？没时间考虑其他，客户更不会听你的解释，唯一的办法是解决问题，否则后果自负！当然这样说严重一点！你在这种紧张、身负重压之下想很快解决掉这个bug，此时我想你最先想到的是你写的这个东西——消息发送、运行的顺序（注释、文档）
一．六．写短小的命令行——帮自己理思路、分析问题
在抒写代码时有很多程序员不注意一些小细节，所写的每行代码夸张的说要比火车还长！假如你用MyEclipse或其他工具请你调制一线编码格式中的单行字符限制数，单行代码不要超过80个字符，最多不要超过100个字符，而且当你不能设计出经典代码的情况下尽量少用三位运算符。
因为，我们要做到10秒法则，我们要与人合作！如果你的代码写的过长，一个Window都不能完全显示你的单行代码的时候，阅读者还要横向拉动滚动条来看你的代码！我想一个一目10行的高手看了你的代码也不会在10秒钟的时间里看懂你的程序！
二．遵循标准（有成文的标准以及不成文符合大多数人思维的标准）
二．一．理解标准
拿到项目开发文档后，我认为第一件该做的事就是看项目开发文档中的编码规范文档! 希望你自己已经有了一套自己的，不成文的开发规范！而且是默认的遵循java行业开发规范的，那么，在进行任何其他项目开发时，你所接到的项目那些规范都会使你感觉是自己的默认规范一样，你在开发时也不会花过的精力到理解标准，也不会按照标准去被动的去实施。每个项目都会有它的特色，标准不是一成不变的，所以你在接到一个项目后必须很快的弄清那些有异于自己习惯的规范，并理解它！
二．二．信任这写标准、写代码遵循标准
项目开发标准（文档）到手后，你必须将它变为自己的标准来实施！我们是在给别人打工，为了达到最好的配合效果去掉我们自己不入格的刺吧！
二．三．有好的标准提议要在项目开始前提出来、而不应是一个事后的想法
有时，明知道是错你是不能以一种旁观无责的态度去面对这很差劲的规范的！除非你不想在这个公司久留，或者你认为公司倒闭后你会更好！！如果你以前开发有过不情愿，那么在这个项目中你看到了不好的规范、标准，你的想法是应该提出来的！努力去和你的上司“争吵”！并获得胜利！千万不要在项目因为这些标准引发问题而你来一个马后炮！
二．四．是他们成为你质量保证的过程
现在无论是你的提议标准，或者是文档的标准！你都要去默默的遵循它。因为有了它，也就是标准，才会使多个人的配合达到代码好似出自一人的效果，合作成功。在每一步代码书写中遵循它，使你书写出合格且高质量的代码！不要背道而驰，即使你写的代码相当漂亮，否则你会看到被人指责谩骂并毫不留情的删除自己的代码的窘境！
三．重要注意事项
三．一．面向人而不是面向机器抒写程序
项目工程和人一样是慢慢张起来的，在程序的实施过程中有大的模块和很多小的细节需要我们去详尽的设计！而正确的实施规则是写出符合人的惯性思维的程序逻辑！也就是说向本节这一点所说，面向人而不是面向机器写程序！当我拿到一本书的时候也会先看看它有哪些章节！然后再挑选自己心仪的章节仔细阅读！所以你在设计时也要先搭起它的功能模块（框架），同时，不追求复杂的程序代码，不盯于小细节上！做到这点你将成为一个高级软件工程师，并向合格的架构师进军！
三．二．首先设计然后编写代码（详细设计）
这样做符合工程本身规律、而机器也是响应你的设计后才运行程序。在项目实际开发中我们也是这样干的！参见软件工程流程图：
整体项目这么干，我们在写功能模块是也要这样干！抒写成员方法也要这么干！
在抒写某个类或成员方法的时候，希望你已经遵从了我的这些规范，那么你会知道这里应该怎样去写精简的注释，并知道开始着手写消息发送运行顺序！参见如下：
Eg1：
<!--[endif]-->
Eg2：
不要吝惜你写注释所花的一点点时间！它是帮你理清思路的重要手段！无论是在前期开发，还是在后期的维护乃至将来的拓展都将伴随着你。我们在编程中经常接触注释、写注释，那么就一定要写好他们！
这是你写程序应遵从的流程，在实际中有很多程序员做的往往相反！他们的步骤是首先写出代码。等写完一个类或方法的时候觉得不写注释不合适就写上一些注释——这是翻译代码的过程！不是用代码翻译你的思路的过程。你要知道我们写程序做软件是给人家做，给人家看，满足别人的要求，挣取别人的钱！两种不同的注释方法将把人往不同的层次引导！要成长就在你写程序之前写上你的设计思路吧。
三．三．一小步一小步的开发
前面已经再三提到过这一点：软件本身是成长起来的、拆分小的模块去开发！纵观现在流行的软件、网站都会看出当初那种可笑的瑕疵，前提是你现在有一定的水平和阅历！做软件写程序要不断去完善，不断去修改，不断去总结的！要知道好程序是改出来的！而不是一气呵成！想一想当初的Win98和现在的vista在方方面面都在变化！这些变化就在于微软公司的努力——完善、修改。。。。。。！而且vista的性能并不能让我们很如意！所以，我们在写程序的时候也应该持这种态度！一小步一小步的开发不能急功近利！更不能懈怠，不断去改进，不断去完善！毕竟软件是不会产生完美的！假如，人们作出的软件方方面面都是完美的那么我们就不必在步入这个行业了！那些黑客也就会消失了！
三．四．让代码简洁
考虑单位时间内代码传递给人的信息不要太多（这是一个让人敏感的程序设计原则）。做到这一点：让你的代码简洁吧，同时功能完善。就象表达我们的思想一样，言简意赅会让人拍手称快！
三．五．学习常用的模式、反模式和代码模式
模式的产生是在项目实施中分工越来越细的情形下产生的！模式是人们所推崇的一种种程序设计形式！就像脚下的路，有的路被开发后走的人不少，并且这条路很不错，那么相应的模式也就生成！
模式一：JSP+JavaBean起初运用不错！但是随着软件技术的提升它暴露出来的缺点得到解决后，模式二：ＭＶＣ就取而代之！并且设计模式在飞快的演化与发展中！作为程序员，我们应该对新出现的技术敏感！不排斥新东西是我们获得更高成就的保证！所以我们一定要学习常用的模式、反模式和代码模式！新技术出现我们也必须去参透它！摄取它的精髓！
四．命名约定
四．一．使用可以准确说明变量、字段、类的完整的功能性质的英文描述符
做到这一点被很多程序员看来很难的，尤其是对一些英语水平不好的程序员来说这无疑是难上加难！但不能因为这一点就降低自己的标准！ 努力去完善，写的多了，选择也就会明智了！指定功能的方法、特定含义的域（属性）好像总有几个可供选择的英文描述符！那么简单的参考下面的标准：
用合适的动词控制合适的名词，类可以是名词性质的，也可以是动词性质的，方法为动词性质的，域（属性）为名词性质的。在java的面向对象程序设计思想中我们可以参照这一标准去实施命名与设计。
使用java源码中的一些命名习惯，添加-add***，截取-substring 等这些习惯。还有很多，这需要在编程中多多留意，写的多了，看的多了命也就会相应的变的轻松！写出的名字也会让人感觉标准、规范。
四．二．采用该领域的术语
这一点很重要，也就是说你在熟悉业务背景的时候就应该了解这个项目领域的专业术语，牢记他们并运用到你的程序中，让业务员看的轻松。希望你在熟悉业务背景的工作中同时干的出色，做到：比业务员还要熟悉业务逻辑！
四．三．采用大小写混合，提高名字的可读性、提高名字的自解释性
这是有名的骆驼命名法，结合本节第一点做到程序的自解释性。也就是常说的命名直观。通过字面意思就能知道其功能作用。一些错误信息字符串全部大写！接口内的域（属性）或者说常量要大写等一些规定见请查阅资料！
注：有精力多看看一些开源项目是一种很好的提升办法！
四．四．尽量少用缩写、使用一定要谨慎
一般采用缩写都使用那些成文的或不成文的规定中经常使用的缩写名称，象下面的例子eg：
<!--[if !supportLists]-->u <!--[endif]-->i18n -- internationalization
<!--[if !supportLists]-->u <!--[endif]-->log4j -- logforjava
<!--[if !supportLists]-->u <!--[endif]-->hibern8 -- hibernate
使用缩写英文字符进行标识的时候要注意一定不要自己一意孤行！想怎么写就怎么写！到头来只有自己知道是什么意思其他人都看不懂,要清楚的知道，软件行业是一种软服务行业！写程序做软件都是给别人看和用的！不采用标准，不入格就可能意味着淘汰！
注：记住那些经常出现的缩写，象上面的例子！通过开源项目或专业文档扩充自己缩写标识符的词汇量。
四．五．避免使用长的名字，最好不超过15个字符
这一点是一个不成文的标准！但是在日常学习和工作中当我们接触到开源项目源代码的时候，我们会发现有些地方这个标准并不是被贯穿的那么死板！基于自解释性的考虑有许多命名远超于这个字符数限制的地方！但为了达到总体的好效果我们最好还是认同这个不成文的标准吧！
四．六．避免使用相似或者仅在大小写有区别的名字
写过十几个乃至几十个文件并且命名不标准的程序员经常这么干！把类、方法、域（属性）等的命名仅在大小写上存在差别，或者命名与关键字、已有类，隐式对象仅存在大小写差别！这样抒写程序是很不好的习惯！程序不大我感觉你就会被自己写的代码搞的晕头转向，并且当你在以后的日子里回顾你的代码时，你想再读懂自己的代码也会比较困难。
四．七．避免使用下滑线
针对于这一点的考虑只是在开发效率抒写代码的速度加以限定！其实可以看出用骆驼命名法可以满足大部分情况，一些特殊的运用不做考虑！
五．注释约定
<!--[if !supportLists]-->l <!--[endif]-->注释应当增加代码的清晰度
<!--[if !supportLists]-->l <!--[endif]-->如果你的程序不值得注释，那么它也很可能不值得保留和运行
<!--[if !supportLists]-->l <!--[endif]-->避免使用装饰性的内容，也就是说不要使用象广告横幅那样的注释
<!--[if !supportLists]-->l <!--[endif]-->保持注释的简洁，最好的注释是简单明了的注释
<!--[if !supportLists]-->l <!--[endif]-->先写注释，后写代码，写注释的最好模式是：在写代码之前就抒写注释
<!--[if !supportLists]-->l <!--[endif]-->注释不仅给出代码的功能，还应给出代码的原因
