導入:

初めまして、Flutterエンジニアのトマトです。
この秋に転職し、コードの綺麗さが開発に与える影響について多くを学びました。
この記事では、綺麗なコードを書く意味と、汚いコードがもたらす問題点を共有します。

尚この記事はflutterエンジニア初心者やエンジニア初心者向けに作成しております。
すでにWEB・アプリエンジニアとして働かれている先輩方には不要な記事かもしれませんのでその点をご了承ください。

綺麗なコード vs 汚いコード:

まず初めに皆さんは綺麗なコードと汚いコードの違いとは何だと思いますか？
変数名の命名規則？？
コメントアウトでコードの意味が明確になっているかどうか？？
リファクタリングを考えているかどうか？？
正直どれも正解です。
それ以外にも綺麗なコードと汚いコードというのは色々と差があります。
しかしどれにも共通するものがあります。
それは相手のことを考えてコードを書くか書かないかの差です。
本当にそれを実感しました。
転職してまだ一ヶ月ちょっとしか経っていないジュニアのエンジニアですが会社のコードを見て唖然としました。

綺麗なコードへの無関心

過去を振り返ると、私自身、綺麗なコードを書くことの重要性を軽視していたことを認めざるを得ません。
インターン時代、綺麗なコードについて度々指摘を受けましたが、当時の私はタスクの完了に集中しており、コードの可読性や保守性にはほとんど注意を払っていませんでした。

過去の自分への謝罪

今、こうして振り返ると、私がどれほど多くの先輩エンジニアに迷惑をかけていたかを痛感しています。
私の未熟さと無知が彼らの負担を増やしていたことを深く反省し、心から謝罪したいと思います。
そして、今後はレビュワーをはじめとする他のエンジニアのことを常に考え、より読みやすく、理解しやすいコードを書くことを心掛けます。

汚いコードとの格闘

実際に直面したコードは以下のようなものでした。

未使用の謎の変数が散乱
dynamic型の乱用と、Lintエラーを無視する文化
極端なネストと、一つのファイルに500行近くもある膨大なコード
これらのコードは、読むこと自体が一苦労。
転職後、早々にリファクタリングの任を負った私は、この「脳筋コード」との戦いに多くの時間と労力を費やしました。

教訓としての反省

この経験を通じて、私は自分自身の過去のコードを振り返る機会を得ました。
そして、ある衝撃的な真実に気付かされたのです。
私の書いたコードも、他人にとって読みづらく、理解しにくいものだったという事実です。
過去に私が書いたコードを見返すと、その複雑さに自分でさえ頭を抱えてしまいます。
目先のリリースに追われ、コードの質よりも速さを優先してしまった結果、無秩序で理解しづらいコードが生まれていたのです。
その当時の私は、リリースを最終目標と捉え、そのためには手段を選ばない状況でした。
その結果、コピペされたコードの断片が乱雑に組み合わされ、それらがどのように機能しているのか、後から振り返っても理解するのが困難でした。
今思えば、このような状態でコードを書いたことに深く後悔しています。
コードは単なる文字列の羅列ではなく、未来の自分や他のエンジニアが読み解き、利用するためのもの。
その重要性を痛感しています。
このような過去の経験から、私は今後はより慎重に、そして他人が読んで理解しやすい「綺麗なコード」を書くことを心掛けています。
開発プロセスの中でリリースは確かに大切ですが、それに至る過程の品質も同様に重要だということを、私はこの経験を通じて学びました。

まとめ

汚いコードは、開発の意欲を削ぎ、バグの温床となり、プロジェクト全体を停滞させます。
私は今、コードをただ書くのではなく、読みやすく、理解しやすく、そして保守しやすい「綺麗なコード」を心がけています。
これは単なる技術的な問題ではなく、共同作業者への思いやりでもあるのです。