Webプログラムに必要な知識

Program

趣味のWebプログラムじゃなくて、仕事の場合に「必要だろ」、って知識。

  1. 文字に関する知識
  2. 脆弱性に関する知識
  3. ユーザビリティに関する知識
  4. マークアップ言語、CSS、JavaScript
  5. サーバサイドで使用する言語、フレームワークに関する知識
  6. SQL、データベース、正規化

文字に関する知識

Unicode周りの知識は今となっては必須のような気が。
Unicodeは全文字2バイトだとか、UTF-16は固定長だとかはもう論外*1。
Shift_JISで全部解決できるとか思ってるのも論外。
テキストフィールドで半角、全角とか書いてあるのも論外。

脆弱性に関する知識

XSS、SQLインジェクション、CSRFなどなど、色々あるけど、動作原理と攻撃対象、影響範囲くらいはある程度理解してないとやばいんじゃないかなぁ。
全員に理解させるのが難しいなら、どのようにコーディングすればいいのかだけでも理解させ、コードレビューもしっかりやる必要がある*2。


データベース周りは独自のライブラリとか持ってる場合も多いだろうけど、SQLを渡すだけで全部やってくれるようなライブラリの場合、簡単にSQLインジェクションが発生するので要注意*3。
そんなライブラリは窓から(ry

ユーザビリティに関する知識

神経質になる必要はないけど、ラジオボタンやチェックボックスにlabel forがないのはダメでしょ。
あんな小さなボタンをクリックさせるとか、バカじゃないの？


半角、全角とか言って入力を強制するのもどうかと思う。
やるとしたら文字数制限で、半角、全角はない。裏で動いてるシステムが要求してる？なら変換して渡せばいいだけでしょ。フロントエンドまで持ってくる問題じゃないってそれ。
そもそも、半角、全角ってなんなのよ。

マークアップ言語、CSS、JavaScript

HTMLとかXHTMLとか、とにかく自分が使うマークアップ言語に関する知識。
とりあえず、Another HTML -lintに自分の書いた(X)HTMLを通してみることが(X)HTMLを理解する近道かも。
div使いまくりな人*4はAnother HTML -lintでは検出されないタイプの人だから、タチが悪い。
あと、テーブル整形が未だに後を絶たないのはどうなんだろうか。


CSSはfloatだとかそういうことじゃなくて、CSSを使ってる意味を理解すること。
classやidにredとかf12*5とか付けてんじゃないよ、ってこと。


JavaScriptは、本当にJavaScriptが必要かどうかも含めての知識。
JavaScriptを書かなくても、フレームワークの機能を使えば簡単に実現できることも結構多い。
事実、300行程度のJavaScriptのコードがASP.NETの機能を使うことで10行程度のC#で済んでしまったことがある*6。機能拡張して20行程度。


その他にも、正規表現とか。
使うなら使うで、理解して使ってくださいと言うかなんと言うか。
8文字以内のチェックに、.........+とか、ちょっとどうかと思う*7。そんなぱっと見わけ分からんコードより、str.length()使ったほうが圧倒的に読みやすい(し速い)。

サーバサイドで使用する言語、フレームワークに関する知識

言語の力、フレームワークの力を全然活かしきれてないのはどうかと思う。
バリバリに酷使して変態的コードを書け、という意味ではなくて、誰でも出来ることはやろうよ、ってこと。


例えば、

  • C#で正規表現を記述するときは逐次的文字列を使う
  • C#では文字列の連結にStringBuilderを使う*8
  • C#では文字列の組み立てにString.Formatを使う
  • ASP.NETで入力検証するときはValidatorを使う
  • ADO.NETのSqlCommand等でSQLを扱うときは文字列連結ではなく、SqlParameterCollectionを使う
  • 同じような処理は関数でまとめる

とかそんな程度。せめてそれくらい・・・ってレベル。

SQL、データベース、正規化

SQLレスは別にいいんだけど、全く意識しない、もしくは出来ないのはダメだと思う。
全部隠してしまうと、全件とってくるようなSQLを投げて、プログラム側でフィルタリングとかが冗談じゃなくなる。というか、SQLが見えててもよくあるコードなんだから、SQLを隠してしまったらもっとひどいことになりそうな予感が。
とはいえ、そろそろホスト言語側はSQLとは決別したいと思ってるんだけど、良い方法が思いつかない。
SQLインジェクションが後を絶たないのは、文字列をごにょごにょすることである程度何とかなってしまうのが問題なんじゃないだろうか。
あと1テーブル1クラスとかもやめて欲しい。それはRDBでやることじゃない気がする。


テーブル設計の際に、はじめから非正規化を考えるのはやめて欲しい。
というか、1画面1〜2テーブルとか、おかしいと思わないのだろうか*9。それはテーブル設計とは言わないって*10。
JOINを嫌うのは、カラム数が多いからじゃないんだろうか。カラム数が多い→JOINが遅い→JOINをなくしてカラム数を増やす→最初に戻る
そういう人たちはディスクIOとかは知らないんだと思う。


カラム数が多いと、一行あたり必要なバイト数が増えるから、行数を増やしたくない。
すると、次に犠牲になるのは第一正規化。
データがカンマ区切りになってたり、改行文字で区切ってあったり。
こうして負の連鎖は続いていくわけですね。・・・RDB使ってる意味あるんですか？




そんなに難しいことじゃないと思うんだけど・・・

*1:UTF-8って言ってるくせに、2バイト固定だと思ってた人もいたなぁ

*2:しっかりってどの程度よ・・・

*3:呼び出し元で文字列連結してる可能性大

*4:div class="list"とか

*5:12pxのフォントらしいですよ

*6:まぁ、これは元のJavaScriptにかなり問題があったんだけど・・・

*7:9文字以上にマッチしたら8文字以内ではないという意図の正規表現。.{9}+にすればいいとかそういう問題ではない

*8:正常系じゃないなら別にいいかもしれないけど

*9:1画面2テーブルはヘッダと明細みたいな

*10:テーブル設計が先にあって、それに対して画面を割り当てるのなら別。使いやすいかどうかは別として