walker...to the next step

Windows自带的zip folder支持巨讨厌，把系统拖得特慢。我终于不能忍了。找到了这个：

http://blog.pengoworks.com/blogger/index.cfm?action=blog:530

regsvr32 /u zipfldr

regsvr32 zipfldr

重点不是这点经验。重点是这些经验后隐藏着的思想。很多东西远远比它们所表现出来的更generic。

1. 复用不是那么容易的。如果不了解现有系统，时间也不允许你先了解现有系统（中国项目的特点），又需要复用一个模块。那么先复制一下做个新的模块，在上面改，比在原来模块基础上增加功能（以及随之而来的一堆判断）要容易得多。这不仅适用于Web开发。

2. Web程序每个URL的功能最好独立一点。比如用Struts的话，每个Action干的功能最好别超过两个。多了以后判断起来特麻烦，而且很多时候，根据参数的缺失情况也不是那么好判断。参见前一篇《Web程序输入分析》。这条要灵活使用。其实Linux里面很多命令或者软件功能非常单一，思想是一样的。简单的东西容易看懂，好维护，并且每个东西只干一件事更容易把事做好。

3. Struts Action中约定俗成不要写fields主要是为线程安全考虑。其实不是绝对不可以。可以配置成每次都生成新的Action实例，只是会降低效率。

4. JSP调试的可能需要app server的支持。比如Weblogic里要把JSP行号打开。（必须以exploded形式部署web module，然后进入descriptor页面即可。实际上就是修改了weblogic.xml。）

5. 方法/函数一定要短啊啊啊啊啊啊啊啊啊啊啊啊啊啊。理由见第二条。

6. 不要根据某些公用的、不是用作flag的对象状态来判断状态。这些东西没有被显式说明会被用到作为flag，因此别的代码可能会未经考虑就修改它们的状态。根据对象内部的private data member，做一个判断并输出状态的接口是没问题的。因为这些东西不会被外界不经意的改变。如果它们改变了，就意味着状态真的变了。

Web程序是琐碎而有趣的。其本质没有什么特殊，也是接受输入（最常见的是http request）产生输出（最常见的是http response）。区别在于，来自于网络的这些输入是来自所谓终端用户，而不是其他的程序员。这些用户可以非常不讲道理，甚至带着破坏系统的敌意，来提供输入（见我前面的一篇《XSS攻击的一种形式》）。所以我们实现web程序时，必须很细心的分析可能发生的各种情况。

输入错误的情况其实有两种。要分情况进行不同的处理。

一种是用户没有按照规定操作界面，比如用户在购物网站未经登录就点击我的购物车。这种情况下要回馈给用户相应的出错信息，引导客户进行正确的操作。

另一种是用户在正常使用界面时，不可能出现的情况。比如某些参数缺失等等。这些情况可能是黑客行为（构造的http request），或者是用户访问了不当的url造成的。这种情况说明对方在做我们不希望他们做的事，因此我们不应回馈任何错误信息。

并不是每次我们都能清楚的区分这两种情况，也并不是任何时候都有必要做最严密的防范。但至少要有这个意识。