More Related Content
More from keki3
More from keki3 (20)
Recently uploaded
Recently uploaded (8)
2019年度 若手技術者向け講座 リファクタリング
- 1. 1 リファクタリング
- 3. 目次 リファクタリングとは 可読性の高いコードの書き方 リファクタリング 3
- 4. リファクタリングとは 4
- 5. リファクタリングとは リファクタリングとは • 外から見た振る舞いを変えずに、中身のソースコードを修正すること。 • リファクタリングの目的のほとんどは、可読性の悪いコードをきれいに 整えること。 • 実行結果は変わらないが、可読性が上がるようにソースコードをいい感 じに最適化しましょう！というのがリファクタリング。 7
- 12. 可読性の高いコードを書く コードは必ず変更される • プログラミングのソースコードは一度書いたらもう終わりということは ほとんどありません。 • 必ず変更されると心得ておきましょう。 • そのため、変更に強いコードを書くことを意識する必要があります。 14
- 13. 可読性の高いコードを書く コードは読まれる時間の方が長い • ソースコードは、一般的に書いている時間よりも読まれる時間の方が長 いです。 • そのため、プログラミングをするときは「書きやすさ」よりも「読みや すさ」を優先する必要があります。 15
- 14. 可読性の高いコードを書く KISSの原則 • Keep It Simple, Stupid.または Keep It Short and Simple. の略です。 • 直訳すると「シンプルにしておけ、愚か者よ」。または「簡潔かつ単純 にしておけ」。 • 「将来に備えて」などと考えて本当は必要のない余計なコードを書いて しまうと、コードはどんどん複雑になっていきます。 • 余計なことはせず、シンプルなコードを保つように心掛けましょう。 16
- 15. 可読性の高いコードを書く DRY原則 • Don't Repeat Yourself. の略で、直訳すると「繰り返してはいけない。」 • コードをコピペして重複させないようにしましょうということです。 • 重複は、バグ修正、機能追加の際のリスクになります。 • 処理だけでなく、定数やリテラルも重複しないように注意しましょう。 • また、コードをそのまま説明しているコメントも重複と同じです。 17
- 16. 可読性の高いコードを書く 名前重要 • プログラミングは、コードの命名が最重要課題だとも言われています。 • 変数名、メソッド名、クラス名、などプログラミングでは必ず名前を付 ける場面が多くあります。 • 名前が適切かどうかを常に意識してプログラムを書くことを心がけま しょう。 18
- 17. 可読性の高いコードを書く コメントの書き方 • コメントの目的は、書き手の意図を知らせること。 • 読み手がコードの理解に役に立つことを書く。 • コードからすぐにわかることは、コメントには書かない。 19
- 18. 可読性の高いコードを書く コメントを多く書かない理由 • コードが修正されたときに、コメントも同時に修正されるとは限らない。 • コードを読めばわかること、特に処理の説明などはコメントには書かな いようにする。 20
- 19. 可読性の高いコードを書く メソッドの行数 • 一つのメソッドは何行以内に収めたほうが良いか？ • Java 1.6 の標準パッケージで4000のメソッドを調べたところ 9割のメソッドは20行以下とこのこと。 • 一概には言えないが、20行というのが一つの目安になる。 21
- 21. 可読性の高いコードを書く 変数名の付け方 • この本が参考になります。 • 変数名など、名前を付けるのが苦手 だと感じる方は一読してみましょう。 23
- 22. 可読性の高いコードを書く まとめ • ソースコードは、読まれる時間が長く、必ず変更されるものと心得る。 • 重複を排除して読みやすいソースコードを書く。そして余計なソースは 記述しない。 • 分かりやすい名前をつける。 • コメントは必要最低限にする。 24
- 23. リファクタリング 25
- 24. リファクタリングの定義 リファクタリングの定義 • リファクタリングの定義は「外部から見たプログラムの振る舞いを変え ずに、プログラムの内部構造を改善すること」 • バグを修正することはリファクタリングとはなりません。 • また、機能の追加もリファクタリングには含まれません。 リファクタリングをすると、結果的にバグ修正や機能追加が行いや すくなる。これがリファクタリングの目的 26
- 25. リファクタリングの注意点 リファクタリングの注意点 • リファクタリングと機能追加を同時に行ってはいけない。 • テストが用意されているか確認する。 • できるかぎり頻繁にテストを行う。 • 作業を小さな単位にまとめて、慎重に作業を行う。 27
- 26. リファクタリングの対象 リファクタリングの対象 • 二重化しているコードを発見した（DRY原則に反している） • 関係ないもの同士が影響し合っている。 • 時代遅れの技術が使われている。 • パフォーマンスが悪い 28
- 27. リファクタリングの対象 不吉な匂い 「Java言語で学ぶリファクタリング入門」の中で紹介されているものです。 • コードが重複している • メソッドが長すぎる • クラスの持つフィールドやメソッドが多すぎる • メソッドの引数が多すぎる • 仕様変更の修正箇所があちこちに散らばっている • あるクラスを修正すると、他のクラスも修正しなければならない • 他のクラスの中身をいじっているクラスがある • まとめて扱うべきデータが1つのクラスにまとまっていない • クラスを使わず、int型のような基本データ型ばかり使っている • switch文やif文を使って振る舞いを分けている • サブクラスを作ると、別のところにもサブクラスを作らなければならな い 29
- 28. リファクタリングの対象 不吉な匂い • クラスが大して仕事をしていない • 拡張するだろうと期待して、クラスが一般化しすぎている • 一時的にしか使わないフィールドがある • メソッド呼び出しの連鎖が多すぎる • 委譲ばかりしていて、自分では仕事をしていないクラスがある • 必要のない双方向リンクや、IS-A関係の成り立たない継承がある • クラスのインターフェースが不適切 • 既存のクラスライブラリが使いにくい • フィールドとアクセッサしかもっていないクラスがある • 継承しているメソッドなのに、それを呼ぶと問題が起きる • コードの不備を補うために、詳しいコメントがある 30
- 29. リファクタリングの対象 不吉な匂い 全部で22個が紹介されています。かなりたくさんありますが、 ざっくりまとめると • 理解しにくい • 修正しにくい • 拡張しにくい と感じる部分がリファクタリングの対象になります。 31
- 30. リファクタリングの手順 リファクタリングの手順 1. テストを実施してテストを通ることを確認 テストが用意されていない場合は、テストの作成から行う。 テストがないコードに関しては、リファクタリングはするべきではない。 2. コードの修正を実施 3. テストを実施してテストが通ることを確認 4. 2と3の手順を繰り返す。 たくさんのコードを一気に修正しないように注意する。 リファクタリングは「小さな修正 ⇒ テスト」のサイクルを多く繰り返し、 少しずつ実施していく。 32
- 31. まとめ 56
- 32. 全体のまとめ リファクタリングは必ずしも実施したほうが良いわけではありま せん。状況に応じて適切な判断を下しましょう。 リファクタリングの必要がない、読みやすい、かつ拡張しやすい コードを書けるように心がけましょう。 時間と心に余裕があればリファクタリング積極的にリファクタリ ングしていきましょう。 リファクタリングは繰り返しテストしながら小さく進めましょう。 57