1. 汚いコード、クソコードは意図して作ってる訳ではない
以下の記事に、とてもよいと感じた箇所がありました。
よほど悪意を持った人でない限りは、意図的に汚いコードを書こうという人もいません。単純に良い習慣が身についていないだけで、悪意はなくても汚いコードになってしまう、という事はよくあります。個人的には、ほとんどがごく単純に知識の問題であると感じています。
よくプログラマーの間で、現場でひどいコードがあると喚いたりすることがあります。
でも、前述の通り、別に悪意をもってそうしているわけではないし、その人の知識量や経験、そして、案件の忙しさなどによって結果的に汚いコードになることはあります。
コードそのものを批判するのはいいと思いますが、コーダーを責めるにはいろいろな背景を配慮する必要があるし、外野からSNSで晒して喚くものではないと感じます。
とはいえ、プログラマーを職業としてするからには、ある程度、綺麗なコードを心がけたいと思います。
20年ぐらいプログラマーとして仕事をしていますが、どういうコードをかけばクソコードを回避できるのか、ポエムとして書いてみます。
綺麗なコードには２つの観点があると思っています。
2. 部品としての綺麗さ
1つめは、変数、関数、クラスなどの部品の綺麗さです。
これは、リーダブルコードにたくさん言及があります。
例えば、以下の観点があると思います。
【部品の綺麗さの観点】
・変数や関数の命名
・関数やクラスの行数（関数やクラスの役割の細分化）
・階層の数（インデントの深さ）
・分かりやすい条件判定
・変数のスコープ（グローバル変数、プロパティ変数の使い方）
・引数の数
・パブリックやプライベートなどアクセス制御（なんでもパブリックにしない。呼び出しが困る）
・同じようなコードを繰り返さない。
・流れのわかりやすさ（main、runとか起点をわかりやすくし、流れを記述する関数やメソッドをつくっておく。）
・アルゴリズム
他にもあると思いますが、上記が良く目にするものだと思います。
これらは、コーディングを仕事とするコーダーとして最低限押さえておいてほしいなと思います。
初心者はまずこうしたコーダーとしての最低限のお作法を押さえることがプロへの通過点だと思います。
プロとしては、ここは必ずおさえておきたいですね。
3.構造としての綺麗さ
2つめは部品を組み合わせた構造の綺麗さ。よく設計として語られますね。
たとえば、ドメイン駆動、オブジェクト指向、関数型プログラミング、オニオンアーキテクチャ、DI、デザインパターンとか挙げれば色々とでてきます。これらの設計方針や実装パターンにより「可読性、拡張性、堅牢性」などが担保されます。
バグを生みにくい、テストしやすい、新しい機能を実装しやすいなどたくさんのメリットをもたらします。
こうした構造の綺麗さについては、なかなか一朝一夕では身につかないし、案件の内容や規模によってどういった設計手法をとり、実装するのかは変わります。
これはコーダーの上に位置するアーキテクトとして身につけておくべきスキルだと思います。
ただ、難しいので必ずしもいつも綺麗になるとはいえない気がしますが、ある程度問題を回避した構造は作れると思います。
4. コードを綺麗に書くための方法（案）
初心者がどうすれば綺麗なコードをかけるのかを自分の経験や人から聞いた話をもとに整理してみます。あくまでも一例です。
ありきたりなことしかないですが、綺麗に書きたいという意識をもって実践するだけですね。
a. 書籍を読む
リーダブルコードなどコーディングのベストプラクティスなどの書籍を読む。
この本は、ハード、メモリ、コンテナ、C、Javascript 、Typescript、Java、Rust、Python 、Elixir と基礎的なところから、最近話題の技術や言語をあつかっていて良い書籍ですね。
b. 綺麗なコードを読む
社内の先輩達のコード、OSSのコードなど、サンプルではなく、実際に動いてるアプリのコードを読むと命名や書き方の参考になります。
c. 他人の目に触れる機会をもつ
職場や個人開発、いずれでもいいのですが自分だけでコーディングせず、他人の目に触れることが大切です。
d. AIやエディタのプラグインを使ってコードを自動で補正する
VSCodeなどエディタやIDEにはリンター（文法のチェック）、フォーマッター（整形）などをしてくれる機能や拡張があります。それをつかって、コードを補正しましょう。
最近は、AIによるコーディングアシストも受けられますので、積極的に使いましょう。
e. 設計について学ぶ
まずは、有名な書籍や記事を読むことですね。キーワードをしったらそれをAIにきいてみるのもありですね。
勉強会などもあるのでいってみるのもよいと思います。いろいろ相談できたりします。
f. 実践経験を積む
上記の知識を得たら、とにかく何かアプリやシステムを作ってみるのが重要だと思います。個人開発、実際の案件、いずれでもよいと思います。実践しないと何も身につきません。
5. さいごに
以上、コードの綺麗さを２つの観点で整理しました。
最低限、コーダーとして部品を綺麗に作れるぐらいはしておき、慣れてきたらアーキテクトを目指して、設計手法をいろいろ学び、経験するのがよいですね。
6. おまけ（20年プログラムをしてきた個人の軌跡）
（１） 関数定義さえ知らず、一人でプログラムをしていた時期：20代半ば
20年前、ソフトウェアの営業をしている最中に、開発の協力が得られないので自分で作り始めたのがプログラムを本格的にするきっかけとなりました。
最初はネットと書籍だけでコーディングしていましたが、レビューも受けなかったので本当に酷いコードを書いていました。まず、関数の使い方知らなかったので、コピペで処理を書いてすっごい長いコードになってました。（時々、そういうの現場でみたりすると懐かしくなります）
ソフトウェアの営業は2年で辞めて、フリーランスになりWebプログラムをメインで仕事をするようになりました。持ち帰りの仕事をしているときは、本当に汚いコードを書いていました。ツールについてもあんまり知らなかったです。
（２）チーム開発で他人の開発スタイルやコードをみたり、レビューを受けたりした時期：20代後半～30代半ば
でも、比較的大きめの会社に常駐して働くようになったり、プログラマーを集めたイベントをしていろいろな人と交流していくうちに、「なるほど、こうやってコーディングするんだな」というお作法や勉強する観点を持ちました。いきなり綺麗なコードは書けなかったけど、最初の頃よりはマシなコードはかけるようになりました。そのとき、外部の人達と触れてコーディングする大切さを学びました。
（３）カオスな設計しかできなかった時期：30代半ば～30代後半
でも、構造（アーキテクチャ）をつくる、すなわち、設計は相変わらず苦手で、読みにくい、拡張しにくいアプリを作っていました。
当時は、以下の記事に書いたように、「オブジェクト指向設計」が全盛の時代でした。
大きめの現場に入ると、Java✕オブジェクト指向というのが席巻していました。
今思うと、オブジェクト指向というのは掛け声だけで、手続き指向設計をクラス構文にくるんでいるだけのものが多かったように思います。スタティックおじさんというのが当時話題になっていましたが、インスタンスさえつくっているけど、実態は、スタティックと変わらないものはたくさん見かけました。
設計についてはデザイパターン、DI、ドメイン駆動、テスト駆動とかの本を読みましたが、現場で綺麗に実践しているところは少なく、あったとしても巨大過ぎてどう作るのか判然としませんでした。というわけで、自分としても何が正解かわからない状態でした。
（４）増田了さんのスライドをみて設計のコツが分かった時期：30代後半～40代前半
どうやったら綺麗な設計になるのかをいろいろと悩んでいました。そのとき、『良いコード/悪いコードで学ぶ設計入門』で有名なミノ駆動さんが勉強会などで関わられていた増田了さんのあるスライドを見つけました。
そのスライドは以下です。
増田了さんの他のスライドも大体読みました。このスライドをみたとき、「なるほど！」と思ったのを覚えています。それまでは、以下のようなコードを書いていました。現場でもよく見かけました。
駄目な設計
・メソッド、クラス一つあたりの処理が多すぎる。
・しなくてもよい共通化をして流れがわかりにくくなる。
・上記の結果、依存関係が増えて、テストもしにくいし、拡張性も低かった。
この問題点を気付かせてくれたのが増田さんのスライドでした。
それ以降、増田さんのスライドの内容に従い、小さく役割を定めてクラスや関数をつくるようになりました。そうすると、かなりテストしやすい、拡張しやすいプログラムがかけるようになりました。
また、命名もかなりスッキリして、コードリーディングもしやすくなりました。
最近は、オブジェクト指向よりは関数型プログラミング（関数指向ともいえるかな）がWebでは流行っているように思いますが、そこでも小さく区切るというのは活きる視点だと思います。
また、オブジェクト指向設計は今でも領域によっては使えると思っています。
以上、クソコードを書きまくっていた自分が少しはマシなコードをかけるようになった軌跡です。
（５）それなりに速く、拡張性の高いコーディングができるようになった気がする現在：40代半ば
最近では、プログラムをするとき悩まずに速く、命名したり、設計できるようになりました。
それは、幾度となくゼロからアプリをつくったことが役立っていると思います。どのように命名すればいいのか、どうモジュールを分割すればよいのか試行錯誤しました。
その結果として悩みのないプログラムができているのではないかと思います。
以上、初心者がワンランク上のプロとしてプログラミングができる参考になればと思います。