【第 2 回 cocone tech talk・前編】クソコードをシンプルにする【イベントレポート】
-
2021年6月17日
こんにちは！cocone tech blog 新人編集者のYです！
今回は2021年5月27日に行われた「cocone TECH TALK VOL.2」でお話した内容をまとめたものを前編・後編に分けてご紹介します！
本記事は前編として「クソコードをシンプルにする」というテーマについてのお話になります。
登壇者紹介
目次
経緯
ポケコロツインの修正、改修をしているうちに書かれているソースコードの複雑さが気になり始めました。
「誰かがクソコードを書いているに違いない。犯人を探そう」
Gitの履歴を見ながら犯人を探していき、見つけたのがこちらの人物。
まさかの自分自身が犯人でした。
今回は、なぜ知らず知らずのうちにクソコードは出来上がるのか？どうやってクソコードをシンプルにしていけばいいのか？について話していきます。
なぜシンプルなコードが必要なのか？
早速ですが、ポケコロツインのクソコードを見てみましょう！
エントリーナンバー1 : 一つの関数がめちゃくちゃに長いコード
ノミネート理由
- 画面に収まりきらない
- でかいif文がいくつもある
- 変数が長生き
※ちなみにこのコードは183行
エントリーナンバー2 : 関数名と変数名の不一致
ノミネート理由
- MapかListか分からない
- 関数名で何が返ってくるのか分からない
エントリーナンバー3 : if文地獄
ノミネート理由
- どこの処理を実装しているのか分からなくなる
- 変数が可変になっていて分かりづらい
エントリーナンバー4 : 引数で渡した変数を変更するもの
ノミネート理由
- 引数が変更されるため、処理がとても追いづらい
- 変更されたことに気づきにくい
- 他のところで追加されたデータを上書きしがち
どうでしたか？
どれも複雑なコードばかりでしたね。でもこれらは動いている以上間違っている訳ではありません。
ただし人間から見て複雑なだけです。
では、なぜ私たちは
『複雑なコード == クソコード』
として認識するのでしょうか？
Science誌「人間の前頭葉における同時目標の分割表現」によると、人間の脳は2つの仕事を同時にする事が限界だそうです。
そのためクソコードによって人間は頭の処理が追いつかず、思わぬバグを産み出したり、遅い処理を書くなどプログラムへの悪影響が及んでいるのです。また、クソコードによって可読性が落ちる事でプログラマへの負担も大きくなります。
そういった状況を避けるため、人間の生産性を上げるため、人間がプログラムの変更を可能にするために、ソースコードをシンプルにする必要があるのです。
どうやってシンプルにするのか？
シンプルにする必要があるのは分かりました。
では一体シンプルなコードとはどういったコードなのでしょう？
ソースコードというものは人間が書き、そして人間が読むものです。そのため「人間にとって理解しやすいコード」がシンプルなコードだと考えました。さらに、先述したとおり人間は2つの仕事をするのが限界な生き物です。
つまり、「人間にとって理解しやすいコード」とは「人間に複数のことを同時に考えさせないコード」となります。
なにをシンプルにするのか？
続いて具体的になにをシンプルにするのか？この事について今回は3つ紹介します。
1. 誰が見ても理解できる名前にする
例えば先述したエントリーナンバー2でも登場したこちらのコード
関数名が「GetPurchaseProductMultiPremiumNoBillingDataCacheMap」となっています。非常に長い関数名かつ何をする関数なのか名前からではよく分からない。
そこで関数のしている動作を読み、以下のように関数名を修正しました。
「GetProductInfoListByPremiumNo」
どうでしょう？関数名をただシンプルにしただけなのに、人間の理解度をあげることができました。
2. 2つ以上のことを同時にしない
まずは2つ以上のことを同時にするコードを見てみましょう。
青枠で囲まれた処理とオレンジ色の枠で囲まれた処理が重なっている部分が人間の理解度を下げることにつながっています。
この例はとてもシンプルなコードですが、もっと複雑な処理をするコードだったらどうでしょう？より多くの処理が複雑に絡み合ってしまい、内容を理解したり、後から関数に分けるなどの変更を行うのが難しくなります。
ではこちらのコードをシンプルにしてみましょう。
青枠で囲まれた処理とオレンジ色の枠で囲まれた処理がそれぞれ独立することで、上から順番に読んでいくだけで理解することができるようになりました。
また処理ごとに独立しているため、後から関数に分けるなどの変更もしやすくなっています。
3. 一度作成した変数は、できるだけ中身を変更しない
言い換えるとimmutableなコードにすること、です。
メリットとして
- コードが単純になる
- 場合によっては性能の改善にもつながる
- スレッドセーフ
- 実装時に変数の変更を考える必要がなくなる
といったものがあります。
では、mutableなコードを見てみましょう。
次にこのコードをimmutableなコードにしてみましょう。
いかがでしょう？mutableなコードとは違い、どのような値が追加されているのかが一眼でわかるようになったことで、理解しやすくなり、さらには値を上書きしてしまう心配もなくなりましたね。
シンプルにする上で一番大切なこと
【誰かのためのコードを書くこと】
もし自分にだけ分かるコードを書いてしまうと他の人全員の生産性を下げることになります。
逆に、誰かのためのコード、誰かが理解しやすいコードを書くことで他の人全員の生産性を上げることができます。
ぜひ誰かのためにコードを書いてみてください。それはいつか自分のためのコードになって返ってきます。
Q&A
Q1. ソースコードの修正にはどれくらいの時間がかかりましたか？
A1. 修正にはあまり時間はかかりませんでした。ユニットテストを書いて元のコードの動作を検証し、その後シンプルなコードに修正したものを同じユニットテストを通るか試しました
Q2. レビューの仕組みはありますか？
A2. 1つの試作毎にマージリクエストをし、2人がOKを出したらマージされる仕組みになっています。
スライド
いかがでしたか？
エンジニアならばおそらくほとんどの人がこの問題に悩まされた経験があるのではないでしょうか？
私は心当たりが多すぎたので、今回のお話を肝に銘じて「クソコード」を生み出さないように気をつけて開発を続けていきたいと思います！
後編はこちらから！ぜひ読んでみてくださいね。
【第 2 回 cocone tech talk・後編】Singletonを使わないUnityを用いたApplication開発【イベントレポート】
また、ココネでは一緒に働く仲間を募集中です。
ご興味のある方は、以下のリンクからぜひご応募ください。
