失敗から学ぶ初心者でもわかるコードの保守性

私は基本的に「作ってみたいものを勢いで作る」衝動型タイプなので、コメントアウトなどもほとんどしていません。
しかし、以前自分が作成していた Discord Bot のソースコードを久しぶりに見返したとき、あまりにもごちゃごちゃしていて絶望したことがありました。
そこで、「どうすればそれを回避できたのか」といったことを書けたらいいなと思っています。

どうして保守性がやばくなったのか

今まで私は静的なホームページ作成をよくしており、Discord.js などを使って Discord Bot を作ったことがありませんでした。
そのため、DB に触れる機会もほとんどなく、慣れていなかったので、テーブル設計などをかなり適当にしてしまっていました。
また、関数から返ってくる返り値も適当に扱っていましたし、当時は JavaScript しか触っておらず、型定義についてもよく理解できていませんでした。
これらが積み重なった結果、機能追加や修正をしようとすると全体に影響が出てしまい、非常に保守しづらいコードになってしまいました。

どうしたらよかったのか

DRY原則を守る

DRY（Don't Repeat Yourself）原則とは、「同じ処理や知識を何度も書かない」ことを目的とした設計原則です。
似たような処理をその都度書くのではなく、関数やクラスとして共通化しておくことで、修正箇所を最小限に抑えることができます。

当時はコピペで処理を書き増やしてしまっていたため、後から仕様を変更する際に非常に手間がかかっていました。

型を使う（TypeScript の活用）

JavaScriptを使わずにTypeScriptを使い、できるだけ型を使って安定させる。
例

type User = {
  id: string;
  name: string;
  level: number;
};

function getUserLevel(user: User): number {
  return user.level;
}

DB設計をしっかりする

データベースは後から変更するコストが高いため、最初にある程度しっかりと設計しておくことが重要です。
テーブルの役割やリレーションを整理し、無駄なカラムや曖昧な構造を避けるべきでした。

例えば、以下のサイトのようなツールを使うと、設計を視覚的に整理できます。
https://dbdiagram.io/

例外処理をしっかりつくる

これは厳密には保守性そのものとは言い切れないかもしれませんが、例外処理をしっかり実装しておくことは、結果的に保守性の向上につながります。
どのようなエラーが、どこで発生したのかを把握しやすくなり、予期しないエラーによるサービス停止を防ぐことができます。

また、ログ出力を適切に行うことで、トラブルシューティングも容易になります。

おわりに

勢いで作ること自体は悪いことではないと思いますが、保守性とかそこらへんを考えながら開発しないとあとあと悪いことをみるので、結果的に自分が損をしてしまいます。
今後は「未来の自分が読んでも理解できるコード」を目標に、開発を進めていきたいと思います。