2006年3月12日

制定计划是一件困难的事情(在软件开发中哪一件事情不难呢?),不只是新手,就是有好几年工作经验的人,对制定计划也颇感为难,往往随便给出个时间了事。我曾亲历过不少场面,大家对任务计划的态度很随意,对时间的估计都是随口而出的。大多数时候,管理者都会对勇士们夸几句,对谨慎者报以轻视。

 

实践证明这些计划都是纸上谈兵,有的严重超期,有的质量不过关,有的功能遗漏,很少按预期完成的。这也难怪,就是精心制定的计划都有偏差,何况是随便给出的呢。

 

这里总结一些个人经验,这是对简单任务而言的。所谓简单任务指的是能分到某个人头上的任务,不包括需要一个小组协同完成的任务(当然部分也适用于小组任务的)。

 

1.         对任务尽可能的细划。任务分得越细,考虑得越周到,遗漏的可能越少。同时我们对细小任务的估计更准确,我想这也是大家钟爱WBS的缘故吧。

 

2.         建立任务的风险列表。外在环境、技术难点、甚至近一段时间工作状态,都会影响任务的进度。风险很多,列出我们能处理的风险就差不多了,至于第三次世界大战之类的风险完全可以抛开。根据风险列表,在理想的计划上,加上一定的风险储备。

 

3.         征求做过类似任务的同事的意见。我们不是神仙,对从未有类似经验的任务,很难估计准确,征求做过类似任务的同事的意见是明智的做法,至少我们能从中了解一些潜在的风险。

 

4.         不断调整计划。计划不是不变的,早期的估计或多或少的有些偏差。随着任务的进展,一些风险的消除,以及这期间的经验积累,我们可以更准确的估计时间了。一般来说在任务预定时间过去30%左右时,重新评估一下任务计划是比较好的习惯。

 

5.         及时反馈任务的执行情况。特别是研究性任务,出现计划与实际较大差异的情况是很常见的。让你的上司清楚任务的执行情况,很有必要,一旦出现较大偏差,他可以对你提供帮助,或者对整体计划进行调整。切记不要在时间快完了,才报告出了大问题。

 

6.         计划要实事求是,不是估计时间越短越好。不要因为面子上的问题,把时间估计得过短。否则你的任务太重,不但会影响你的正常休息和工作情绪,最终无法完成时,面子丢了是小,影响整体计划是大。

 

7.         采用PSP中一些方法,评估自己的效率。记录在执行任务过程,你的时间分配情况,估计你在做某类事情时的效率,为以后类似的任务提供经验数据。

posted @ 2006-03-12 21:34 成长记录 阅读(1555) | 评论 (1)编辑 收藏

2005年12月8日

     摘要: prototype.js开发笔记 覆盖版本 1.3.1 1. Prototype是什么? 或许你还没有用过它, prototype.js 是一个由Sam Stephenson写的JavaScript包。这个构思奇妙编写良好的一段兼容标准的一段代码将承担创造胖客户端, 高交互性WEB应用程序的重担。轻松加入Web 2.0特性。 如果你最近体验了这个程序...  阅读全文
posted @ 2005-12-08 21:25 成长记录 阅读(287) | 评论 (0)编辑 收藏

2005年10月30日

日志(Log)是什么?字典对其的解释是"对某种机器工作情况或某项任务进展情况的记载"。对于应用系统来说,日志就应该记录应用系统的运行状况了。

是否需要记录日志?这个问题无需回答,这是毋庸置疑的--当然要记了。
剩下的问题就是应该如何记录日志才能确保日志具有高可用性和低耗性了。日志信息过于简化,乃至于没有日志,则用户无法找到解决问题所需的信息,进而妨碍问题的解决;然而日志信息过于详细不仅会降低系统的性能而且会使真正有用的信息淹没在文字的海洋中。

为此JDK给出了建议的日志分级标准。将不同的信息根据其重要性分级。与此同时可以根据实际需要在JRE中设置需要记录的日志级别--级别高于此值的日志才被记录。依照JDK提供的标准(java.util.logging.Level)将日志划分为OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL等从高到低九个级别。他们都分别对应着唯一的整数值,即OFF=Integer.MAX_VALUE、SEVERE=1000、WARNING=900、INFO=800、CONFIG=700、FINE=500、FINER=400、FINEST=300、ALL=Integer.MIN_VALUE。通过对java.util.logging.Level的泛化(扩展),开发人员可以在JDK提供的标准基础之上定义自己的日志分级标准。

在这九个级别中OFF、SEVERE、WARNING、INFO、CONFIG、ALL比较容易理解。

OFF级别主要用于JRE日志输出控制,表示不输出任何信息。

SEVERE(严重)级别描述组织程序正常运行的重大事件。这些事件的表述必须能够让最终用户和系统管理员清晰地了解到底发生了什么事情。

WARNING(警告)级别描述了最终用户或系统管理员维护时比较感兴趣的事件,或指示系统存在潜在问题的事件。这些事件都需要特别提醒最终用户或系统管理员注意。

INFO(信息)级别主要用于描述输出到控制台或其替代品的,具有相当程度重大意义的事件。譬如系统的心跳信息,以及其他系统希望告知最终用户或系统管理员的信息等。

CONFIG(配置)级别主要用于描述可以辅助调试解决问题的静态配置信息。譬如CPU类型、操作系统类型、内存容量、系统语言等等。

ALL级别也是主要用于JRE日志输出控制,表示输出所有日志信息。

FINE、FINER、FINEST等三个级别被用于描述不同程度的跟踪信息。这三个级别被sun分别翻译为"良好","较好"和"最好",但是笔者认为翻译为"略细","较细","最细"更合适。这三个级别比较容易使人难于区分。到底什么样的信息应该以哪个级别输出呢?

一般说来,FINE级别用于输出开发人员广泛关注的信息。包括小的可恢复的故障,潜在的性能问题、数据源连接不足、服务超时等。

FINER级别描述比FINE级别更详细的信息。包括进入/返回方法调用,抛出了一个异常等信息。

FINEST级别描述更详细的调试信息。包括开发人员在方法内为了调试方便而输出的调试信息,即某些日志分级系统中定义的DEBUG级别信息。

将方法调用/返回信息作为一个单独的级别处理是一个明智的选择。在解决系统运行问题时,通常根据方法调用/返回过程就能大致确定问题所在。

此日志分级标准被广泛地应用于中小型系统中。更详细的信息可以参考JDK
API文档的java.util.logging部分。

posted @ 2005-10-30 22:40 成长记录 阅读(515) | 评论 (0)编辑 收藏
 

只有懒惰的程序员才会去编写那些可以最终代替自己工作的自动化工具,才不会成天为了实现相似的功能去编写大段大段冗余重复的代码 - 这种代码往往是软件后期维护和重构的天敌。通常来说,由于惰性的驱使所产生出来的工具和程序将最终极大的提高生产开发的速度。

当然,对于一个程序员来说,光光具备懒惰这个要素还是不够的。在享受懒惰之前,他必须以最大的热情和最高的效率去研究解放自己的途径,比如:找到最有助于开发的工具,最能体现“一次编写,多次复用”精神的代码架构的设计。只有在这些必要的工作之后,才可能真正享受轻松编程的乐趣。

所以“懒”的精髓用一句老话来描述,那就是磨刀不误砍柴功。如果你不想办法磨亮手中的柴刀,就算一天二十四小时都在砍柴,效果也不如拿把锋利的斧头一天只砍一小时。

从这个角度来说,Google给员工的20%自由时间是完全发挥了“懒”的能动力。为了更好的享受偷懒的乐趣,员工会更加具有创造力的去高效完成自己的任务。

夸张一点来说,懒惰才是人类进步的原动力。

这一点似乎比懒更让人不能接受。在解释这里所说的笨的具体含义之前,我们先看看一个聪明人(或者说认为自己足够聪明)会做什么:

1) 停止学习新的东西

2) 不愿意用批判的眼光去审视自己的工作

第1点将使我们很难去接受或者主动的去研究一项新的技术 - 即使新技术能带给他更多工作上的便利。第2点会使我们无法清晰的分析自身工作的问题所在,要对其进行改进或者重构就更加困难。

从这两点来考虑,作为一个程序员太自以为是不见得是件好事情。由于对自身的过于自信,往往无法客观的看待自己和自己的工作。相反的,笨一点(确切的说,谦逊一点)有时候倒有助于开发的顺利进行。举例来说,当程序出现bug的时候,最好尽早承认问题是出在自己编写的代码上面而不是在于编译器(当然除非是字节高低位编码方式之类的问题,这种问题编译器会是错误的根源之一)。如果你太自负的认为自己的程序没有问题而去猜测可能是编译器或者其他的什么外部因素出问题的话,那么十有八九你会在调试过程中走上一长段的弯路。

程序员应该笨一些的更为关键的原因在于,当需要思考问题的最佳解决方案的时候,往往要求我们首先要跳出思维定式。你对系统了解的越多,积累了越多的经验,就越难走出已有的局限,可以尝试的范围就越小。相反的,对于一个什么也不懂的门外汉来说,因为没有任何失败的记忆和潜规则的约束,也就没有什么是“不可能”的,这样的大脑所能迸发出来的在专业人士看起来愚不可及的想法往往正是解决问题所需要的关键点所在。

可能很多程序员都会有类似的经历,在面对别人(尤其是其他部门)对于一个bug的描述的时候,必须把自己摆在一个普通用户而不是程序开发者的角度来分析问题,否则的话可能你永远都想象不到这种错误也会发生。越能让自己变得“笨”起来,越能很快的定位到问题所在。我们先看看这么一段关于web开发问题的程序员和客服人员的对话:

“从昨天开始我们的用户就看不到我们站点上的Logo了。”

“他试过重启浏览器么?”

“是的。”

“他试过重启电脑么?”

“是的。”

“他清空过浏览器Cache么?”

“是的。”

“他的浏览器版本是IE6么?”

“是的。”

“他确信是真的看不到Logo了么?”

“是的。”

“他是在电脑显示器屏幕上看我们的站点么?”

“什么?”

“比如说,它可能是打印出来看不到?”

“不。他是在显示器上看的。”

“除了站点Logo之外,他是不是其他的图片都看不到?”

“什么?哦。我再问问他。”

从这段对话来说,估计用户实际上是禁止了浏览器显示图片的功能(或者他儿子干的)。不管怎么样,如果你不是用这种傻瓜式的思维方式去寻找答案的话,可能怎么也找不到问题的根源。

很多时候,问题发现者对于问题的描述往往是非常片面的,并且加上了主观推测的成分在里面。如果你不能透过这些主观的描述去发现问题的实际表象,或者说根本就是你自己根据程序员的经验逻辑来判断问题所在的话,十有八九会在歧途上越走越远。

对于白痴级的问题,只有用白痴的行为方式才能得到答案。

即便同样是程序员,但对于你的程序并不熟悉,也会经常有这样的疑问:“为什么我调用你的代码出错了?”这种问题的答案,很多时候是因为他们的调用方式不对,或者调用了错误的库文件,或者库文件的版本使用不当,或者根本就没有联接到库文件上。当你想让同事帮你检查一下程序中的一个莫名其妙的bug的时候,一般来说希望他对你的系统了解的越少越好,只有这样他才会问一些你自己认为绝对不可能出问题的“笨”问题。

所以“笨”的精髓在于你如何去思考问题:不要假设些什么,把自己假设的太完美或者把别人假设的很聪明都会使你忽视一些很浅显的事实。思考的前提必须是完整的事实表象,思考的过程必须是抛弃成见的问题跟踪。在发现事实之前作太多的主观思考和臆断,倒不如把自己当作白痴一样来行动更好。

当然,不思考的一个极端是不分情况都直接去做,另一个极端是完全脱离事实,用思想办事。一个优秀的程序员应该做好权衡。10次决定里面的1次错误决定不是致命的;只做5次正确的决定而另外5次没有任何决定才更糟糕。

最后是一个蜈蚣的故事。蜈蚣本来用自己的几百只脚走路走的很快很好,但他从来没有花时间去想过为什么。直到有一天,一只臭虫问他:“你是怎么管理好你的几百只脚的?你不觉得这是件很困难的事情吗?”臭虫问完之后就走了。只剩下蜈蚣坐在地上,不停的思考这个问题,却一直想不出个究竟。从此以后,这只蜈蚣再也没办法好好的走路了

posted @ 2005-10-30 22:33 成长记录 阅读(469) | 评论 (1)编辑 收藏
 
什么是XML数据岛? 
数据岛是指存在于HTML页面中的XML代码。数据岛允许你在HTML页面中集成XML,对XML编 
写脚本,而不需要通过脚本或<OBJECT>标签读取XML。几乎所有能够存在于一个结构完整 
的XML文档中的东西都能存在于一个数据岛中。包括处理指示、DOCTYPE声明和内部子集 
。(注意,编码串不能放在数据岛中。) 
<XML>元素标记数据岛的开始,它的ID属性提供了一个可以用来引用数据岛的名称。 
数据岛的XML可以是内嵌的: 
<XML ID="XMLID"> 
   <customer> 
      <name>Herbert Hanley</name> 
      <custID>81422</custID> 
   </customer> 

</XML> 
或者在XML标签中通过SRC属性引用: 
<XML ID="XMLID" SRC="customer.xml"></XML> 
也可以使用<SCRIPT>标签来创建一个数据岛: 
<SCRIPT LANGUAGE="xml" ID="XMLID"> 
  <customer> 
    <name>Mark Hanson</name> 
    <custID>81422</custID> 
  </customer> 
</SCRIPT>

posted @ 2005-10-30 22:26 成长记录 阅读(343) | 评论 (0)编辑 收藏
仅列出标题