今日はtwitterから受けた質問にお答えしていきたいんですが、

デザインパターンは覚える必要あるんですか？

という質問内容ですね。

デザインパターンというのは設計パターンというか、ソースコードの型みたいなもので、その型に沿ってコードを書いていくと言うものです。
少し技術的な話なので、分からない方はネットなんかで見て頂ければと思います。

実際使用されるものは限定的


このデザインパターンって、最近はあんまり意識しなくてもコードを書けるようになってきているんじゃないのかなと思います。
Webフレームワークなんかのソースコードの中身を見ますと、使われているのはSingleton（シングルトン）パターンが結構多く、たまにFactory Method（ファクトリー・メソッド）パターンが使われているという感じで、他のデザインパターンってそんなに多用されていないようなんですね。

未経験の方など、デザインパターンも全部覚えとかなきゃいけないのかな？と心配される方がいらっしゃるんですが、実際のところ私もSingletonとFactory Methodの2つくらいしか使ったことないですからね。

デザインパターンも色々ありますので、覚えてもやっぱり実践で使わないと忘れちゃいますよね。
なので、とりあえずSingletonとFactory Methodの2つだけは押さえておいて、あとは実際にどこかの会社に入られて、もしそこでデザインパターンを使って開発しているようでしたら、仕事でソースコードを見ながら学んでいくというくらいの考えでいいんじゃないのかなと私は個人的に思います。

技術知識よりコードの読みやすさ


デザインパターンの使用も良し悪しあって、実際の開発で使うと逆にコードが読みにくくなるって言うことも結構あるんですよね。
デザインパターンに限らずライブラリなんかもそうなんですが、ある技術を自分が知っているとあえてそれを使いたくなりますが、他のチームメンバーが知らなければ読みにくくなってしまうわけです。

例えばpythonでよく使われるList comprehensions、日本語だと「リスト内包表記」なんかも、forループ1回分であればまあリスト内包表記を使って書いてもいいんですが、forループが2回とか3回とかでも知識があるばかりにリスト内包表記を使う人がいるんですよ。
そうするとコードって読みにくくなるんですよね。
読みにくくなるということはやっぱりチームでメンテナンスもしにくくなりますし、トラブルが起きて素早くコードを読んでいかなきゃいけない場面などで結構他のメンバーが迷惑するっていう事があったりするんです。
なので知識があるばかりにそれを多用していると、場合によっては他のメンバーからは嫌われてしまったりもします。

特に、実務未経験でアカデミック系でやってきた人は、教科書通りに学んだ知識をあえて多用したいなんて場合もあると思いますが、その辺は注意した方がいいんじゃないのかなと思います。

今は昔のように一人で開発というより、チームで開発していくということ多くなってきていますので、ソースコードの読みやすさって非常に大事なんですよね。

シリコンバレーのGoogleもFacebookもAmazonも大規模開発なので、他のチームメンバーの読みやすさを考えてコードを書いていくということがかなり重要になりますし、逆にそこを考えられないでコードを書いてる方というのは解雇対象になるんですね。
独りよがりのソースコードで他の人が理解できないというのはやっぱりチームに迷惑かかりますからね。

日本の方っていうのは、他の人がわからないぐらい難しいソースコードをかける人が優れたプログラマーだみたいな考え方があって、難しいデザインパターンを使う人が多い気がしますが、それよりも他のチームメンバーのことを考えてコードを書くことを意識した方がいいのかなと思います。

読みやすいコードとは


（デザインパターンの話題からは外れますが）
プログラムのコードを上から読んでいったときに何が重要かというと、やっぱりフォルダ名・ファイル名・関数名・変数名ですね。
この名前の付け方が悪いと、何を書いているか分からないんですよ。

例えば判定用のフラグを使うときに、（flagだからその頭文字の）「f」などという変数名を付ける方がいるんですが「fって何？」っていう感じですよね。
このフラグがもしブラウザのInternet Exploler（IE）を判断するものであれば、「isIE」などの変数名にすれば英語の文章を読む感覚で「ブラウザがIEかどうかを見てるのか」と分かるわけです。

こういった変数名や関数名を分かりやすくするように意識している方のソースコードって、コメントなど一切なくてもソースコード見ただけで何が記述されているか分かるようになっているんですよ。

できるプログラマーはそういうチームメンバーに配慮した、トラブル時も読みやすいソースコードを意識して書いているので、皆さんもそういったエンジニアを目指していただくといいのかなと思います。

ちなみに読みやすいソースコードに関しては、UdemyのPythonのコースでどうやって書けば綺麗に見えるかなんていうことも説明してますので、もしよかったら受講していただければと思います。

Udemyのコース一覧はコチラ↓



ということで、話を戻して、デザインパターンに関しては、Singleton、Factory Methodだけ押さえておいて、あとは実践で学んでいくということでいいんじゃないのかな。というのが回答でした。

技術的な質問なども何かあればお答えしていきたいので、YouTubeやTwitterでコメントいただければと思います！

動画はコチラ↓



酒井潤

Twitterにて、こまめに情報を発信しております！フォロー大歓迎です。気軽にフォローしてください。


YouTubeも始めました。チャンネル登録よろしくお願いしまっす。


LINEで更新通知をお送りできます。読者登録もよろしくお願いしまっす。