ブログトップ

公開日:

更新日:

13 min read

エンジニアリング

初心者エンジニアのための基礎講座：変数名から考えるプログラマの責任

プログラミング コーディング規約 チーム開発 技術教育 レガシーコード
初心者エンジニアのための基礎講座：変数名から考えるプログラマの責任のイメージ

問題のあるコードの例

先日、レガシーシステムの改修を担当した際、とあるページのコードを見て考えさせられることがありました。

   //■selectによる表示件数の変更
if(isset($_GET['pg'])){
$pagingdisplay = xHsc($_GET['pg']);
}
//■ページングでページが変更されたら
if(isset($_GET['p'])){
$current = $_GET['p'];
}

このコードを見て、多くの方は「何が問題なの？動いているじゃない」と思うかもしれません。 確かにこのコードは動作します。 でも、このコードには幾つかの深刻な課題があります。

変数名が持つ意味

まず、変数名を見てみましょう。 $currentという変数名からは「現在の何？」という疑問が浮かびます。 実はこれは現在のページ番号なのですが、それを理解するには日本語のコメントを読む必要があります。

また、URLはこのようになっています。

   example.php?pg=20&p=2

「pg」が表示件数で「p」がページ番号だと、コードを読まないと分かりません。

セキュリティ対策の一貫性

さらに気になるのが、セキュリティ対策の一貫性の欠如です。 pgパラメータはサニタイズされているのに、pパラメータはそのまま使われています。 これは特に問題です。 なぜなら、サニタイズの必要性を知っていながら、面倒だから省いたとしか考えられないからです。

データベースのテーブル定義にも同様の問題が見られました。

   tjapanesse varchar(512)

はい、「japanese」のスペルミスです。 しかも、このミスが長年にわたって修正されることなく、他のコードにも影響を与えていました。 スペルミスに気づいていても、「動いているから」と修正を先送りにしてきたのでしょう。

さらにコメントにも問題がありますが、それについてはプログラミングのコメント。現場から見えるエンジニアリングの本質を読んでください。

「動けばいい」という考え方の危険性

このような「とりあえず動けば」という姿勢は、実は大きな問題をもたらします。

  1. 後続の開発者が意図を理解するのに余計な時間を費やさざるを得ない
  2. 安全性が一貫していないため、セキュリティホールになるリスクがある
  3. 同じような手抜きが他の開発者にも伝染していく

私が特に懸念するのは最後の点です。 「あ、ここはサニタイズしなくても動くんだ」「変数名なんて適当でいいんだ」という悪しき前例を残してしまうのです。 プログラミングとは、単にコンピュータに指示を与えることではありません。

むしろ、将来そのコードを読む人々とのコミュニケーションなのです。 その意味で、このコードの作者は将来の仲間たちとの対話を放棄してしまったと言えます。 30年以上プログラマとして働いてきた経験から言えることは、「動けばいい」という考えは、必ず後でより大きな代償を払うことになるということです。 今回の例でも、私たちは改修に予定以上の時間を費やすことになりました。

改善されたコードの例

では、このコードをどのように改善できるでしょうか？

   const DEFAULT_PAGE_SIZE = 10;
const MAX_PAGE_SIZE = 100;

$itemsPerPage = filter_var($_GET['items_per_page'] ?? DEFAULT_PAGE_SIZE, FILTER_VALIDATE_INT);
if ($itemsPerPage !== false && $itemsPerPage > 0 && $itemsPerPage <= MAX_PAGE_SIZE) {
    $itemsPerPage = xHsc($itemsPerPage);
} else {
    $itemsPerPage = DEFAULT_PAGE_SIZE;
}

$currentPageNumber = filter_var($_GET['page_number'] ?? 1, FILTER_VALIDATE_INT);
if ($currentPageNumber !== false && $currentPageNumber > 0) {
    $currentPageNumber = xHsc($currentPageNumber);
} else {
    $currentPageNumber = 1;
}

URLも分かりやすくなります。

   example.php?items_per_page=20&page_number=2

このように書き換えることで、コードの意図が明確になります。 変数名を見ただけで何を表しているのか分かりますし、セキュリティ対策も一貫して適用されています。 データベースのカラム名も同様です。

   japanese_text varchar(512)

レストランの例えで考える

レストランのシェフがこんな感じで働いていたらどう思いますか？

  • 手洗いは面倒だから適当に済ませる
  • マニュアルの計量は面倒だから目分量
  • 包丁は研ぐのが面倒だから切れなくても使い続ける
  • 食材の保管場所は「自分が分かればいい」と適当に置く
  • 調理器具は「自分が探せれば大丈夫」と適当な場所に戻す
  • 作業台は「次に使う人が掃除すれば」と汚れたまま

動けばいい＝とりあえず料理ができればいい、という考え方ですね。 でもこれって、一緒に働く他のシェフや、後でキッチンを使う人のことを全く考えていません。

そしてもっと重要なのは、こういった雑な作業の積み重ねは、必ず品質に影響してくるということです。 料理の味が不安定になり、最悪の場合は食中毒のリスクも出てきます。

プログラミングにおける「手抜き」の影響

プログラミングも同じです。

「面倒くさいことは省く」 →食材の温度管理を省くようなもの。 後で大問題になります。

「コードはなるべくコピペ」 →同じソースで作った料理なのに、なぜかAとBで味が違う…こんな状況です。

「関数名・変数名は思い付きで一貫性が無い」 →調味料の容器に適当なラベルを貼るようなもの。 「あれ？これ塩？砂糖？」となります。

「コメントは自分が分かる範囲だけ」 →引き継ぎ時に「ここの手順は、まあ分かるでしょ」と説明を省くようなもの。

「スペルミスなど、動作に関係のない問題は放置」 →キッチンの棚の「LICE（本当はRICE）」というラベル。 間違いと分かっていても直さない。

チーム開発における責任

このような人と一緒に働くことになったら…想像するだけでも大変ですよね？周りのスタッフのストレスは確実に上がりますし、レストラン全体の効率も落ちていくでしょう。

仕事が速いように見えても、それは「自分の担当範囲だけ」の話です。 チーム全体で見れば、むしろ効率は落ちています。 なぜなら、他のメンバーが余計な時間を使って、その人の残したツケを払わなければならないからです。

プログラミングは個人作業ではありません。 チームで協力して、より良いものを作り上げていく活動です。 自分の書いたコードは、必ず誰かが読み、理解し、そして修正を加えることになります。

独学の限界と弊害

近年、私は深刻な問題に直面しています。 「独学でプログラミングをマスター」という形で業界に参入してくる方が増えています。 彼らの多くは、個人でアプリケーションを作る経験は豊富にあるものの、チームでの開発経験がありません。

そのため「プログラミング＝個人作業」という認識が染み付いています。 自分の書いたコードを他人が読む、あるいは他人の書いたコードを自分が読んで理解する、というような経験がないのです。

この「個人開発」と「チーム開発」のギャップは、現場で様々な問題を引き起こしています。

  • コードレビューを「個人攻撃」と受け止めてしまう
  • 「動くコード」と「保守可能なコード」の違いが理解できない
  • チームの規約やコーディング規約の重要性が実感できない
  • 他のメンバーの作業効率への影響を考慮できない
  • ドキュメント作成を「余計な作業」と考えてしまう

「面倒くさい」と省いた作業の代償を、誰かが必ず支払うことになるのです。 それが自分なのか、チームメイトなのか、あるいは顧客なのか。 私たちには、その選択をする責任があります。

実は、この「誰かが支払う代償」には、独学プログラマー自身の将来も含まれています。 次のプロジェクトで、前任者の残した「動けばいい」コードに苦しむのは、かつての自分と同じような考えを持っていた人かもしれないのです。

未来の開発者への責任

プログラマには、コードを書く責任があります。 それは単に動くプログラムを作る責任ではなく、未来の仲間たちに対する責任でもあるのです。 目の前の問題を解決するだけでなく、そのソリューションが将来にわたって理解され、安全に維持できるものである必要があります。

独学でプログラミングを学んだ方々へ：あなたの技術力と学習能力は素晴らしいものです。 その能力を、ぜひチーム全体の、そしてプロジェクト全体の価値向上に活かしてください。 エンジニアリングとは、単なる技術の集合ではありません。 それは人々との協働を通じて、より大きな価値を生み出していく営みなのです。

このレガシーコードが教えてくれたのは、プログラミングにおける「責任」の重要性でした。 私たちが書くコードは、必ず誰かが読み、理解し、そして修正を加えることになります。 その時、彼らが深いため息をつくことになるのか、それとも「なるほど、よく考えられているな」と感じるのか。 それは、今コードを書いている私たちの責任なのです。