Skip to content
This repository was archived by the owner on Mar 20, 2023. It is now read-only.

Commit 57706bd

Browse files
committed
refactoring
1 parent d448935 commit 57706bd

File tree

1 file changed

+42
-19
lines changed

1 file changed

+42
-19
lines changed

books/refactoring.md

Lines changed: 42 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -244,30 +244,30 @@ const main = () => {
244244

245245
### リファクタリングの問題点
246246

247-
#### 新機能の実装が遅くなる
248-
249-
- リファクタの目的はプログラミングの速度を上げること
250-
- よって実装は遅くならない
251-
- ただしトレードレードオフもある。このあたりは経験がモノを言う
252-
- リファクタする場合の例
253-
- 以後の作業が楽になるとき
254-
- 何度も同じ問題が起きているとき
255-
- 同じような醜いコードに何度も出くわしているとき
256-
- リファクタしない場合の例
257-
- 新機能が非常に些細なもので、リファクタを後回しにできるとき
258-
- めったに触らない箇所であるとき
259-
- 道徳的な理由でリファクタしようとするのは危険
260-
- 「コードが美しくなる」とか
261-
- 「(しばしば原理主義的な)すばらしいプラクティスにコードを近づける」とか
262-
- 経済的な基準でのみ判断せよ
247+
#### 新機能の実装が遅くなる
248+
249+
- 実装は遅くならない
250+
- なぜならリファクタの目的はプログラミングの速度を上げることだから
251+
- ただしトレードレードオフはあるので、このあたりの判断は経験がモノを言う
252+
- リファクタする場合の例
253+
- 以後の作業が楽になるとき
254+
- 何度も同じ問題が起きているとき
255+
- 同じような醜いコードに何度も出くわしているとき
256+
- リファクタしない場合の例
257+
- 新機能が非常に些細なもので、リファクタを後回しにできるとき
258+
- めったに触らない箇所であるとき
259+
- 道徳的な理由でリファクタしてはならない
260+
- 「コードが美しくなる」だの
261+
- 「(しばしば原理主義的な)すばらしいプラクティスにコードを近づける」だの
262+
- 経済的な基準でのみ判断せよ
263263

264264
#### コードの所有権
265265

266266
- コードの部分ごとにオーナーを設定し、変更を承認するようなやり方が良いのでは
267-
- これは、以下の 2 つの間を取ったもの
267+
- これは以下の 2 つのあいだを取ったもの
268268
- 所有権が強すぎて、リファクタが困難な状態
269-
- e.g. 関数名を変えたときに、呼び出し元のコードを変更できない場合など。こういったときは古い関数から新しい関数を呼び出すようにして、古い関数には deprecated を指定するなどするものの、最悪の場合、古い関数は永遠に残り続けることになる。
270-
- 所有権がなくて、誰もが好き勝手に変更を加えてカオスになった状態
269+
- e.g. 関数名を変えたときに、呼び出し元のコードを変更できない、など。こういったときは古い関数から新しい関数を呼び出すようにして、古い関数には deprecated を指定するなどするものの、最悪の場合、古い関数は永遠に残り続けることになる。
270+
- 所有権がなくて、誰もが好き勝手に変更を加えてカオスになる状態
271271

272272
#### ブランチ
273273

@@ -290,3 +290,26 @@ const main = () => {
290290
- 新たに埋め込んでしまったバグにすぐ気づくから
291291
- テストがない or 少ない場合は、IDE に安全が保証されている自動実行できる種類のリファクタであれば、実施できるかも
292292
- ただし注意深く手順に従う必要があるし、言語仕様にも依存するので比較的高度なやり方
293+
294+
#### レガシーコード
295+
296+
- レガシーコード = テストのないコード、テストの追加も困難なコード
297+
- 「レガシーコード改善ガイド」を読めとのこと
298+
299+
#### データベース
300+
301+
- 個々の変更は小さく、かつ完結したものにする
302+
- 正式リリースに至るまでに複数のリリースに分割する
303+
- 例えばフィールド名の変更であれば:
304+
- 1. 新規フィールドの追加(まだ使わない)
305+
- 2. 新旧両方のフィールドに書き込みを行うようコードを変更
306+
- 3. 古いフィールドを削除(使われていないことを確認した上で)
307+
308+
### リファクタリング、アーキテクチャ、Yagni
309+
310+
- リファクタリングという武器を手にすると:
311+
- 現時点で判明している最低限の要件を満たすだけの、最もシンプルなコードを書きさえすればよい
312+
- 将来のために変に柔軟性を持たせたりしない
313+
- e.g. 関数に無駄にたくさん引数持たせるなど
314+
- YAGNI = You ain't goint to need it = どうせ使わねえよ
315+
- リファクタリングできるんだから、必要になった段階で変更すれば足りる

0 commit comments

Comments
 (0)