adode AIR 午饭分歧终端机
作者：Lightning@小宝 发布时间：August 29, 2010 分类：生活 & 职场 No Comments
占位，待续
《敢死队》观后感
作者：Lightning@小宝 发布时间：August 24, 2010 分类：JavaScript学习笔记,生活 & 职场 No Comments
经典对白之一：
阿诺走后，史泰龙 说他想当总统！
李连杰的经典语录：我能赢他，我缺钱，我要加薪！从头到尾就这几句。
看过后还有意犹未尽之感，周二50元的票价还可以值得去看，第一次去ume双井店体验还可以，比我老家的影院强！
娱乐之后也不能忘记学习：
javascript练习：
var f = function g(){return 22;};
typeof g();//应该会输出什么呢？试一下吧！
替代onkeyup事件的方法
作者：Lightning@小宝 发布时间：August 15, 2010 分类：JavaScript学习笔记 No Comments
不久之前还在研究各浏览器下的keyup,keydown,keypress的不同表现。兼容性问题永远是前端开发人员的痛处, 这也成就了很多出色的前端开发者与优秀的前端开发团队。
演示Demo,这里
之后，会写几遍分析JS的文章，感谢您的关注！
有关前端文档的...
作者：Lightning@小宝 发布时间：July 25, 2010 分类：web标准设计 No Comments
前端文档缺失的原因
前端开发的文档相信大多数情况下都没有后端的服务描述详细，而大多数测试也仅仅在黑盒测试，所以很多情况下对这片文档的描述都廖廖无几。
前端开发的代码分散——没有规范化，没有很好的设计，大多数人仍以业务为主的开发方式。
测试人员对前端仍然处于黑盒测试，有没有文档都不影响到他们的测试进程。
一旦业务定型，用传统方式的文档模式，很难复制到前端开发来。——改变了开发方式（从作坊式到规范化）让人难以适应。
尝试对症下药
对于代码分散的问题需要从源头解决。从规范化开始，试点从头到尾惯穿规范化，强制的约定，使代码质量提高。
这一块需要下大力气，中间加入设计review、代码review等环节。需要注意的是粒度把控，即什么是必须的，什么是可选的，什么是约定的等有共识。
功能描述——开发前的工作，对编码者来说必须收集需求。对于使用者来说，能够知道写这个代码的目的是什么，解决了什么问题，还有什么问题没有解决，或需要改进。
设计描述——分享你的思想，这很重要，一个成熟的开发人员看开码的时候很多时候不是看你实现如何如何，而是看你的设计。
API描述——使用者快速上手。接口是代码的眼睛。命名要严谨，不能说也可这样，也可那样。经验告诉我们，接口做得不好，历史原因就会多。
demo/snippets——给使用的人copy/paste没什么不好。
使用指南——例如库的使用指南等手册。或者说一个简单的上手教程
文档该由谁来写？
从理论上看，文档都应该由编码者来写，其实不然。一个软件的周期，可以分为：开发前，开发时，使用时，测试时，维护时。
那么各时间段上应该有不同的人来参与。缩小些范围来看的话，应该将
开发前收集需求由大家参与。实现者收集后存档到文档里。此为开发目的与预期。
开发时的API描述，设计描述主要由编码者来实现。
开发后/维护时的demo及snippets可以由使用者来完善。
设计文档是否能自动化生成
代码注释(现在一般都用java doc)可以生成接口文档。
以往都必须自己画设计图，配上描述。那么理论上这块也应该可以通过注释加入设计的描述，通过文档生成的工具自动生成设计图。这样应该方便多了。
原文出处：http://www.never-online.net/blog/article.asp?id=294
代码自我审查的一些体会
作者：Lightning@小宝 发布时间：July 11, 2010 分类：Python/Java/Erlang学习 No Comments
转自：庄周梦蝶
1、首先态度需要端正，做代码的自我审查并不是否定自己，而是给自己将工作做得更好的一次机会。在审查过程中要尽量将自己作为一个旁观者的心态去审查自己的代码，尽管这比较困难。
2、代码审查离不开重构，在审查过程中发现任何坏味道都请使用重构去改善，发现缺乏测试的地方要及时补充测试，不要让BUG遗漏。
3、代码的自我审查可能不是越早越好，隔一段时间之后回去看自己写的东西，对一些设计上的选择能有更客观的评价，在审查的过程中可能需要重新去理解代码，在此过程中可以检查自己代码的可读性，并思考如何改善可读性，切记代码首先是给人读的。
4、审查过程中需要记录下一些犯下的错误，以及当时为什么会犯下这样的错误，建立自己的bug数据库，并时常review，在以后的工作中避免同样的错误。
5、代码的自我审查应该是一个持续性的过程，而非特定时间的特定行动，时常审查自己的代码，不仅能辨析自己的得失，还能够进一步提高自己在未来工作中的设计能力和预见能力。
6、代码的自我审查跟团队成员之间的相互review并不矛盾，在相互review之前做一个自我审查，有助于提高review的效率，包括可读性的提高和一些一般错误的避免。
7、代码自我审查的一些常见注意点：
（0）自认为绝不会出错，并且从来没有审查过的代码。
（1）注意else语句，if条件下的子语句通常可能是个正常的流程，而else意味着异常的情况或者特殊的场景，你可能特别注意怎么处理正常的情况，却忽略了else子句的实现细节，如该释放的锁没释放，该递减的计数没有递减，该赋予特殊值却没有赋予等等。
（2）注意空的方法，没有方法体的方法，是不需要实现？还是忘了实现？
（3）注意switch语句，有没有忘了break？这种错误通过findbugs之类的静态代码检查工具都能避免。
（4）注意大块的注释，为什么这么多注释？是代码写的很糟糕？还是遗留的注释？遗留的注释会误导人，要及时删除。
（5）注意一些看起来“不合常理”的代码，这样的代码很多都是基于所谓性能考虑而优化过的代码，这样的优化是否还需要？是否能去除这些“奇怪”的代码也能实现正常的需求？
（6）对客户端的使用有假设的代码，假设用户只会这么用，假设用户只会用到返回对象中的某些属性，其他属性一定不会用到？不要对客户代码做假设！这个客户代码包括外部用户和调用这个模块的内部代码。
（7）标注了FIXME、TODO之类task标签的代码，是否忘了修复BUG，实现功能？
（8）任何超过15行以上的方法，这些方法是否能拆分成更细粒度的方法，并保持在同一个抽象层次上？
（9）任何在代码中出现的常量值，是否应该提取出来成为单独的常量，常量的默认值设置是否合理？
（10) 任何持有容器的代码，提供了放入容器的方法，是否提供了从容器中移除对象的方法？确保没有内存泄漏的隐患。
（11）重构中提到的其他坏味道，别放过它们，但是也不要追求完美，OO不是圣杯，如果能简单的实现一个算法，你不要引入3个对象和4个接口。
（12）在review最后能列出一张清单，开列下该项目面临的风险点，并提出解决办法，然后按照这张清单去review关键代码，着重检查异常情况下的处理。风险点的review，我建议可以放在后面，在一般性错误解决之后进行，此时你对代码也将再度变的熟悉。
