然而，一个偶然的下午，突然心血来潮，何不将visit 的命令行功能做一下增强，比如支持多个路径、多个过滤器(filter)、多个文件列表，原想只是加一个命令行参数分析循环，然而真正实现起来，却再次体会到了命令行的复杂，if for嵌套时冲定向输出，判定目录时根目录与子目录的不同，for 对过滤器的低能替换(win9x/dos) ，一个个新问题摩肩接踵，层出不穷，竟然整整耗了我大半个工作日的时间，才勉强实现了一个粗糙的版本，这就是所谓的 V2CE 版，对与严格的测试我没有多大的信心。
现在，再回头看我的工作，其实那个 V2CE 版其实是没有多大的应用价值。多个路径和过滤器，完全可以通过多次调用visit 来实现，而且实际上，我们大多数情况下只用一个路径和过滤器；而且，多参数控制带来了易用度的下降，用户总是对参数繁多的程序有一定的心理障碍，我个人对dos 压缩软件的爱好，从高到低依次是rar,zip,arj, 易用度就是第一靠量；另外，最重要的是，多参数控制导致了代码量和复杂性的大幅提升，这个程序一度让我钻进了if for构建的幽魂迷宫而不知南北西东，程序的可读性越来越差，调试起来也越来越困难，同时兼容性上拉上了更多的绊马索。
这些，就是功能提升所付出的代价，虽然这只是一个比较极端的例子，但是功能与简洁的平衡在程序设计的其重要性可见一斑。亲和性的界面并不意味着亲和性的代码，人性化的需求并不意味着人性化的实现，一味将使用方的复杂性转嫁给设计者（比如Windows）， 并不是一个很聪明的主意，反之亦然（比如Linux ），这尚不考虑代码功能增强对设计方和使用方的双重施压。
