プログラミングにおいてはひとつのやり方をいつでもどこでも使おうとするより、それに固執せず言語の特性にあわせて一番「おいしい」ところを活用するプログラミングにすべきだとおいらは考えます。
たとえばこんな感じです。
例外
例外はエラー処理を非常に簡単にしてくれます。
正しい使い方を覚えたら例外の無い言語はもう使えません。
しかしC#やJavaにおいても丁寧に例外をキャッチして、メソッドの呼び出し結果を0/1やtrue/false、はたまたnull/not nullで返そうとするプログラマは非常に多いです。
合言葉は「キャッチするな！！」です。しっかり覚えておきましょう。
オブジェクト指向(特にポリモーフィズム)
継承、カプセル化、ポリモーフィズム等々どれも大事ですが、おいらはポリモーフィズムが一番すごいと思います。
これを活用するとプログラム中から同じようなif文の数が劇的に減ります。
if文が減るということはホワイトボックステストのテストパターンが減って開発工数が少なくなります。
また思わぬバグの発生も減らすことができます。
しかし、if文ではなくポリモーフィズムを使って処理を分岐させようと思うと発想の転換というか、プログラミングのパラダイムシフトが必要になるのでちょっと敷居が高いかも・・・。
あと、継承には要注意です。
オブジェクト指向 = 継承 = サブクラスを作って機能を追加
と信じているプログラマのなんと多いことか！
継承はis-aの関係を理解していない人は使っちゃいけません。
機能ベースでサブクラスを作ると複雑で再利用のきかないクラスができあがってしまいます。
スクリプト言語
コンパイル言語を使ってきた人がスクリプト言語を使うとき、「スクリプト言語には型が無い」とよく言います。
しかし実際には型が無いわけではなく、実行時に型を判断しています(実行時型解決)。
int hoge = 1;
と書くのは変数hogeが整数型だとコンパイラに教えるため。
コンパイラがないなら整数型だと教えなくても良い。
var hoge = 1;
そのかわり処理を行うときにそれが実行可能か逐次チェックされます。
hoge + 1 //いける！ 2だ！ hoge + "a" //文字列の連結ならいける！ "1a"だ！ hoge + window //整数とウインドウ？？無理だ！エラー発生！！
こういうイメージ。
メソッドの呼び出しも実行時にそのメソッドがあるかどうか判断されるので、あらかじめクラスやインターフェースを定義しておかなくても良い。
逆にコンパイル言語はそのメソッドが確実に呼び出し可能であることをコンパイラに教える必要があるので、クラスやインターフェースが使われる。
というわけでスクリプト言語を使うときはコンパイラに教えなければいけない情報が減らせる分、シンプルに(少ないコード量で)コーディングできます。
でも実際に実行するまで動作が保証されないので、あまり大規模なシステムになってくるとコンパイラがエラーを教えてくれる方が安全じゃないかと思います。
SQL
SQLは宣言型言語です。
「こうしてほしい」ということをうまく伝えてあげると(つまり宣言してあげると)、データベースが効率の良いやり方を使って結果を返してくれます。
なので多少SQLが長くなってもSQL一発で処理を実現した方が良いです(特にSELECT文)。
一般的なプログラミング言語は手続き型なので、変数や配列を用意し、if文やループを使ってプログラムを構築します。
SQLの「おいしさ」をあまり理解していない人はこのパラダイムをSQL(というかPL/SQLやT-SQL)に持ち込もうとします。
本当であれば分岐やループに当たる処理はデータベースが最適化できるはずなのに、それをプログラマが明示的にロジックとして書いてしまうとパフォーマンスも落ちますし、コードも読みにくくなってしまいます。
Wordのスタイル機能
プログラミングとは直接関係ありませんが、Wordのスタイル機能も強力な武器でありながらそれを存分に使いこなしている人を見たことがありません。
毎回範囲選択してフォントを変えたり、下線を引いたりしているのは実はとっても非効率。
スタイルを作成しておけば文書のレイアウトはいつでも好きなように変更できます。
・・・と大体こんな感じです。
こういった内容は「はじめてのXXX」みたいな初心者本には載っていません。
中級者以上の本を読んで勉強することが必要です。
というわけでエンジニアはやっぱり勉強！ということになるわけですね〜。
