苦逼用来形容自己，是稍显偏颇了，2014虽然经历了两拨996的洗礼（年初和年末），但是技术成长确实没有想象的多，工作四年来，两年时间用来做web的后端开发，从spring、webx的源码，到慢慢深入到一些数据库中间件的使用ibatis和tddl（淘宝内部）、消息中间件metaq（淘宝内部）、服务框架HSF和其他的整个后端相关的内容，大概理解了一遍所有backend后，团队缺前端的状况逼的自己开始做frontend，使用jquery和kissy（brix），使用bootstrap，开发自己的基于raphaeljs的vnix数据绘图框架等等，对前端的正常业务开发也基本熟练。回顾2013年的总结，发现自己去年就开始有些负面情绪了，虽然接触了storm开发，正常时间写hive和odps的sql，开发数据报表，但是这些工作对于技术的直接提升并不明显。在无线反作弊领域做两年了，整个反作弊的设计架构也从最开始的统计分析发展到机器学习后来又逐渐变为混合模式，也算经历了三代的演变。乐观的审视自己这4年的蜕变，技术上的提升最大还是在2-3年的时候，现在的很多认知提升，都慢慢的转到了架构设计和团队管理，慢慢的自己开始不断挑刺了，我一直不理解我这种变化的原因究竟是什么，开始不满团队的管理模式，经常设想如果自己来干，哪些地方该优化该改进；开始不满产品的技术架构；开始不满团队成员的“不够优秀”。

         回家过了个年，胡吃海喝后，自己开始熟悉原来身边的环境，也开始能看到自己内心去了。你要做成功一个事情，这是之前在阿里巴巴的一个承诺。其实这是很难的，不仅是阿里，你在哪家大公司都很难。那么发泄不满是最低效最没有品位的做法，你只能让身边的人知道你不满，但这重要吗？The thing is to acitvate them。一个卓越的人，首先要能包容自己对身边的不满，我们不乱发泄，我们沟通，我们建设。要做成一件成功的事，不是要和一个完美的团队配合，而是要能配合出一个完美的团队。能容别人所不能容，能帮助别人成就别人。

        2014整个一年我自己总结就是懒惰的一年，这一年，我没怎么读过书，没怎么关注过新技术，没怎么写过有趣的代码，反而还经常玩手游，跟人诉苦水，传播负能量。人生苦短，在即将30岁的时候，我却开始纠结一些芝麻绿豆的事情，工资高低啦，晋升啦？These all shit。新的一年，自己要有远大的目标，我一定要做成一个事情，而为了这个目标，要持续学习、读书。记得小时候，每到寒暑假，都会把整个假期及未来学期的计划写清楚，虽然那时很幼稚，计划总是什么几点睡觉，几点起床，读哪几本书之类，但是这种习惯，在我们长大后却逐渐褪去了，我们成了没有目标的混日子的混子。想起Fenng之前的一篇文章，讲大公司的混子，还真别说，大公司最多的就是混子。

        不要拘泥于要成为什么样的人，只要知道你要做成什么事就够了，因为只要你努力为这个目标奋斗，你就会成为一个能做成这个目标的人。That's enough。

为什么会这样，我想这个和我最近痴迷橄榄球NFL有关（怎么这个句式特别像广告呢）。年初的超级碗全场录像把橄榄球运动拉入了我的视野，随着2014-2015NFL新赛季的开始，我也开始关注NFL，美式橄榄球是项非常棒的运动，为什么这么说？运动本身有几个特点非常吸引人：1）高强度身体对抗——无疑这是一项男人的运动，比赛中最常见的就是身体接触。2）规则和体系非常合理，橄榄球的进攻防守规则是非常合理的，进攻组司职攻城略地，而防守组负责守卫家园，这个对于原始的战争游戏模拟的非常到位。3）策略和战术要求极高，橄榄球进攻和防守战术非常多样化，进攻端可以采用地面冲球和传球，传球的话又可以分远距离、中距离和近距离传球，传球的对象，也可以是外接或者跑卫，外接的跑动路线……说不完啊。4）数据拟合准确，当然这是让我最痴迷NFL的原因，美式橄榄球把数据运用到了极致，对于球员的指标衡量非常的准确形象。

比起拳击那样的攻击与防御，它显得安全了很多；比起网球、乒乓球这样的球类运动，就相当的刺激荷尔蒙；比起足球和篮球这样的流行运动，橄榄球的规则和完整的体系以及无可出其右的策略性，是最吸引人的。当然足球的魅力在于团队配合可以打得非常精彩，同时个人英雄的出现也可以拯救世界，但是足球里衡量运动员综合素质的指标体系实在是不够好。我个人认为像橄榄球和棒球（NFL和MLB）是最好的数据决策运动体系，好笑的是这都是美国人为之疯狂的运动，而在世界上其他国家却知之甚少。

结合橄榄球运动和数据体系构建，确实给了数据从业人员很大灵感，玩NFL Fantasy的玩家都知道每周的Pick’Em可以来预测比赛，要知道一周15场比赛完全猜对的人非常非常多，为什么？因为数据刻画形象且透明，也就是说，我们做预测，不在于算法有多牛逼，而在于指标是否足够好，模型是否足够清晰的能刻画业务本身。这是我一直在做数据挖掘强调的，但是仍然有太多太多的人纠结在算法中不能自拔……NFL有一套自己的rating算法来评估球员的素质，当然这在FM游戏里也有，但是我个人认为NFL的计算更合理，因为橄榄球运动目标性非常强，没有像足球那样过多的回传和组织，橄榄球单箭头的向前就是最好的约束条件，这为数据可操作性提供了基本保障，我个人是这么认为的。另外NFL联盟的运作也类似一个数据体系，联盟约定工资帽，不会出现过分的强弱队之分，一个队伍都是明星大牌，工资帽不允许啊，所以NFL的32支球队，大体水平相当（当然有弱队和强队，这里说的大体相当是指在一场NFL比赛预测中，没有那么明显的胜负趋势，优势微弱=属性连续、分布完美）。另外不同的战术相生相克，在场上随时可以通过暂停来及时调整，这是小步快跑实时运算的等价比喻，足球比赛一开场就至少踢45分钟，这是典型的批处理，教练有个意图都是大声喊，也不见得球员遵循，但是橄榄球就完全不同，每次攻守基本都是战术的完整体现。说起时间，因为足球篮球是连续比赛，而棒球和橄榄球则是分档进攻，这其中的区别体现在数据的可分析性以及一次操作的影响性分析上，其实是很明显的。足球的连续比赛，导致我们在分析一次进攻的成功因素时，需要考虑的变量非常的多，因为时间窗口太大——45分钟，而橄榄球是阶段性的，一次成功的推进，一定是经历一个开球-传球或跑球这样的流程，这明显是规格化的产物，谁告诉你足球进球一定要是本方守门员大脚开球到前锋射门呢？所以对于橄榄球这种阶段性运动，一次分析可以根据本身的进攻和防守阶段被拆成很多的细片，在细片上完成分析，这也符合分析的规律——样本干净且完整。这有点像分布式计算，橄榄球天生分布式，而足球只能一把搞到内存里做完全分析……

胡乱扯了一通NFL的东西，美式橄榄球运动是项极度体现智慧的运动，结合数据去玩Fantasy，更觉得其乐无穷。

回头有空，再详细举例NFL的数据故事。没准也还聊聊手游和数据的事。

    2013已经成了历史的一个数字，在各种数据总结、趋势图表、红包鞭炮、酒席宴请弥漫的后春节状态下，终于回到公司，坐在清冷的办公室，冲一杯咖啡，键盘和聊天声中，开始静静的回忆过去的一年。

    3年一个坎儿，也许不假，2013是我最频繁想起跳槽、转行、辞职的一年，为什么？我把它归罪于3年这个坎儿。工作3年整了，在一家公司，一个部门，做着很多类似的事情，有这些想法……正常。先插一段故事，从年前到家到年后的各类聚会，总结起来比上班还累，天天吃肉喝酒，处处谈论着本不感兴趣却不得不谈的现实，开始总跟人抱怨在外地工作辛苦，天天加班拼命，上班路堵不方便，生活成本高，周六日没休息等等。后来所见所想，看着各有各的辛苦，各有各的烦恼，明白抱怨解决不了问题，抱怨只会让大家知道你在外面混的很苦而已……徒劳的。回到正题，总结2013，先谈积极的，生活上，孩子健康成长，父母健康平安，房子按期装修，一切都正常运转按部就班，只是花钱如流水，年底混个0的开始，不过还是很欣慰，一切蛮顺利的。总结总是谈工作更多，那我也就更多的说说工作。

    工作好像不那么顺利了，进入了一个很奇怪的循环，也许别人不觉得，但是我自己把现在的状态称作一种尴尬的境地。这一年，在互联网技术这个圈子里，我尝试了4种岗位，2013之前，我是一个专职的Java开发工程师，我关注的是服务端应用的架构设计、代码质量、并发和可扩展，但是到2013年底，我感觉自己成了一个时下流行的ASE——全栈工程师（All Stack Engineer），这种转变是因为团队缺乏“资源”而被逼出来的，年初产品改版，全站大换血，没前端资源，没办法，在借了个前端做了2周demo和组件的前提下，我带着一个开发兄弟“成为”了前端，写js，写css，后来css变成了less，js也需要自己做前端组件，1个月后，我们真的成为了前端，这时候的我，开始关注数据可视化组件（了解d3和raphael），前端模块化（seajs），前端开发模式(前端OOP)和架构等，看两遍犀牛书已经满足不了我的需求，更多的js书籍进入了我的reading list。项目在快速的迭代后进入稳定，新的需求也可以快速的被完成（因为我们俩已经算是前端熟手了），而后开发人员补充一倍，机器扩容，一切看上去都开始正常。这时一个新的数据项目起步，再次面临“资源”紧张，不过这次缺的不是software engineer，而是data algorithm engineer。于是我也重复了这次紧张，进入到数据开发的角色中。数据开发其实是个有意思的角色，关注点主要是写sql，但是在大数据背景下，hadoop要非常熟悉，要理解整个生态，数据开发不是单纯的ETL，写写hive或者pig的ql，而是在结合业务的前提下设计出出色的数据架构，数据架构看上去很虚，但是其作用不亚于软件开发中的架构设计。从某种角度讲，在大数据背景下，好的数据架构起到的作用更大，直观上讲能节省大量的成本。本来数据这块角色可以分很细的，但是同样由于“资源”的问题，我承担了全部的工作，当然学习起步阶段得到了不少同事的帮助，同时也得感谢公司的大数据平台的简单易用让大数据这种比较有技术含量的东西可以轻易的被工程师使用。总的来说，2013后半年进入到数据领域，开始各种数据开发尝试。这一切看上去还挺不错的，但其实麻烦在于业务，业务发展过于变动和快速，导致工程师做东西都是填补型甚至是一次性产品，比如前后端开发成了copy&paste，数据开发沦为了copy&paste型的ETL，结构层次不清晰，毫无架构可言。在短时间内开发高质量产品本来是个悖论，又经历长期的加班和强制性的公司政策，这是在束缚创造力和打压创新精神……

     于是，作为一个ASE，我们可能热衷于一切可能改变世界的技术，但是产品落地一定依托于某些业务，而业务往往是关键点，所以，真正的循环悖论是我们在不断的重复失败的业务，而技术的轮子由成功的业务驱动，于是周而复始，眼见别人的成功，而无能为力改变自己，这应该算是某类工程师的悲哀吧，我们可以轻易的实现各种算法，可以写大量的Java来实现控制业务逻辑，迅速的组织页面html+css+js来可视化，可以熟练的写成MR或者hive sql在大数据平台下查找数据，甚至可以轻松的把这一切全部一肩扛起，但是~~~我们改变不了产品失败的命运……

    In my opinion，我们不应该仅仅是为了公司的股票和工资在做事，不能只是因为一次涨薪、一次红包、一次配股而努力，既然选择了，那么这是一份事业——a career not only a job。3年前我放弃导师的博士学位邀约，进入大公司成为了一名普通工程师，3年后，是否要放弃大公司的庸碌而重拾自我？忙碌过后、重新思考，如果这仅仅是工作，那么趁着还不老，追寻自己的梦想吧。

    就写这么多吧，总结这东西写起来总没个关注点，洋洋洒洒的，哦对了，最近流行的文体是北上广深究竟给了你什么？好吧，我不在以上四地，但是就杭州来说，我这3年，没想清楚杭州究竟给了我什么。但是我心中有个答案，你不在这些地方存在过，你永远不知道答案。

没有JS，只有单纯的div+css~容易上手，但是也有很多限制。不在技术上，更多的是一些适合手机屏幕的适配~

移动平台有多种，iOS, Android, WP7, Sybian …

移动浏览器就更多，我的Android手机中装了10款浏览器，分别是：原生google的，qq，UC，海豚，firefox，opera，天天，go，skyfire和x浏览器GL。

那么我们需要的适配多少呢？答案是 平台数去乘以平台版本号再乘以浏览器种类再乘以浏览器版本号~~无穷无尽啊

一些建议：仅限中低端适配

1. 尽量采用div+css结构，因为有些浏览器在有些平台上的显示是不支持table的。

2. css不要用float，不要用过多的伪类和absolute之类的position相关的东西。

3. form表单不要使用type为file的input。

4. 每行设计的时候最好数数pixel的个数（很容易计算的）

5. 被迫使用表格的话，那么请记住不要用rowspan或是colspan，部分android和sybian系统不支持。

6. 看一些已有的大型站点的手机wap站前端，去学习他们的标签设计，毕竟小团队或者个人开发资源有限，无法统计和适配多种手机。

7. 别搞wap啦，做好webapp和native，改行html5 + css3吧~~

另外对于触摸屏的出现，在head中的meta多了很多的设定，比如viewport等。

下面贴一些html和css的小tip，希望有用。

1. 浏览器是忽视所有文档中的tab，回车和空格的。

2. ..在<a>的路径中代表上级目录

3. 所有的路径分隔符都是/

4. Block型元素前后都有换行，inline型元素则没有，block型有<h1-h6>，<p>, <blockquote>，inline型有<a>,<em>,<img>,<q>等

5. Css的最近原则就是如果有多条css属性匹配，那么按顺序执行渲染，所有的conflict都被最后的规则解决。

6. Css的字体大小font-size指的是字体的高度，就是从最下端到最上端的距离。如果单位不是px而是%，那么指的是相比其他字体的大小倍数。如果父标签是10px，那么子标签应用了%或者em的就是父标签的倍数关系。

7. Line-height其实是行间距

8. Html中每个元素可以被理解为一个box，而padding就是指元素内容与box的边界之间的内间距。

9. 一个图理解这些间距问题：

10. Id属性是用来定义严格的单一元素的。你可以有很多个元素有相同的class属性，但是id只能有一个。

11. Width属性只声明内容区域的宽度。Width的默认是auto。

12. 默认的padding是0px

13. 用空格分开的css表示的是父子关系，比如div h2{}就表示div下的h2如何如何。这种父子关系是相对的，不是直接关系，只要h2嵌套在div中就可以。直接的父子关系需要div > h2{}来指定。

14. Padding和margin的省略写法：padding: a b c d是按照上右下左的顺时针顺序设定的。

15. Css优先级使用三位数排列法：000，是否有id，有则在第一位加1，是否有class或者伪类，有则在第二个数加类或伪类的个数，是否有元素名，有则在第三位加元素数。

16. 在flow中需要注意的一点是：水平的两个元素的margin是二者之和，而垂直的情况则是二者中大的margin作为间隔。换句话说，inline元素之间的margin是二者之和，而block元素之间的margin是二者中的较大者。

17. Float会将元素剥离出页面的flow，页面其他block元素会在它之下，但是inline元素会自动和float元素的边界分离。

18. 表格单元格之间的距离叫做border-spacing。

首先说说工作的流程，对于新手上路，莫名的技术轰炸我觉得不可怕，掌握公司整个产品开发流程，知道去哪里找资源，这个更重要一些。刚到这里，会感觉有很多东西要学，于是也制定了一些计划，开始学习这，学习那。但是实际工作过程中，发现根本没有时间，或者没有那么系统和完整的时间供你系统学习。时间都被打散成了碎片，要懂得利用碎片时间。这是另一个话题，但我的感觉就是一定要首先对流程掌握清楚，知道一件事分几步，每一步在干什么。也就是说，在你知道具体怎么做之前，一定要知道是做什么，怎么个流程。

清楚流程后，那么开始实际上手吧，没时间去等你全学会了，掌握了，“考试通过了”才能去开发~~这没有止境，而且不靠谱。合理的安排就是在过程中学习，利用时间片段去学习。我们现在浮在技术的海洋上，各种新鲜的东西层出不穷，若是想一一学尽，那么毫无意义，更是毫无可能。那么怎么学？一个工作流程中会遇到很多技术，这些技术都隶属于自己技术领域或者技术层面的一个特定点。那么好吧，在看着前人的结果去依葫芦画瓢的时候，去理解和思考这些技术细节所属的技术层面。然后去阅读，去查找，去弄明白这一个技术层面的概况。不需要去抠细节，这个阶段还不够。只是了解，知其然，足够了，因为罗马不是一天建成的。

清楚流程，又清楚了各个技术层面的总体概况后，那就可以有多种选择了，根据自己的业务需求去关注一两个技术点，或者是像之前一样，再遍历一遍流程中的各个技术层面，然后深挖每一个~~很多大牛都介绍自己的学习经历的时候提到过“先深后广”的路子。这个是非常好的一个方法，在一两个点上逐渐深入，慢慢成为专家的时候，再跳出来涉足别的领域，那就发现其实道是互通的~~

最后总结一下，也算是对现有流程的一个回顾：首先是产品经理设计一个产品出来，功能和外观原型展示和描述出来，我称之为模型。在这个模型出来后，要做一番评审，流程中各个可能参加的人来提出建议和意见，尤其是要和开发人员交流，讨论技术可行性。其次就是交个前端设计师去根据外观原型设计具体的外观样式和demo，产品原型像一个框架，先把地框住，外观demo像图纸，得弄清楚要做成什么样子。当然外观demo的设计也要评审，主要是产品和前端人员进行沟通，看是否符合原型设计。接下来就是开发人员开发，在已有的框架和图纸下，一步步添砖加瓦，将其实现。然后测试人员进入进行检查，就像是验收一样，我们现在都叫QA，这点确实非常符合。在保证了质量后，最后交付。整个流程每一轮都要评审，有人觉得评审是浪费时间，但是，如果没有评审机制，你就会发现生活越来越乱~~

一个产品的生产过程，就像盖一所房子，这也是软件工程和建筑工程各个环节都非常相似的一点。不同的地方就在于软件产品在开发过程中的技术细节繁杂多变，各式各样。虽然我不懂建筑，但是想必建筑应该不如软件的复杂吧~

那么对于开发的技术来说。还是前面提到的思路，先深后广，但是这个深和广的意义和界限没那么严格。不能一味的深钻一个而完全不管其他，也不能全方位覆盖而一个都不深入。具体的度就由自己把握了。

这段时间比较忙，难得一个周末的下午有空能写写文字总结。

下面就是自己前阶段做的工作的一个回顾了~

1，刚来的新人，不断学习（这是必须一直持续的事情，无所谓新旧老少）

2，理解流程，认识同事，交流培训~~

3，项目前端页面在各个浏览器上体验不一样，寻找原因并解决之

4，加入小项目，开始实战（小项目主要是改善用户体验，修改现有代码）

5，小项目2期，继续优化

6，研究型项目，后续可能应用，属于探索创新

7，前端页面设计及编码

8，友情项目帮助，主要是后台开发

其中的4和5是同一个项目，但是明显在做4的时候，只是知其然，完成功能就OK，到5的时候，新的任务，同样的代码，但是才意识到自己在之前项目中的各种不熟悉和不深入，重新深入理解，加深了不少认识，学到了很多东西。研究型的东西自己比较擅长，在时间比较充裕的情况下，很顺利的搞出demo。前端设计是自己很感兴趣的东西，也在很短时间完成了任务，同时也体验了一把项目前端工程师的感觉。友情项目说实话干着很轻松，感觉也能学习新的东西。

什么样的代码是优秀的代码？这个概念目前还没有人能确切的定义。然而广大的程序设计人员普遍都认可的一系列标准基本上从各个层面提出了对优秀代码的要求。最近在读《编程匠艺》，觉得文章都写的很出色，相比之前读《卓有成效的程序员》，该作从代码本身讲述了编程“那些事”。深受启发，写写读后总结。

http://gxgonline.bokee.com/679308.html 这里有一段“优秀代码标准”，具体限于篇幅不再赘述。只是从自己这个编程菜鸟的角度，去谈谈对编写优秀代码的理解。正如每个人心中都有一个衡量标准一样，我对优秀代码也有一个衡量的标准：结果正确的，形式优美的，性能高效的，易重用和健壮。当然结果的正确性和程序本身的性能取决于算法设计，这是另一回事，不是本文所讨论的问题，本文只讨论与代码的形式和结构有关的问题。

2. 编写优秀代码

       优秀的代码首先具有优美的样式，我想这点是所有编程人员所共识的。没有人愿意读晦涩难懂的代码，相反，如果放在你面前的代码结构清晰，样式优美，那么读程序的人想必也读的心旷神怡了。要记住一点，代码写出来并不是永远给自己看的，而且就算给自己看，也不是一直都能看的懂的。那么如何写出形式优美的代码呢？第一点应该注意的就是代码样式，什么是好的样式：一致，传统，简洁。

一致的代码主要指程序中代码缩进要一致，括号的位置要一致……其实不用细数，所有的一切关于代码的东西，都要一致。正像那些大师们说的，“挑选一种适合你的风格，然后坚持下去”，这就是一致。那么好了，有哪些好的风格呢，经典的括号位置有K&R风格和悬挂式风格，具体是什么样的，见下表：

表1. 括号风格

K&R风格	void k_r_style() {     // Do something }
悬挂式风格	void exdented() {     // Do something }

另外一个要一致的东西就是命名了，就像文章由断落、章句和字词组成一样，代码也由变量、函数、类型等等构成。合理一致的命名对于代码的样式同样重要。“恰当地命名的关键是准确理解你所命名的对象。只有这样你才能给它起一个有意义的名称。如果你不能为某个对象起一个号名字，那么你就不会真的知道这个对象是什么或者这个对象真的有必要存在吗？”

接下来说说名字，名字首先得是描述性的，单纯的字母命名是我们编程最常用的，为什么如此，我把它归结为我们初学编程时那一点点的懒惰，随便的定义int a, int b这样的变量，完成着短小的程序。但是当程序渐渐的大起来，文件渐渐的多起来，这样的变量名字显得那么的渺小和苍白而最终毫无意义。所以如果无法描述一个对象，就不要为它起名字。第二，技术上是正确的，关于这点，由于现在的编程工作大多是在IDE下进行，因此这部分的检查工作我们程序员都交给了IDE，当然如果命名满足了第一条——具有描述性——那么也基本不会违反技术规范了。第三，恰当的，恰当的命名体现在长度和格调上，也许你为一个变量起了一个具有描述性的名字并且也是技术上正确的（且符合语言习惯），但是它却长达30个字符(theNumberOfImagesInMyComputer)或者只有1个字符(a,b等等)，这样的做法是不好的。对于命名格调的理解，我想这是一个文化背景的问题，有的人很喜欢用foo或bar这样的诡异名字，这样做其实违反了“传统”原则，这个稍后会提到。关键需要记住的“了解你的语言的命名规则。但更重要的是看，了解这种语言的习惯用法。公共命名约定是什么？应用这些语言习惯和约定。”

编码要符合标准，这样就会与别人的一致，同样也会与自己过去写的代码一致。这种纵向横向的一致往往从一个编程标准开始。当然编程标准的制定也应该是尽量符合传统，这就说到第二个问题了。

不要去新鲜的创造样式，而应该去遵循传统。这样可以确保别人读懂你的代码，同时不会让未来的自己和其他人犯晕。我理解的传统更像是一种大众化，就像上面讲到命名时说的，不要用诡异的名字，foo和bar不是什么好的选择。

简洁讲的更多是一种补充。假设你自己订立一个标准的话，你遵循了传统，也一直坚持使用它，但是由于你的天才你把编程标准弄的过于复杂，这样可是苦了其他的程序员了。所以，能简洁是尽量简洁，不要追求华而不实的代码样式。记得自己以前写代码，总写一些类似于“a[index++] = some();”这样的代码。现在想想，还是改成“a[index] = some(); index++;”这样更简洁。简洁不意味着代码行数少，而是让人看着舒服。

我认为，程序员写代码就像作家写文章一样，清新的结构，行云流水的成文往往能令读者身临其境。而我们作为读者读代码的过程中，也无不希望代码优美，就像是在看优美的散文一样。其实说了这么多，无论是缩进或者括号位置更甚者是命名，这都是在增强我们代码的可读性。当你读代码像读文章一样，那时你就是一个专业程序员了，当你写代码能像写文章时，那时你就是一个优秀程序员了。

当然代码的可读性离不开注释，注释本身不是代码，但是确是优秀代码所必不可少的东西。“注释的目标读者是人，而不是计算机。”注释是一种内部的文档化机制。什么时候写注释呢？这个问题其实很好回答：当你需要解释代码为什么时，去写注释。那么如何写呢？记住几条法则，确保遵循这些法则，那么你也能写出美妙的注释。第一，不要描述代码，“一个事实——一个源头，不要在注释中重复代码。”因为本身你是在解释为什么而写代码，这是一种目的解释，而不是过程描述。所以如果你有解释代码的注释习惯，那么，摒弃它吧（当然个别难以理解的算法除外）。第二，不要取代代码，“当你发现自己在编写密密麻麻的注释来解释你的代码时，赶快停下来。”注释的字数不会太多，大量的注释看着也让人头痛。第三，确保注释有用，“想一想你在注释中写些什么，不要不动脑筋就输入。写完之后要在代码的上下文中回顾一遍这些注释。它们是否包含了正确的信息？”确保注释是有价值的，是真的，是容易理解和清晰明了的，不要用一些含混不清的俚语或个人幽默。最后，避免分心。注释中不应该包含那些陈年旧事，也不应该用各种ASCII图形来美化，因为字体宽度变化的多种编辑器可能让你这种美化丑陋不堪。同时我也不是很支持在代码块的结尾用“//end if(a<1)”这样的注释来解释。清晰的缩进和括号已经可以解释一切了。

说到底，清晰代码结构，良好的编码风格和注释，都是在提高我们代码的可读性。而我们写这样代码的目标就是代码的自文档化。我们总会在写完代码的时候，花费大量的时间去写文档，这其实从架构层面来讲，增大了耦合，谁的耦合？代码和文档的。代码一经改变，文档相应也要改变。这样的复杂关联总是耗费了编程人员大量的精力，那么为什么不去在代码本身的形式上花些功夫呢？如果我们都能编写可以阅读的代码，人性化，简单易懂，那么文档还需要吗？就像我们看书籍作品，很少见哪本小说还配着一部说明文档的。

最后，再说一说代码的易用性和健壮性。除了美观可读这些外部特性外，编写代码还应该具有易用性和健壮性。《Code Craft》里提倡使用防御性编程，并给出了防御性编程的一些技巧。当然我并不是防御性编程的fans，也不是契约式编程的死忠。只是从健壮性的角度看，防御性编程是必须的。然而过多的防御降低了代码的效率，有时候甚至是美观，这样的代码也许使问题复杂了。不管怎么说，代码的易用和健壮是经验积累的体现，怎样写出这样的代码？好吧，没有捷径，大量的编写代码并阅读其他人写的优秀的代码。渐渐的，你会发现，你的代码也可以同样的优秀。

3. 小结

       本文主要从代码的形式上讲述了编写优秀代码应该注意的一些细节。当然，代码的核心——算法没有涉及。最后的一些关于代码健壮性的认识也是拙劣有余。作为一个编写代码爱好者，写出优秀的代码是我们追求的目标。培养良好的编程习惯，掌握更多的编程技巧，不断的编写和阅读……一点心得，一点总结。

4. 参考文献及推荐阅读

[1]http://gxgonline.bokee.com/679308.html

[2]编程匠艺, Pete. Goodliffe著，韩江、陈玉译

[3]如何编写优秀代码，http://hi.baidu.com/08027/blog/item/bc30cefe78e1bf305d6008ef.html