someok

来源: BlogBus 原始链接: http://www.blogbus.com:80/blogbus/blog/index.php?blogid=8036&m=200406 存档链接: https://web.archive.org/web/20041128234606id_/http://www.blogbus.com:80/blogbus/blog/index.php?blogid=8036&m=200406

.: 日历 :. 2004 年 6 月 Sun Mon Tue Wen Thu Fri Sat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 .: 站内搜索 :. .: 快速登录 :. .: 读书笔记 :. 敏捷软件开发：原则、模式与实践 .: 最后更新 :. 又是n久没有更新了 263.net == 恶心！！！小玩了一把Thinlet 一个程序员的一生酒桌偶感我所期望的项目过程管理系统随便说说2 人类SARS冠状病毒动物源性被证明果子狸为主凶很多公司往往会遇到这样两个问题上传附件（类似gmail） .:

最新评论 :. ppulong : 不能用来上传附件. bpnr : 我最近与这个主人. flyisland : 这反过来说明一个. flyisland : 其实走到这一步，. 郁也风 : 呵呵，点解. 幻想懒王 : 把最好的程序员变. 幻想懒王 : 我最近也在想，怎. 林星 : class/object是一. love_java : 嘎嘎。。怎么有这. asiapan : 有道理！. .:

存档 :. 1970/01/02/-2004/01/01 2004/01/02/-2004/05/01 .:

我的链接 :. 默默无语北漂男人龙心客栈冰云@NonaStudio log4u 透明思考 jini (99% jakarta) blogging 土豆仙的炼丹炉一亩三分地口水集 .:

上海天气 :. .:

CNBlog最新目录集 :. .:

扩展功能 :. ◇ Refer... :: 首页技术心得 (47) 技术文摘 (30) 琐事杂谈 (34) 牵针引线 (3) 直接转载 (5) ::wiki:: 留言簿 MVM对“如何用正确的方法来写出质量好的软件的75条体会”的回答及我跟在MVM后的回答

[技术心得] MVM曾经发了篇题为《如何用正确的方法来写出质量好的软件的75条体会》的blog，后来他又给出了相应的回答：《七十五条》的解释。而我亦给出了我自己的答案，有些不错，有些差强人意，有些则非常不足了。为便于比较，我的答案附在了MVM答案的后面。

你们的项目组使用源代码管理工具了么？ MVM : 应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。郁也风 : 公司使用的是VSS，在网上与朋友玩的就是CVS了。
你们的项目组使用缺陷管理系统了么？ MVM : 应该用。ClearQuest太复杂，我的推荐是BugZilla。郁也风 : 嫌BugZilla安装太费事，界面太简陋，我选择的是Jira的破解版。
你们的测试组还在用Word写测试用例么？ MVM : 不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。郁也风 : 用Word，而且测试工作很是不上台面（中国软件的通病，所以我们公司也没少得了犯）。
你们的项目组有没有建立一个门户网站？ MVM : 要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。郁也风 : 没有，不过看你这么介绍，回头试试去。
你们的项目组用了你能买到最好的工具么？ MVM : 应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。郁也风 : 我一向认为所谓的Notepad开发是自虐狂的不良嗜好。我们使用Eclipse，不要钱的，但我认为是java开发最好的工具了。
你们的程序员工作在安静的环境里么？ MVM : 需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。郁也风 : 看来这位兄台是看过人件了，可惜我们公司的办公环境只能说是一般，极为一般。
你们的员工每个人都有一部电话么？ MVM : 需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。郁也风 : 你果然看了人件了，但请认清形式吧，那是美国，这是中国，“中国国情”四个字会噎死你的，现在的实际情况是很多公司都不让用QQ，MSN（肯定包括我们公司了）。
你们每个人都知道出了问题应该找谁么？ MVM : 应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。郁也风 : 我们知道去找谁，但这不代表就能解决问题。
你遇到过有人说“我以为…”么？ MVM : 要消灭“我以为”。Never assume anything。郁也风 : 我也经常说“我认为”，尤其在我验证之前。当然，我会考虑改正。
你们的项目组中所有的人都坐在一起么？ MVM : 需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。郁也风 : 需要，很多问题不是面对面的话，还真无法解决，或是有时候面对面更能开拓思路，也能更好地交互。
你们的进度表是否反映最新开发进展情况？ MVM : 应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。郁也风 : 这是我一直很头疼的问题，如何维护一个有效的进度表不亚于任何一个模块的开发啊。
你们的工作量是先由每个人自己估算的么？ MVM : 应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。郁也风 : 可惜我们的任务多是政治任务，工期固定的就像螺丝钉。
你们的开发人员从项目一开始就加班么？ MVM : 不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。郁也风 : 我们加班是很多是因为资源的到位晚导致的，无可奈何。谁都知道问题的所在，谁都找不到解决问题的方法。
你们的项目计划中Buffer Time是加在每个小任务后面的么？ MVM : 不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。郁也风 : 我们尽量这么做了。
值得再多花一些时间，从95%做到100%好 MVM : 值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。郁也风 : 我们多是在客户的逼迫下完成那最后的5%的。而且100%并不代表Over，而是另一个100%的开始，成就了一个完美的恶性循环。
登记新缺陷时，是否写清了重现步骤？ MVM : 要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。郁也风 : 绝对要，理由同上。
写新代码前会把已知缺陷解决么？ MVM : 要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。郁也风 : 没别的说的，一定要。
你们对缺陷的轻重缓急有事先的约定么？ MVM : 必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。郁也风 : 知道需要，但是做的相当不够，需要努力改进。
你们对意见不一的缺陷有三国会议么？ MVM : 必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。郁也风 : 要由最后拍板的。而且不能陷入争论的泥淖。
所有的缺陷都是由登记的人最后关闭的么？ MVM : Bug应该由Opener关闭。Dev不能私自关闭Bug。郁也风 : 同意。
你们的程序员厌恶修改老的代码么？ MVM : 厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。郁也风 : Code Review？我们老板不喜欢。
你们项目组有Team Morale Activity么？ MVM : 每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。郁也风 : 这点绝对不会少的，至少我带过的团队的凝聚力还是不错的。
你们项目组有自己的Logo么？ MVM : 要有自己的Logo。至少应该有自己的Codename。郁也风 : 没想过，今天头要搞个我们部门的文化衫，我强烈反对了。不过Logo可以考虑。
你们的员工有印有公司Logo的T-Shirt么？ MVM : 要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。郁也风 : 哦，前一个我说了，我反对了。我不喜欢千人一面的感觉。
总经理至少每月参加次项目组会议 MVM : 要的。要让team member觉得高层关注这个项目。郁也风 : 好像是个不可能完成的任务。不知别的公司如何。
你们是给每个Dev开一个分支么？ MVM : 反对。Branch的管理以及Merge的工作量太大，而且容易出错。郁也风 : 反对，管理困难，也没有必要，可以加Lable。
有人长期不Check-In代码么？ MVM : 不可以。对大部分项目来说，最多两三天就应该Check-In。郁也风 : 不可以，我每天都监控VSS的。
在Check-In代码时都填写注释了么？ MVM : 要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。郁也风 : 要写！
有没有设定每天Check-In的最后期限？ MVM : 要的，要明确Check-In Deadline。否则会Build Break。郁也风 : 没有，整合就是个明确的Deadline了。
你们能把所有源码一下子编译成安装文件吗？ MVM : 要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。郁也风 : 当然，我不喜欢出现源码和类文件不匹配。
你们的项目组做每日编译么？ MVM : 当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。郁也风 : 至少项目负责人要做。
你们公司有没有积累一个项目风险列表？ MVM : 要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。郁也风 : 没有。也是一个需要考虑的内容。
设计越简单越好 MVM : 越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。郁也风 : 不同意，过度简单就成了简陋了。而且什么样的叫简单？没有一个量的界定。设计是需要让别人看明白的。
尽量利用现有的产品、技术、代码 MVM : 千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。郁也风 : 同意，我的原则是：有稳定的，经过实践验证的开源组件或产品的话，绝对不再自己搭炉灶。
你们会隔一段时间就停下来夯实代码么？ MVM : 要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。郁也风 : 肯定做了，不过可能并不是有意识地去做的。
你们的项目组每个人都写Daily Report么？ MVM : 要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。郁也风 : 这是公司的规定。也是少有的能让我支持的规定。
你们的项目经理会发出Weekly Report么？ MVM : 要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。郁也风 : 也是公司的规定。
你们项目组是否至少每周全体开会一次？ MVM : 要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。郁也风 : 要，至少这点我们实施的还可以。
你们项目组的会议、讨论都有记录么？ MVM : 会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。郁也风 : 有记录，最后要形成会议纪要的。
其他部门知道你们项目组在干什么么？ MVM : 要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。郁也风 : 我们公司的项目开始时要求所有的技术骨干坐在一起评审的，别人想不知道都难。
通过Email进行所有正式沟通 MVM : Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。郁也风 : 很少使用Email，更多是当面解决问题，毕竟都在一个办公室。
为项目组建立多个Mailing Group MVM : 如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。郁也风 : 没有这个条件，这个更应该根据项目组的规模来进行吧。
每个人都知道哪里可以找到全部的文档么？ MVM : 应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。郁也风 : 所有需要的开发文档都放在一个统一的地方，这是规定。
你做决定、做变化时，告诉大家原因了么？ MVM : 要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。郁也风 : 对我们来说，需做变化时，也就是临时会议的需要进行的时候。
Stay agile and expect change MVM : 要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。郁也风 : 这点只能说谈何容易。希望能做到吧。
你们有没有专职的软件测试人员？ MVM : 要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。郁也风 : 我们都知道需要，可是往往实际情况差强人意。
你们的测试有一份总的计划来规定做什么和怎么做么？ MVM : 这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。郁也风 : 知道需要，可实际情况同46。
你是先写Test Case然后再测试的么？ MVM : 应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。郁也风 : 至少目前的习惯和你类似，将来打算试试TDD。
你是否会为各种输入组合创建测试用例？ MVM : 不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合――但要想清楚，你是否有时间去运行那么多test case。郁也风 : 不会，没那个精力先。
你们的程序员能看到测试用例么？ MVM : 要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。郁也风 : 当然能够，项目中所有的东西都是对大家透明的。
你们是否随便抓一些人来做易用性测试？ MVM : 要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳――臭的看久了也就不臭了，不方便的永久了也就习惯了。郁也风 : 我是非常推荐这样的测试的，很多时候，客户也会参与进来。
你对自动测试的期望正确么？ MVM : 别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。郁也风 : 从不期望。
你们的性能测试是等所有功能都开发完才做的么？ MVM : 不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。郁也风 : 同意，非常同意。
你注意到测试中的杀虫剂效应了么？ MVM : 虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。郁也风 : 同意。
你们项目组中有人能说出产品的当前整体质量情况么？ MVM : 要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。郁也风 : 这当然是TL/PM的活了。
你们有单元测试么？ MVM : 单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了――可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。郁也风 : 我同意，虽然我们做的很不好。
你们的程序员是写完代码就扔过墙的么？ MVM : 大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。郁也风 : 这样的选手是要挨骂的。
你们的程序中所有的函数都有输入检查么？ MVM : 不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。郁也风 : 更多的时候是在最外面进行检查。太多的检查没有意义。
产品有统一的错误处理机制和报错界面么？ MVM : 要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。郁也风 : 有，这也是j2ee 的规范了。
你们有统一的代码书写规范么？ MVM : 要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。郁也风 : 有，首先是IDE的format工具，然后是Checkstyle之类的检查工具在每天的day build之前使用。
你们的每个人都了解项目的商业意义么？ MVM : 要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。郁也风 : 刚才说了，我们的项目的每个部分对每个人都是透明的。
产品各部分的界面和操作习惯一致么？ MVM : 要这样。要让用户觉得整个程序好像是一个人写出来的那样。郁也风 : 需要，这也是规范的一部分。
有可以作为宣传亮点的Cool Feature么？ MVM : 要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。郁也风 : 同意，我前一个项目的界面风格，被客户定为其它项目的参考标准了^_^。
尽可能缩短产品的启动时间 MVM : 要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。郁也风 : 需要，另外一方面，等待对我们开发方也是一种折磨。
不要过于注重内在品质而忽视了第一眼的外在印象 MVM : 程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。郁也风 : 这也是我在最近的项目中转变最大的方面。
你们根据详细产品功能说明书做开发么？ MVM : 要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。郁也风 : 我更喜欢迭代，你的设计是根据需求，而需求是来自客户，而客户。。。永远不变的是变化。
开始开发和测试之前每个人都仔细审阅功能设计么？ MVM : 要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 郁也风 : 要做，而且要求每个人都提出意见，这是开发工作开始之前，开始之后，我更倾向于“一言堂”了。
所有人都始终想着The Whole Image么？ MVM : 要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。郁也风 : 我也同样反对“软件蓝领”，一向唾弃这个学院派制造的名词。我们采取的方式也同样可以参加61。
Dev工作的划分是单纯纵向或横向的么？ MVM : 不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。郁也风 : 同意。
你们的程序员写程序设计说明文档么？ MVM : 要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。郁也风 : 做的不够，我们从来没写过。
你在招人面试时让他写一段程序么？ MVM : 要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。郁也风 : 我认为交流更能看出一个人的实际情况。
你们有没有技术交流讲座？ MVM : 要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。郁也风 : 同意，也在着手准备启动。
你们的程序员都能专注于一件事情么？ MVM : 要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。郁也风 : 我也懂，可实际情况是，现在有4个项目和我有关联。
你们的程序员会夸大完成某项工作所需要的时间么？ MVM : 会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。郁也风 : 会的，就算我在上报工作量的时候也会夸大的。对下，我采取的措施同你；上面对我，采取的措施是打折。
尽量不要用Virtual Heads MVM : 最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。郁也风 : 我想说的同73。 someok 发表于 2004-06-29 &nbsp23:03 | 阅读全文 | 评论(0) | 引用(trackback0) 使用Spring控制启动过程

[技术心得] Servlet 2.3 及以上版本的规范中支持 Listener ，而且在应用程序的启动中是 Listener 比 Servlet （带 load-on-startup 参数）要早，然而很遗憾并不是当前所有的容器对 servlet2.3 的支持都那么的让人满意。支持 Servlet 2.3 的 Listener 的容器有： Apache Tomcat 4.x Jetty 4.x Resin 2.1.8+ Orion 2.0.2+ 而不支持的有： Bea Weblogic up to 8.1 IBM WebSphere 5.x Oracle OC4J 9.0.3 那几个商业应用最多的容器对 Servlet 的支持的步伐是最缓慢的，当然，这其中有各种因素在起作用，不赘述。不过对于 IBM 的 WebSphere 我还是颇有微辞的，当初有个应用是在 WAS 4 上面跑，结果发现这玩意居然只支持 Servlet2.3, Jsp1.1, IBM JDK 1.3 ，而且无法给它升级，结果改动时是很费了一把劲。在 Spring 中，提供了两种模式来适应上面出现的情况，一种是 Listener ，一种是 Servlet 。让我们来看看能用到的启动工具。其一是 Log 4j 的配置，估计与 JDK 1.4 带的那个与鸡肋无异的 log 相比，绝大多数人仍然是更愿意使用 Log4j 吧。 Spring 提供了 org.springframework.web.util . Log4jConfigServlet 和 org.springframework.web.util . Log4jConfigListener 分别对应上述两种情况，可以根据需要选用其中之一来配置 Log4j 。当然不管使用那种，你都需要先配置一下需要的 : webAppRootKey ―― 缺省是 webapp.root ，这个东西该怎么说呢，是用来表示 Web 应用所在的根目录的关键字，在系统启动时将它和应用程序的物理路径以 key, value 的形式存入 System Properties 中去，所以不同的应用程序要使用不同的 key ，以防止冲突。由于是在应用启动之处就被存储进了 System Properties ，所以在 log4j 的配置文件中我们就可以使用 log4j.appender.logfile.File=${someok.root}/WEB-INF/someok.log 来配置输出日志的相对路径了（其实也只是样式类似相对路径，内里还是物理路径）。 e.g.

webAppRootKey someok.root log4jConfigLocation ―― 配置 log4j.properties 的位置，那个前导“ / ”是可选的，你不写，系统会给加上。 e.g. log4jConfigLocation /WEB-INF/classes/log4j.properties log4jRefreshInterval ―― log4j 的刷新间隔，这个一般不用配，直接使用 log4j 的缺省值即可。 e.g. log4jRefreshInterval 50000 实际的使用情况如下： Listener : org.springframework.web.util.Log4jConfigListener Servlet : log4jConofigServlet org.springframework.web.util . Log4jConfigServlet 1 需要注意的是，如果使用 servlet 的话，那么其启动顺序最好是在最前面。待续。。。 someok 发表于 2004-06-27 &nbsp17:16 | 阅读全文 | 评论(0) | 引用(trackback0) 测试 Checked Exception 和 Unchecked Exception

[技术心得] 对 Checked Exception 和 Unchecked Exception 的一些不成熟想法，也欢迎对此二者有比较清晰理解的各位指正^_^ someok 发表于 2004-06-25 &nbsp13:34 | 阅读全文 | 评论(2) | 引用(trackback0) 试用oneNote
[琐事杂谈] 试用了一下 MS 的 oneNote ，嗯，还别说，确实挺不错的东东，最小化后，占用资源很少，不过它这个最小化其实只是在任务栏保留一个图标而已，主窗体是关闭了的，这样如果还占用太多资源的化，就真有点天诛地灭了 ^_^ 内容详见全文浏览 someok 发表于 2004-06-22 &nbsp11:59 | 阅读全文 | 评论(0) | 引用(trackback0) CVS Keyword List
[技术心得] 经常在一些开源项目中看到类似$Id:...$,$Header...$之类的标记，后来有人告知是CVS的关键字，可以自动更新一些类似于版本、日期之类的信息，于是跑到CVS的官方网站查了一下，关键字还挺多，并且可以自定义的说。正文是从CVS网站拷来的Keyword List。 someok 发表于 2004-06-21 &nbsp16:33 | 阅读全文 | 评论(0) | 引用(trackback0) 现今维护的wiki
[技术心得] wiki： http://wiki.someok.com ，目前和QQ群里的几个网友共同维护，也算是刚刚起步，没什么太大野心，只想把平时的一些心得体会整理一下，相信随着时间的迁移，这个wiki的主题与内容将会欲加成熟。当然，如果你没有wiki，也没必要再去自己架一个了，可以和我们共同维护，欢迎各位光临。我的QQ：1265016 我的msn： someok4u@msn.com someok 发表于 2004-06-19 &nbsp02:20 | 阅读全文 | 评论(0) | 引用(trackback0) 主要精力将转向wiki
[琐事杂谈] 这个blog的更新频率越来越低了，也越来越倾向于流水帐式的记录了，没办法，现在的主要精力也算是转向了我和几个网友一起维护的wiki上了。这一阵也一直在考虑Blog和Wiki的使用群体及各自的擅长。区别――乱花渐欲迷人眼： Blog，有人直接称之为“日志”或是“日记”，也就是说它先天的具有流水帐的特性以及时效性，而且各个日志条目之间基本独立，关联性不是很强，如果说关联，估计也就是在分类时稍微存在那么一点吧。这种特性也导致无法将某个论题深化，也容易让作者的兴趣点多元化（多元是好事，不过也往往存在无法纵深的缺陷），多数时候流于肤浅。而wiki呢，其多人协同编辑的特性众人皆知，也没必要再次强调。这里需要说的是wiki的表现形式更类似于一个内容管理系统，但更趋轻量级，几乎没有入门台阶。而且各个条目之间的关联相对容易表现，只需为某些具有关联的条目建一个组织页面即可呈现，而且没有时效性之说，通过自定义的目录结构的整合，很容易就激发出把内容做深做广想法，乃至行动。毕竟，往往一个微不足道的小小区别会给人带来全然不同的感觉。换言之，wiki存在目录，目录亦体现主题。所以我给blog的定义是更偏向于“记录”，而wiki则显然更偏向于“写作”了。面向对象： Blog由于其时效性的先天特性，使得其在新闻发布方面表现尤其出色――blog的广泛传播好像也和伊拉克战争中的那个blog关系密切啊，当然，美女作家也同样需要blog，毕竟谁也不会老是去深化某天的床戏吧。而wiki在协同编辑、深化主题方面显然更加出色，就我作为一个程序员的角色来说，感觉wiki更适合我们使用，可以就我们关心的某些领域建立主题，多人协同维护。而实在没必要跟随现今的Blog热潮，人手一个blog，每天也笔耕不辍，谈着些不咸不淡的技术话题，个人感觉实在是一种时间、精力的浪费。经常去看一些blog（多是些大腕），感觉虽说写的多数都很精彩（大腕毕竟是大腕，对自己笔头负责任的都^_^），但是也往往会话题离散、飘忽，乃至整个blog结构散乱。而以这些人水平，如果使用的工具是wiki的话，相信肯定会朝纵深挖掘，这样下去的话，我们看到的文章在质量方面肯定更胜现在一筹的。当然，我这样说，并不是诋毁blog，而是术业有专攻，各有各的擅场，而我作为一个程序员，显然更倾向于wiki，但对于一个新闻工作者来说，blog对他则更加的得心应手。 someok 发表于 2004-06-19 &nbsp01:40 | 阅读全文 | 评论(0) | 引用(trackback0) 申请了一个GMAIL，却无法登录，郁闷
[琐事杂谈] 在生吃咖啡豆的blog上看到他通过blogger的帐户申请了一个gmail，立刻激动了一把，因为我记得我曾经也在blogger.com上申请过一个帐户，申请后因为不通过代理国内无法访问的问题就将其弃置了，也不知道把我的帐号删了没有，立刻赶去查看，hi，不错，居然还在，而且正如生吃咖啡豆所说的，在页面右方果然有邀请参加gmail测试的文字，跟着连接就过去了，一切顺利，申请成功。可让人欲哭无泪的是在登录的时候服务器报： Server Error Gmail is temporarily unavailable. Cross your fingers and try again in a few minutes. We're sorry for the inconvenience. 这种感觉，怎一个郁闷了得！ someok 发表于 2004-06-17 &nbsp20:37 | 阅读全文 | 评论(1) | 引用(trackback0) CheckStyle检测代码规范情况
[技术心得] 一个简单的教程，价值一般，无所谓看与不看了^_^ someok 发表于 2004-06-15 &nbsp11:43 | 阅读全文 | 评论(0) | 引用(trackback0) 代码规范化做的实在是不够啊
[技术心得] 昨天修改了一个别人做的模块，几乎没有注释，代码格式也很是凌乱，一天下来是头昏眼花。痛定思痛，开始使用CheckStyle、PMD检测代码，结果令人汗颜，在CheckStyle的摧残下，几乎没有那个java文件是能让人看上眼的。虽说代码格式、规范等等也都是耳熟能详，可惜实际执行总是令人无法满意，看来以后的控制力度要加强了，当然只靠每个开发人员自己来控制估计显然是个不可能完成的任务。将CheckStyle、PMD相结合，这二者都有Eclipse的相关插件。每个人在写程序的时候可以使用PMD随时检测，而CheckStyle可以在每天的整合时对整个项目进行一次检测，发现问题随时修改，初期问题可能会较多，不过相信在一段时间之后，这方面的工作量估计会小很多吧。个人 Format(Eclipse自带或是Jalopy） PMD 整合检测 CheckStyle someok 发表于 2004-06-09 &nbsp10:29 | 阅读全文 | 评论(0) | 引用(trackback0) 大字段处理的跨平台解决方案
[技术心得] 对于跨数据库平台的项目来说，大字段的处理往往是个很头疼的东西，oracle中的LOB，mySql中的text，虽说JDBC驱动中现在也提供了LOB字段的接口，可惜在实际使用中问题并未减少太多。刚才在与一个老鼠上了猫讨论这个问题时，忽然有个想法。既然LOB字段在跨数据库平台中存在问题，那么是不是可以放弃使用大字段，而使用那些能够在跨平台中使用的很好的方法呢。要知道，平时我们在大字段中存储的信息多是文本信息（如果是二进制形式的话，下面的方法就没办法了），这样的话，我们可以将大文本分割成若干段小文本，然后分别存入一个专门的表中，而这个表和原有的主表显然是个“一对多”的关系了，很简单的方法，也许可以解决很棘手的问题吧。不过现在的问题是这种模式的处理效率如何，这需要通过实际测试才能知道了，不过如果可以满足要求的话，这个方案个人认为要比使用各驱动自有的解决方案要强了。不成熟的想法！ someok 发表于 2004-06-07 &nbsp10:50 | 阅读全文 | 评论(4) | 引用(trackback0) F1赛场流水帐――俺是外行
[琐事杂谈] 想来自毕业后已经很久没有热血沸腾了，而今天，在亲眼目睹了法拉利赛车那充满美感的奔驰，亲耳聆听了F1赛车那刺耳的尖啸，那久已沉寂的、疑为程序的理性完全覆盖的热情终又重新点燃。这是种什么样的感觉啊，怎么像要飞？对我来说，跑到上海那新建的、位于嘉定的F1赛场去亲眼看看鲜活的F1赛车，本是永远都不会成为行动的，甚至都压根未在脑海中出现过这种想法。无论兴趣还是金钱都早早地将这些可能的想法扼杀在了萌芽状态。不过头不知从哪搞到的几张门票却不由得我不仔细思考一下了，4张400元面额的门票足以让我和几个朋友下定去看看的决心了，毕竟，对我来说，免费的午餐吃起来是格外的舒心啊。这是前因，后果是我们来到了传说中的F1赛事的中国区赛场。赛场嘛都是那个样子了，车库、跑道、观众席，一个都不能少，不过那充满现代感但却不知作何用途的高大“门楣”倒是颇为的壮观。上午的赛事颇为无聊了，好像是一些国产赛车在那儿转圈子，最大的感受是：还不如找几个喝过点老酒的司机来跑跑呢。不过我倒是趁这个机会，在马达的轰鸣中补了一下昨天未够的睡眠，另外在睡眠的间隙四处扫描了一下周围的ppmm。下午的第一个节目是开幕式，中国人的开幕式都是一样的。一群脑满肠肥、道貌岸然的党政高官作了一通如有雷同、纯属巧合的发言后，让人满怀期待的巡场开始了。所谓“巡场”，就是一堆让人口水止不住地流的法拉利跑车前导，一群方程式赛车保航，另有一批拉力赛上亮过相的赛车压阵，绕场若干周的巡游。在这个时候，速度不是第一位的，重要的是这么多的可以用名贵，可以用经典，可以用巨帅来形容的名车汇聚一堂，而且还活生生在你面前驰过，你还会有什么样的感觉呢？我的感觉是热血冲顶，舌下生津。当然，其中夹杂的南京××特的屁股后头扎大旗的广告车，我只能说是一群贵族当中愣是混进了一帮子土匪，咋就那么的扎眼呢？这个壮观的巡场之后，有几款精彩跑车开始个性展示了，其中包括法拉利的一辆概念车，从斜上方看去整个就是一个方形的不明飞行物，风格可以说是与以前的那些款式迥异，“酷”就一个字，我只说一次。这次的巡游也让我深刻体会到电影和现实的巨大差异性。电影中的美女在名贵的敞棚跑车中迎风招展她们的秀发，让我们感受到她们是那么的美艳不可方物。而现实中的那辆同样名贵的敞棚车中的国产模特也意气风发地向我们展示了这个迎风晃脑袋的招牌动作，但可惜的是两圈之后她的头发打结了，就像是“她来自清朝”。而那个国外的、我从不认识的名模显然经验丰富多了，老老实实地呆在挡风玻璃后面，也保住了她的丰姿与风采。看来与国际接轨，我们要做的还很多啊。如果说这些还只是饭前的甜点的话，那么正餐显然就是那辆法拉利新款赛车的精彩亮相了。经过那么久的望眼欲穿，我们这些观众的胃口也都被调到了嗓子眼的时候，万分感谢，它出场了，它拯救了我们的胃。不过精彩确实不容错过，启动速度显然超个其它赛车若干数量级，而马达的轰鸣声也向我们证实，“和飞机一样响”不仅仅是传闻。血管开始扩张、热血开始沸腾，而这还只是一辆方程式赛车而已，如果是几十辆同堂较量的话，那会是什么样的感受呢？虽说可能无法亲见，不过可以肯定的是，绝不是看看电视就能体会得到的。感觉无以言表。当然，在看了巨爽的赛车的今天，也经历了两件颇为不爽的事：一是，去肯德鸡买吃的（此处只有两个临时搭建的KFC柜台，可想而知那些个队排的有多长了），排在队伍后半截的时候，服务人员信誓旦旦的说，我们有这个，我们有那个，可终于等我们排到了前半截的时候，服务员开始一脸抱歉的说：不好意思，卖完了。你们早前说的是什么来着？？？两个柜台前，经历了两次同样的事。然后我就认同了KFC的广告歌了：Fuck KFC，生活好滋味！另一件就与国人的劣根性有关了，那么多人紧挨着的观众席，总是有那么几个人颇自以为潇洒、颇旁若无人地在那儿喷云吐雾，更多的也不想说什么了，习惯了 someok 发表于 2004-06-06 &nbsp09:08 | 阅读全文 | 评论(0) | 引用(trackback0)