はじめに
最近、自分のソースコードが汚くて悩んでいます。
具体的にはVisual Studioで開発を行っていますが、メソッド化すべきか、新たなクラスを作るべきか、新たなプロジェクトを作るべきかの判断が出来ず、汚いコードになっています。
そこで、SOLIDの原則などを調べている時に以下のサイトを見つけました。
プログラマが知るべき 97 のこと
通称「きのこ本」とよばれるオライリー発行の書籍群があります。 これらの書籍は CC-by-3.0 などでライセンスされており、著者名を明記すればコピー/配布や改変が自由にできます（商用利用も可能）。 そこで、勝手に電子書籍化（非公式版）を作...
zenn.dev
なんとオライリーの「プログラマが知るべき97のこと」が無料で読めるみたいです。
97項目もあり、量が量なので重要だと思った内容を自分のメモ用に書き留めておきます。
重要だと思った内容
- 後からきれいなコードに書き直そうとするのは、負債の始まり
タスクに追われ続けて修正する時間なんか取れないから - シンプルさを追求すれば、可読性、保守性、開発効率は付いてくる
- 全てを書き直したい衝動を我慢する
いくつものテストを潜り抜けてきたコードを書き直すのは無駄を生む - 最新の書き方がされてないからといってリファクタするのはナンセンス
- 関数は出来るだけ短くし、機能は1つに絞る
- 関数のパラメータは最高で4つまで
- コードに書けないことのみコメントにする
- 汚いコードは変更を恐れず修正を加えるべき
投資対効果が高いから - 新たな言語を学べば、きれいなコードを書けるようになる
- 死んでるプログラムを無理にtrycatchで生かしてはいけない
- なぜか上手くいっているという状況は危ない
- 「DRY(Don’t Repeat Yourself)原則」
重複は無駄 - バグレポートの内容はバグの再現方法、本来の仕様、実際の動作
- 余分なコードは書かない
将来必要になるかもというのは理由にならない - 複数の言語を学ぶべき
- プロのプログラマは自分のコードに責任をもつ
- 詰まったらコンピュータから離れる
脳の論理機能の部分を休ませて、創造部分を動かす - 他人のコードや過去の自分のコードを読め
- 良い部分だけを残し、悪い部分は消すということも困難なくらい汚いコードなら全消しすべき
- 「単一責任原則」
AとBが同じクラス内にあり、○○という理由でメソッドAを修正する、○○という理由でメソッドBを修正する時、○○は違ってはいけないという原則 - 面倒でも自動化できることは自動化すべき
まとめ
きれいなコードを書くための方法をイメージすることが出来ました。
イメージしている手順は次の通りです。
- 重複部分はメソッド化
- 単一責任の原則に従って新たなクラスを作成する
- 1つのプロジェクトから1つのexeまたはdllが生成するため、他のプログラムでも流用出来そうならプロジェクトにまとめる
- プロジェクトにまとめるときは、それから生成するdllなどは先々一塊で流用されることを念頭に置いてプロジェクトを分ける
参考サイト
プログラマが知るべき 97 のこと
通称「きのこ本」とよばれるオライリー発行の書籍群があります。 これらの書籍は CC-by-3.0 などでライセンスされており、著者名を明記すればコピー/配布や改変が自由にできます（商用利用も可能）。 そこで、勝手に電子書籍化（非公式版）を作...
zenn.dev
コメント