プログラマーとしてタブーとされる要注意な行為

何事にもタブーと言われる行為があるように、プログラマーにも「これをやっちゃダメだろ」みたいな、絶対にやってはいけないとまでは言わないまでも、控えた方がよい行為はあります。

これから紹介するような行為は万死に値しますので、世のプログラマーの皆様、ご注意下さい。

コメントを残さない

ソースとコメントは二つで一つというか、切っても切り離せない仲なのです。それなのにプログラムソースだけを書いて、コメントをおろそかにしてはいけません。絶対に。

コメントを残す行為は、システムの保守性を高めることや、後任のエンジニアへの配慮といった意味で、非常に重要な意味を持ちます。

当サイトのブログ内でも、何度もコメントの重要性については記事にしておりますので、以下を参考にどうぞ。

• ソース内にコメントを残しておくことの重要性について
• ソース修正時にコメント文に残しておきたい項目（参考例付き）

ソースだけ直して設計書はそのまま

これは新規開発時よりも保守フェーズでよくあるのですが、バグ対応や追加カスタマイズなどで何かしらのプログラム修正が入った場合に、ソースだけを先行して修正し、設計書をそのままにする行為もいけません。

プログラムソースを修正したら、”必ず”設計書も修正します。というか順番的にはまずは設計書を修正⇒プログラムを修正という流れで行いましょう。

その場はやり過ごせるかもしれませんが、その後の保守を考えると、設計書と動いているプログラムの整合性が合わないと、著しく生産性が下がってしまいます。

テスト中に勝手にマスタを書き換える

テスト中に勝手にマスタファイルを書き換える。そんな行為をすればチームメンバーから非難が集中すること間違いなしです。

テスト環境とは言え、データベースは個々のプログラムとは違い、チーム内で共同利用するものです。特にマスタ関連のデータはあらゆる処理に影響を及ぼしますので、自分都合で勝手にマスタデータを書き換える行為は御法度。

マスタデータを更新する場合は、メンバーに一言断りを入れてからにしましょう。

バージョン違いのプログラム適用

修正したプログラムではなく、バージョン違いのプログラムを適用しちゃったとか、せっかく修正を加えたプログラムファイルが一つ古いバージョンのものだったとか、うっかりミスのようなことも気を抜いているとやってしまいます。

作業中に気づけばまだよいですが、バージョン違いのプログラムを適用してしまうと、システムが意図した動きをしなかったり、デグレードを起こしてしまうので要注意です。

未然防止の観点から言えば、Gitなどのバージョン管理ツールなどを利用すると良いでしょう。

意味を持たない変数名

ついつい変数名を考えるのが面倒になり、（特にカウント用変数とかは）「i」とか「t」という名前をつけたくなってしまいますが、変数名はぱっと見で役割や用途が分かるような名称をつけるようにしましょう。

こうしたこともコメントや設計書との同期と同じく、保守フェーズや後任者への配慮となります。

変数名については「上手な変数名のつけ方。一見して用途を識別できるために」の記事を参考にどうぞ。

汚いソースコード

プログラムという代物は「ただ動けばいい」とか「目的の処理を達成できればいい」という考えは間違いではありませんが、正しくもないでしょう。

できることなら、より美しいプログラムソースを書くことを追求していきたいものです。変数宣言、初期値代入、処理というパートに分けたり、処理ごとにメソッドを分けたり、サブルーチンを上手に利用するなど、美しく書かれたソースコードは読みやすいコードとも表現できます。

まとまりがなく汚いソースコードはスパゲッティコードと揶揄されることもありますが、プログラマーならばソースコードにも美しさを求める美意識を持ちたいものです。

無駄にオリジナリティを出す

システム設計もそうですが、プログラミングにもセオリーと呼ばれるものがあります。「普通だったらこの関数を使うよね」とか「普通だったらここで条件分岐させるよね」など。

それに先に話した変数名や共通化処理などは、現場で定められたコーディング規約を遵守しながらソースを書いていくことになります。

でもそうしたセオリーを無視して、無駄に独自関数を使ってみたり、あえて高度なロジックにしてみたり、オリジナリティを追求してくるプログラマーも存在します。

アマチュアとしてのプログラミングなら別ですが、仕事としてのプログラミングにおいて、ソースに自己表現を求めることは絶対にやめましょう。それは本人の自己満足でしかありませんし、周りが苦労するだけです。

あくまで仕事としてのプログラミングであれば、コーディング規約に則り、一般的なセオリー通りに、個性を排除した形でソースを書いていくようにしましょう。

おわりに

ここでご紹介したことは、プログラマーであれば誰もが一度は経験しているかもしれませんし、知らず知らずのうちに行っているかもしれません。

ですがどれもエンジニアとしての質を疑われてしまう行為ですので、今一度自身のソースコード・自身の行いを振り返ってみるとよいでしょう。