良いコード・悪いコード アウトプット
今回は2023年で最も売れている本としてとても評価されている「いいコード悪いコード」の要約を記事にします
対象者
・読みづらいコードを書きたくない
・リファクタリング作業をできるだけ楽にしたい
・バグを生みやすいコードを避けたい
また、この本はページ数がとても多いので、いくつかのパートに分けての記事になりますので、今回のパート一を読んでタメになった！という方は続きの記事を読んでもらえると嬉しいです。
悪いコードの代表格を把握
この記事を読んている方は少なくとも全くの未経験ということはないと思います。なので、これから紹介するコードはいわるクソコードです。
もう有名すぎで、みなさんご存知かとは思いますが一応みなさんとの頭の中を共通化したいので提示します。
意味不明命名
1 技術駆動命名
その技術の名前を使って命名してしまう行為
メモリーとかstringなどの型やFlagなどがあります。
それ自体を使うのが悪いのではなくそれをメインにして命名するのが悪いということです。例えば、getFlagとかですね。何をするためのフラグ？となってしまうからです。
2 連番命名
これはクラス名やメソッド名などで、名前を番号で識別する手法です。
これも、客観的に見たときに何の処理？となってしまうのでNGです。
例えば、mothod001・method002・method003などですね。
ネストだらけ
これはよくif文などで紹介されます。if文の中にif文があるような構造ですね
もっとタチが悪いのが、数百行の処理の中にネストがされていた日にはもう最悪ですよね
低凝集による問題
関連性のあるコードがあちらこちらに存在するコードいわゆる「スパゲッティーコード」があります。
低凝集とは例えば、税金を管理しているクラスがあるとします。そのクラスのプロパティとしてtaxがあるとします。もちろんこの税金を計算するロジックが必要になってきますが、ある開発者はこう考えました。「別の場所に１つでまとめておいて、それを使って今後計算すればよくね？」。ですが、これが不運の始まりなのです。
重複コード
そのコードの存在を知らずに実装してしまうこと。これにより、コードの肥大化と開発コストがかかってしまいます。
修正もれ
先ほどの重複コードが肥大化してしまうと、修正漏れが出てしまう
可読性低下
単純にコード量が増えるので、可読性が低下してしまいます。
また、別の場所に書いたことにより、関連性のあるコードを探し出すのに手間がかかるので、可読性が低下してしまいます。
生焼けオブジェクトの生成
コンストラクタで初期化をしないような実装にしてしまうと、生焼けオブジェクト(不完全な状態)になってしまいます。
public class RawObjectExample {
private String name;
private int age;
public RawObjectExample(String name) {
this.name = name;
}
public void setAge(int age) {
this.age = age;
}
public void displayInfo() {
System.out.println("Name: " + name + ", Age: " + age);
}
}上記のコードだとRawO bjectExampleを実行しないと初期化ができないです。これだと、実装者以外の人がこのクラスを使う際にRawObjectExampleを実行しないとエラーになります。
これらの悪いコードを撲滅するにはしっかりとした設計を行う必要があります。その設計をするための僕の記事を全て読んで読者の血肉になればなと思います。
設計の初歩
名前の省略はしない
何でもかんでも名前を省略してしまうと、実装者以外の人からしたらこれは何の略称だろう？と考えて調査する工数が入ってしまいます。もし、書略をするのであれば、プロジェクト関係者全員に認知をさせる必要があります。なので、僕の場合はそんなの面倒なので、できるだけ省略はしないようにしています。
変数の再利用はしない
例えば変数damageを使って色々処理をした後に、トータルのダメージを再度damageに入れてしまう場合があります。そうすると、このダメージという変数は攻撃を受けた際のダメージなのか、トータルのダメージなのかが分かりにくくなってしまうので、再代入はコードを複雑にしてしまいます。
まとまりのある処理で分ける
全ての処理を１つのメソッドの中に入れて実装する方は、流石にいないと思うのでここは割愛しますが、一応初歩ということで。
関連性のあるものはクラスでまとめる
クラスのパラメータとして体力・防御力・攻撃力などユーザの能力値を持ち、そのパラメータを元にどのくらいのダメージを与えるのか、どのくらいのダメージを受けるのかなどの処理をメソッドとして置いておくと、よりまとまりのある処理が書けるようになります。
どうでしたか？ここまでは、本当に初歩なので、そんなことは知ってるよという内容だったかもしれません。ここからはもう少し細かい設計方法について書いていきます。
次回予告
次回の記事ではクラス設計について記事を書きます。
興味のある方はフォローといいねよろしくお願いします。
告知
=========================
■企業向け
技術顧問とシステムの請負をやっています。
ご質問はTwitterのDMでご連絡ください。
https://twitter.com/katsurayamahiro
=========================
■株式会社パーソンリンクで働きたい人向け
通期での採用をしています。
熱意を添えてご応募お願いします。
https://www.person-link.co.jp/recruit
=========================
■未経験者向け
プログラミングスクールの生徒も受け付けております。
まずは無料カウンセリングからお申し込みください。
https://staging.engineer/
=========================
■現役エンジニア向け
現役フリーランスやこれから独立をしてバリバリ稼ぎたい方に対して単価200万円に必要なスキルの身に付け方、案件の取り方などを説明します。
https://www.timeticket.jp/items/78813/
=========================
■起業したいエンジニア向け
開発会社として起業の仕方や採用、営業手法を加えた初期段階の成長のさせ方を説明します。
https://www.timeticket.jp/items/137453
=========================
=========================
■IT業界が好きな人・興味がある人向け交流会の開催
もっとIT業界を盛り上げるための人脈を作りたいと考え交流会を開催します。このイベントのにはうちの代表も参加します！
また弊社に興味を持っていただけた方は説明会を受けるよりは圧倒的に会社の雰囲気がわかるイベントかなと思います！