12项网站程序设计要规避的问题

一、未善尽责任

基础知识不足或偷懒，使得网站程序代码不够稳固；例如数字计算未事先避免divide-by-zero、将字符串写入数据库之前没有检查最大长度。网站程序交付到用户手上，往往都会被以意想不到的方式操作，因此各种潜藏的错误都可能发生，甚至造成信息安全漏洞。网站程序语言或开发工具的改善，或许可以帮助我们免于整个系统挂点，例如Java网站程序的Exception机制，在某个功能抛出Exception时，即使我们没有加以善后，网站程序仍然可以继续执行；但是这些机制并不能真正帮助我们解决问题，因为要解决问题，必须有业务面的考虑。举例来说，执行某功能发生NullPointerException时，如果我们只是catch、显示error stack信息之后就置之不理，能够防止系统crash，对于开发人员也很容易从错误信息得知解决方法；但是对于不了解系统内部设计的end user而言，将很难从中找到修正的做法，例如在执行此功能之前必须先做某项设定之类的操作。

二、过量不必要的细节

假设用户在网站填写一个电子邮件邮箱，送到服务器时必须经过十个function处理，为了彻底防止不正确的数据，每个function都用regular expression检查邮箱格式、并且建立SMTP联机测试是否存在真实的邮件服务器。这种设计固然做到滴水不漏，但无止尽的过度设计实际上并不可行，因为网站程序设计必须考虑系统资源、网络带宽、响应时间、开发时程、执行效能等。

三、控制不够简化

开发Ruby on Rails应用的网站程序设计师，会习惯一种约定取代设定(convention over configuration)的做法，当网站程序中建立一个Name类别的model，拥有两个属性first及last，那么就可以预期数据库中，也会建立命名一致的Name数据表及first、last两个字段。网站程序开发时采用一些约定成俗的惯例，就可以省去很多额外设定的麻烦。

四、对框架过多的托付

框架帮你处理掉很多琐碎的事情，例如Ruby on Rails将约定的URL格式转换成controller method呼叫，通常不必知道它怎么运作。Mike Morton(一位网站程序设计师)说：它们(框架)就像用轿子把你抬上九成的山路，但剩下的那一成必须靠你自己携带氧气攀岩才能完成。

五、太过相信客户端

我们无法预期网络另一端的用户怎么操作系统，就像一个网站的窗体数据，即使我们已经在浏览器端用JavaScript做好一些基本的检查，但送出的数据的过程仍可能遭到恶意窜改，例如使用者用某些浏览器外挂，在窗体填入原本不允许的数据，或是黑客伪造窗体数据进行SQL Injection攻击。即使是我们自己的网站程序回传的数据，只要是来自客户端，就不该相信它一定照规矩，检查数据是不是存在威胁很难做得彻底，因此一个好的实践方式，就是只让符合条件的数据通过。

六、不够信任客户

有时候降低一些对安全的要求，可以让网站程序开发比较容易，用户也比较好操作。例如一个提供八卦闲聊的论坛系统，如果注册时需要自然人凭证及信用卡验证，每次登入都需要动态密码及一连串身分辨识，每一次送出的信息都经过特殊加密，虽然在资安方面可能有极高的成效，但肯定不会是个好的系统。

七、重度依赖神奇魔术盒

当你买了一个神奇的数据库备份软件，你不必管它怎么运作，因为销售员告诉你It just works.是否就此高枕无忧，再也不必担心数据库发生问题？许多买来的函式库、开发工具很好用，我们只需要知道怎么用，而且大部分的时候它都很顺利，但是有一天它闹个别扭，灾难就此发生。

八、重新发明轮子

如果你需要一个加密的算法，应该要找一个好的算法实作，如果觉得它不够好，那么就动手去改善它(如果是自由软件那么更需要这样做)；反之，如果你丢弃别人已经辛苦几年做出的成果，想要重新打造一个自己专属的算法，那不仅是浪费时间，也等于是向黑客敞开大门。

九、过多的功能让用户困扰

智能型手机的两大主流平台，iPhone及Android各自有其爱好者，Android在安装新软件时，很详细地将新软件有哪些访问权限告诉使用者，让使用者自己判断新软件潜在的安全问题，例如一个可以存取SIM卡数据的软件，就有可能透过网络把你的个人隐私泄漏出去。但是对于end user而言，根本看不懂这些涉及技术面的问答题，他们最后还是会在不懂有哪些潜在危害的情况下确认安装。iPhone赢在操作起来"通常"比较简单，让完全不懂科技产品的消费者，也能很快就爱上这款新奇的科技产品。试想在登入一个网站时，你还要选择是否启用SSL、GZIP网站压缩，要发表一篇文章时，还要设定使用哪一种所视即所得编辑器，使用者哪管这些？大多数人喜欢的系统就是，方便、不必太多思考(参考 Don't make me think)。

十、使用者想的和你不一样

有些Web邮件系统没有新增子文件夹的设计，但可以用标签来达到同样的功能，标签比子文件夹好用，因为一封邮件设定了多个标签，就有同时存放于多个文件夹的效果。但并非每一位使用者都愿意接受这种操作模式，他们就是喜欢先建好一堆树状的文件夹结构，等真的收到邮件的时候，再决定分类到哪个文件夹。

十一、封闭网站程序代码

许多发展商业软件的公司，总喜欢用尽各种手段保护网站程序代码不会泄漏，不但要编码加密，还要加入防止逆向工程的设计。对软件公司而言，网站程序代码是一项资产，要把它分享出去，是件有挑战的事。并不是每一种网站程序代码都是需要保护，有些网站程序代码可以公开，可以藉由分享变得更好；例如在一个项目中，实作了一组方便的邮件发送函式库，把它公开分享，并不会影响项目的收益，却能得到知名度的提升及使用者意见回馈的好处。

十二、开放不是万灵丹

有大量的开放源码项目在SourceForge、GitHub等网站上线，但仅有少数能够获得人们参与维护、修正及扩充代码。如果软件项目缺的是人力，即使把它变成开放源码的方式分享出去，也不见得就能获得问题的解决，因为很容易找到其他相似的替代品，即使现在没有，也会在未来出现。而且将产品开放，可能也意谓着将失去财务上的支持，更可能被拿去做违反自由软件精神的应用，例如某些网站程序代码被拿去开发成商业产品的一部分，并且衍伸的网站程序代码并没有同样分享出来或回馈给创始者。