非エンジニアもわかるクソコード
こんばんわ。
最近クソコードについて考える事が多いのでパターン分けしてみました。
クソコードって言葉、そんなに好きじゃないけどそうしか言いようもないからしょうがない。
で、どうせなので非エンジニアにもわかればいいなと思って書きました。
非エンジニアの方に説明するとき。
自分は非エンジニアの方にプログミラングの事を説明するとき例えとしてLEGOを使うことが多いです。
パーツを組み立てて、形を作っていく様がプログミラングに似てるんですよね。 その上、出来上がったものが目に見えるし、その上ほとんどの人が小さい頃にやってたり、やってなくても知っているので説明にはピッタリです。
クソコードってなに？
クソみたいなコードの略です。言葉の汚さマックスですよね。
どういうのがクソコードなのか？
だいたい3パターンあると思ってますので一つ一つ説明していきます。
1, 見た目がもうだめパターン
LEGOで例えると、なんか隙間が空いてたりちゃんとブロックがはまってなかったりする感じのやつです。
見ただけでダメだよねこれ、って感じのやつです。
実際のプログラミングではインデントとか、書式が全体に統一されていないパターンです。
これは簡単に誰でもわかるクソコードです。
初心者にありがちなパターンだと思います。
ちょっと慣れた人の場合はこのパターンはほぼ無くなります。
2, もっと簡単にスマートにできるのにパターン
簡単にできることを、不自然に難しくやっちゃうパターンです。
LEGOだと下の画像の薄い板みたいなやつをいくつも重ねて一つのブロック作ったりしちゃうパターンです。
そうじゃなくてもともとある一個のブロックだけ使えばいいよね？って話になります。
これが起こりうる原因は「無知」だと思います。
単純にその一つのブロックが存在していることを知らなかったが故に起こり得ます。
勉強不足ともいえますけど、全てを知ることは難しかったりします。
これはいろんな人の良いコードを見ていくか、ひたすら自分のコードをいろんな人に見てもらって指摘をもらわないかぎり、そもそも自分の書いてるコードがクソコードってことに気付きようがないです。
なんでもは知らない。知っていることだけ。。。
3, 要求に対応できない設計なパターン
たとえば、あなたがある人からLEGOでそれなりに大きい怪獣を作ってほしいと言われたとします。
そして完成。
よかったと〜と一息つく間も無く「右腕だけ形をフック船長みたいにしてほしいなぁ」って言われるわけです。
たとえばあらかじめ、右腕や左腕を簡単に着け外しできるように設計しつつ組み立てた場合はこの要望には簡単に答えられますよね？
でも、そうじゃなくて「右腕を変えるには上半身壊してつくりなおさんといかんぞ！？」っていうことも多々あると思います。これが設計がよくないパターンです。
これが起こりうる原因は「想定できていなかった」ことになります。
エンジニアは将来起こりうる要求に柔軟に対応できるような設計をする必要があるのです。
ただちょっと難しいこともあって、たとえばあらかじめ「右腕とか左腕は基本的に変更しない」っていうことが約束されている環境ではさっきの後者のパターンでも全然”設計がよくないパターン”ではないのです。コミュニケーションミスとかは置いておいたとして。
その後の要求によって、今すでにあるものがクソコードなのかどうかってことが決まっちゃうって見方もできたりします。
要求者の要求によってコードの生き死にが決まるっていうのは、さながらシュレディンガーの猫みたいですよね。
まぁ実際はある程度どこを取り外し可能にしたらいいかみたいなことは巨人たちによって議論されているので目安みたいなもの(エンジニアのいうMVCとか)はあります。
目安みたいなやつは結構優秀でそれに従えばそれなりにいろんな要求が来ても柔軟に対応できるものが作れたりします。
とはいえシュレディンガーの猫状態は解消されていないので、結局「設計に正解はない」のです。
まとめ + α
クソコードは下記の３パターンあります。
- 見た目がもうだめ
- もっと簡単にスマートにできるのに
- 要求に対応できない設計
エンジニアとしてできる、それぞれの対応策は
- 気をつける、整形ツールを使う
- 良いコードをたくさん読む、自分のコードに指摘をもらう
- 完全には無理でも最善をつくすために既存の設計方法を知る
かなと思います。
以上です。
