【技術書感想】「レガシーコード改善ガイド」は1歩ずつ優れたシステムにするための本

はじめに

単なる貼り付けなどではなく、私が噛み砕いて書いている記事となりますので、本書も合わせて読むことをおすすめいたします。

https://amzn.to/46rQMm1

はじめに

テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。テストがあれば、検証しながらコードの動きを素早く変更することができる。テストがなければ、コードが良くなっているのか悪くなっているのかが本当にはわからない。

その通りである。

2章 フィードバックを得ながらの作業

• 次に当てはまるものは単体テストではない
  • 1. データベースとやり取りする
  • 2. ネットワークを介した通信をする
  • 3. ファイルシステムにアクセスする
  • 4. 実行するために特別な環境設定を必要とする（環境設定ファイルの編集など）
• レガシーコードのジレンマ

  コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。

• レガシーコードの改善手法
  • 1. 変更点を洗い出す
  • 2. テストを書く場所を見つける
  • 3. 依存関係を排除する
  • 4. テストを書く
  • 5. 変更とリファクタリングを行う

12-3章 絞り込み点の落とし穴

• 単体テストを書くことが、いくつかの問題を引き起こす可能性があります
  • そのうちの1つは、単体テストを小さな統合テストに徐々に成長させてしまうことです
• 新しいコードのための単体テストを書くコツは、できる限り独立してクラスをテストすることです

13-1章 仕様化テスト

• さて、テストが必要です。どのようにテストを書けばよいでしょうか。
  • 仕様化テストは振る舞いをそのまま文書化するだけなので比較的簡単
• 仕様化テストの手順は？
  • 1. テストハーネスの中で対象のコードを呼び出す
  • 2. 失敗するとわかっている表明を書く
  • 3. 失敗した結果から実際の振る舞いを確認する
  • 4. コードが実現する振る舞いを期待するように、テストを変更する
  • 5. 以上の手順を繰り返す
• テストは、実際のシステムをそのまま文書化したものともいえる
  • システムの動作を理解すると、システムを変更出来るようになる
• テストがあると、システムの動作を理解するスピードが上がる
  • テストが足りないと、自分がコンピュータになったつもりでコードを読み、ある時点のある値がどうなっているかを解読する以外に、システムの実際の動作を理解する方法はありません
    • この速度がどんなに速く理解できたとしても、何度も何度も繰り返さなければならないのは、かなり退屈で無駄なことです
• 多くの場合、クラスをテスト可能な状態にするだけで、コードの品質が向上します。
  • 何がどのように動作するかを理解できるため、変更を行い、バグを修正して、先に進むことができるようになります。

25-9章 実装の抽出

• ネーミングは設計の中心である。
  • 優れたネーミングはシステムの理解を助け、作業を容易にする。
  • 貧弱なネーミングはシステムの理解を妨げ、後でシステムを扱うプログラマに辛い日々を送らせる。

https://amzn.to/46rQMm1

さいごに

👋 主にFlutter使ってるエンジニアの pomm（ぽむ）です！ Flutterやエンジニアリングについて、業務や趣味の中で気づいたTipsなどをまとめてます。

いいね・フォローしてくれると喜びます！

この記事が1人でも多くの方へ参考になっていれば嬉しいです。