はじめに
最近コードを書いていてふと、今の自分は以前とは全く違う思考でコードを書くようになってるな。。。と気づいたので、少しまとめたいと思います。
以前
「本でこういうコードの書き方が良いって書いてあったな〜」
「本でこういうコードの書き方だめって書いてあったな〜」
「凝集度あげるためにデータとメソッドは一箇所にまとめた方がいいな〜」
「単一責務の原則に反しているからなおさないとな〜」
↓
実際に改善
↓
「よし綺麗になった」
最近
「使いやすい形のインタフェースになっているかな？」
「メンテのためにも共通化しておいたほうが良いな。。。」
「どういうデータ構造で持っておくのが嬉しいだろうか？」
「直感的に理解できるようになっているだろうか？意図などは伝わるかな？」
↓
実際に改善
↓
結果的に綺麗になっている
以前と最近との違いは？
以前と最近の主な違いは、思考の過程で具体的に自分のコードを読んだりメンテナンスをする他の開発者のことを想像できているかどうかです。
あとは綺麗な形を目指しているのか、結果的に綺麗になっているかの違いもあります。
以前は本に書いてあることや原理原則を重要視していて、そこにできる限り近い形が綺麗なコード（正解に近いコード）なのだろうという価値観を持っていました。
コードレビューでも、こっちの形の方が良いとされてるからなおした方が良いよ！というような指摘もしていました。
ただしこの時のことを振り返ってみると、【自分以外のコードを読む人、メンテナンスをする人、機能開発や改修をする人】のことは全く目に入っていませんでした。
技術書のようになっていればよい、技術書に載っているようなアーキテクチャになっていればよいと思っていました。
この思考だと、しっかりと層に分かれているもののなんか使いづらいな。。。メンテナンスしづらいな。。。というコードを生み出してしまいます。
メソッドの呼び出し方、引数をこういう感じで呼べると嬉しいだろうな〜というような、自分ではない他の開発者の視点がないと、表面上の形だけ正しく見えて、良いコードだと思っていたけど、実際に再利用してみると使いづらい。。。みたいなコードを生み出してしまいます。
最近は「こういう形の方が使いやすいよね？」「こういうふうにまとめておくとメンテするときに楽になるよね？」というような思考が増えました。
SOLID原則やDDDやクリーンアーキテクチャなどに特別こだわることはなく（もちろん大切ではありますが）、【自分以外の人に対して意図が伝わる形になっている、再利用しやすい形になっている、メンテナンスしやすい形になっている】という状態を目指してコードを書くようにしています。
最後に
【コードを綺麗に書く】というのは、技術書に書いてあるような形に近づけるのではなくて、他の人に意図が伝わるように、他の人が再利用しやすいように、他の人がメンテナンスしやすいように自分以外の開発者のことを想いながらコードを書いていくということだという気がしています。
（これもまた絶対的な正解ではない）
とはいえ技術的な成長をするためには技術書を読んだり、Webで色々と調べることも重要だと思っています。
技術書も読んだらそれを絶対的な正解だと思わず、自分以外の開発者（将来の自分という意味で自分も含む）を楽にするための手段の一つとして捉えられるようになるとまた有意義なのかなと最近思っています。
逆に技術書を絶対的な正解だと思い込み、その形にすることこそが正解だ。。。というふうになってしまうと身の回りの人も、自分自身も、自分が関わっているプロダクトもみんな辛くなってしまうのではないかと思っています。
自分達の仕事はプロダクトを開発して、プロダクトを通して価値提供をすることであってコードを技術書通りの形のように綺麗に書くことではありません。
プロダクトを最大限成長させるためにも、プロダクトを通してたくさんの価値提供をしていくためにも、他の開発者の人が楽になるような、他の開発者の開発速度や改修速度が上がるような、そんなコードを書けるようになれたらベストだと思います。
こんな偉そうなことを言っている自分もまだまだまだ未熟なので頑張ります。。。