腕に覚えのあるプログラマーがやりがちな『ありがた迷惑』
Twitterにメモしておいたことより。
2次開発から参加したプロジェクトで、1次開発の開発者が該当していると「勘弁してくれよ、もう〜」となるものを集めてみました。思いついたまま書いたのでイマイチまとまり無し。
「共通ライブラリ」を作りこむ
『利用されない』という問題
プログラマーが独断で共通ライブラリを作成するとき、殆どの場合に置いてその共通化は『想像』によってなされます。では想像で作られたものが実際に使われるか、となるとこれはほぼノーです。未来を予測することは誰にも出来ませんから。Tommorow Never Knows.
そうやって山のように作られたメソッド群から、目的にそぐったものを探す。これはかなりの面倒な作業です。一瞬で目的にたどり着けるくらいにドキュメントが充実していれば良いですが、そういったことはまずありません。*1。
そうこうしているうちに、自前で実装*2しちゃえ、となるわけです。
無意味なコメントを残す
改修による変更前コード
残さなくて良いです。中途半端にソースコードが残っていても、どういった意図で残しているのかわからなくなってはゴミ同然です。どうしても残しておきたいならバージョン管理ツールを導入して残した上で、最新コードからは削除してください。
ソースコードの挙動をあらわすコメント
// hogeFlgが1の場合、処理をおこなう
if (1 == hogeFlg || 2 == hogeFlg) {
else {
}どうでしょう。このコメントは必要でしょうか？
コードを読んで理解するのとコメントを読んで理解するのに掛かる時間が殆ど同じであれば、コメントは残す必要がありません。コメントはそれ自身をコンパイラーがチェックする方法がありませんから、実装と齟齬が出る可能性もある。そうなると無意味を通り越してマイナスにもなりえる。コメントはなるべく減らしましょう、ということです。
ただし、業務を説明する文言や、仕様などによりやむなく実装したなどの「今の自分」しか解らない事を残しておくのは良いと思います。
無理やりMVCなどのアーキテクチャを適用する(.NET)
.NET、特にASP.NETは基本的にMVCに綺麗に分けることが難しい、っていうか出来ません。「ASP.NET MVC」と言うのが新しく出来たのが逆の証明になっています。ユーザーからのポストをフォームが受け取ってる時点でMVCたりえない。にも関わらず、無理やりMVCっぽく作ろうとして破綻する、というパターンが後を絶ちません。
もちろん、アーキテクチャを固める必要はあります。検討する価値は有る。混沌を遠ざけておかないと後々の自分の首を絞めてしまうことになりますから。だからといって猫も杓子もMVCとかドキュメントビューアーキテクチャだとかレイヤーパターンだとか取り入れてうまく行くものでもない。
アーキテクチャを決めるためには
・規模はどの程度か？
・横断的要素は何か？
・例外はどのように処理するか？
……などなどを検討する必要があります。そこまで考えられているプログラマーは、これもまた残念ながら殆どいません。
他にも色々ありますが、長くなってきたのでこの辺で。
