クソコードについて考えてみた
初めに
最近 X（旧Twitter）でクソコードについて盛り上がりを見せており、改めてクソコードについて文字にしながら考えてみたくなりダラダラとした文にはなりますがまとめてみました。
クソコードってどういうもの？
改めてクソコードとはなんだろう？と思い調べてみたのですが、こちらの記事にどういうものがクソコードというのがまとめられており参考になりそうです。
一般的なクソコードとはどういうものか？
上の記事を参考にさせていただきながら、ざっと調べると下記のようなものと定義できそうです。
- 可読性の悪いコード
- バグを誘発しやすい
- 機能追加しづらい
- 再利用性が悪い
- 実装方法が明らかにおかしい
- コードの意図がわからない
- 命名が適切ではない
- コードから仕様が理解しづらい
- 実は実装が仕様的に間違っているがそのまま放置
人によってはクソコードはクソコードではない
ほんの一例ではあるのですが、Aさんからみたものがクソコードに見えてもBさんからみたものがクソコードではないというようなものが結構ありそうです。
例えば、React的な話ですると関数コンポーネントで大量のpropsを扱っているコンポーネントを見た時にAさん的にはそのコードをクソコードだから一部をグローバルステートで扱った方がいいと思ったりする。
ただ、Bさん的にはグローバルステートを扱うことでいろんなところから参照をされているものではないか？といった考えることが増えることを嫌う人からしたらグローバルステートを扱うことをクソコードとも捉えられるかもしれない。シンプルにpropsのバケツリレーをしたいよー的な、、
なのでこういうコードの設計部分に関しては、周囲と認識を合わせをしながら実装を進めることによって、そのコードが本当にクソコードなのかを考える必要がありそう。
なので以降に話については誰もがこれはクソコードだー！、というものをクソコードと定義しておきたい。
クソコードはどういう問題を引き起こすのか？
クソコードに直面した自分が今までどういう問題を引き起こしたのか、あとは周りの話を聞いて考えてみる。
開発スピードの低下
機能修正、追加があった時に、クソコードはすでに負債を持っている状態なので、既存コードの理解に時間がかかったり、他の機能に影響を与えてしまうなどの問題がある。
人によってはクソコードでなければ1時間で済むものが、クソコードのせいで2,3日やそれ以上かかったりなんてこともあったりするかもしれない。
機能追加・修正ができなくなる
いろんな人がその場しのぎで書いてきたコードを理解し、仕様を理解しながらそのコードを触るのは熟年のスキルが必要です。というか熟年のスキルがあっても難しいものもあるのではないかと思います。
大量の条件分岐があったり、既存コードにそもそもバグがあったり、したら何を信じてコードを書けばいいのかわからなくなってしまいそう。
開発コストがかかる
うまく書けていたら1時間で済むものが2,3日やそれ以上かかったりすると、エンジニアにかけないといけないコストが上がる。
お金や時間を大量に投下しないとだ。
ストレスが溜まる
諸々考えることが増えてしんどくなります。
会社に愛はあってもコードに対する愛が薄まりそうです。
優秀なエンジニアの確保がしづらい
例えば新しく優秀なエンジニアにプロジェクトに入ってもらった時に、プロダクトのクソコードを見せるとプロジェクトに入るまでは頑張ろう！と思っていた気持ちが下がり、すぐに辞められちゃうかもしれない。
面接では綺麗なことを言っていたのにコードはクソコードやないかー！的なこともあったりしそう。
言葉は嘘をつけてもコードは嘘をつけない。
クソコード問題を理解した上でクソコードを許容するのか？
X（旧Twitter）のいくつの意見があったのでそれを見ながら考えてみる。
『クソコードを許容してリプレイスする前提で作ればいい』 について
まずリプレイスって相当な気合いと、お金が必要になると思っている。
仮にサービスが大当たりしてリプレイスをするとなった時にそのリプレイスにはいくらのお金と、どのくらいの時間がかかるんだろうか？
どこの企業とかではないですが聞いた話によると、リプレイスをすると決めてチームを作って走り出して、数億のお金をかけ、数年たってもリプレイスが完了しないし、終わる目処も立っていないという会社もあるとかないとか。
もちろんこれも悪い例の一つで、後でリプレイスに成功をした企業もあるとは思うが、リプレイスを確実に成功させれるなんて確実にできることなんだろうか？？
リプレイスする前提で作るというからには、リプレイスをできる未来を想像して本当にそれが可能なのか？というところまで考えるのが大事かなと。
そのプロダクトでそれが可能な未来を想像できるというのであれば、結構なクソコードがあったとしても、そのまま走ってみるというのはいいかもしれないです。
『スタートアップでクソコードをメンテナンスするような資金や人材がない』 について
これは辛いやつ。こういう場合はコード負債を積み重ねながら、プロダクトを前に進めて後で改修をしていくパターンだろうか。。一定仕方がない気もする。
ただ、可能であればエンジニア側からプロダクトオーナーに伝わるように、クソコードがもたらす問題をしっかり伝えてもらって資金を確保してもらい、出来るだけ優秀なエンジニアを引っ張ってきてもらう等して将来的なコストをできるだけ書けないようにできるといいなと思っている。
プロダクトオーナー的に資金や人材の確保が難しいとなった場合はクソコードのコスト的な問題点だけしっかり伝えてあげたい。
ただ、クソコードを全て無くして進むということ自体も無理だとも思っているので、実装をする時にはクソコードの問題点と向き合いつつ、ビジネスサイドやプロダクトオーナー等を巻き込みながら、日々クソコードと上手にお付き合いをしていくのが大事なのではないかと思ったりです😀
なぜクソコードは生まれるのか？そしてクソコードが生まれないためにできることは？
誰しもクソコードを書きたくて書いているわけでははずなのになぜこの問題が起こるんだろうか？
全てを考えるのは難しいがいくつか例に出してみた。
実装者の技術力問題
自分も大した技術力はないので難しいが、知識不足、経験不足からアンチパターンを踏むなんてことはよくありそう。
対策
- 実装者は技術理解を深める
- 言語、フレームワーク、ライブラリー、etc..
- コードガイドラインの理解に努める
- コードガイドラインがあればこれを定期的に確認をする。
- 実装後にはレビュワーがちゃんと確認をする
- クソコードがないか、クソコードにならないかをしっかり見てあげる。（PRで相手に対してクソコードとかは言わないでください🥺）
プロダクトに関する理解
そもそもプロダクトに関する理解が不足していると、それっぽい機能を言われて作る形になるので実装がその場しのぎの実装になりやすかったりする。
対策
PRD（プロダクト要求仕様書）を確認しやすくする。
プルリクエストからこれらの仕様を遡り、レビュイ、レビュワーがそれぞれ仕様を理解して実装をし、未来的に実装を振り返る時にPRからPRDを確認して仕様を追えるようにすると良さそう。
PRDの項目の一例
- 誰のために問題を解決するか
- どんな問題を解決するものか
- 機能要求・要件
- 機能および特長
- 関連するUIデザイン
リファクタリングについて
一時は素敵なコードでも、時を経つと、実装に合わせてコードが複雑化し、リファクタリングを迫られることがあるが時間がなかなか確保できていない。
対策
- 出来るだけクソコードを生まないような体制でコードを書く
- 軽微な修正であれば実装に合わせて修正をする。
- ビジネスサイドと調整をして可能であればリファクタリングの工数を確保する。
最後
みんなクソコードも積もりに積もると向き合いたくないし好きなものではないと思います。
このような嫌いなレベルのクソコードにならないようにしっかりコードはメンテナンスしておきたいし、クソコードの問題点について日々理解を深めながら実装を進めるのが大事なのかなと書きながら思いました😀
Discussion