リファクタリング

最初にやること

リファクタする前に書く

リファクタして挙動がおかしくなっていないかを確かめるため

テストコードを書きづらい部分もあるだろうし

例えばControllerとか

1つのでかい関数を小さく切り出していく

1つの関数を、前半と後半に分けるイメージ

パフォーマンスとの兼ね合い

例えば、リファクタによって関数呼び出しの回数が増えたりする

やや気になってしまうが、気にする必要はない

気にするほどパフォに影響はない

きれいになった方がその後のチューニングもしやすい

一度キレイにしてしまってから、パフォの問題が出たら直せばいい

それはさておき、このスライドのような状況に立たされた時に、自分ならどうアプローチするかな、というのを考えながら読んでいた

自分ならまず最初に、

読んで構造を理解した上で、

徐々に型を付けていく

その後、関数に切り出す、というふうにやりそう

つまり、テストを書く、ということをしなさそう

でもそれって、実際認知不可が大きそう

このスライドでは、少しずつテストを書き、少しずつリファクタするアプローチをしている

要件を聞いた上で取り掛かるのと、コードを読んだ上で取り掛かるのでは差がありそうにも感じる

つまり、テストを書いて徐々に改善しようにも、

自分が発見できた要件はテストに落とし込むことができるが、

その合間を縫って漏れた要件に関してはテストで表現されない

すると、リファクタ完了後は、発見できた要件のみを満たしたコードになってしまう

ノイズのようなコードを見かけた時に、

単純に書き手の能力不足でそういう記述になっているのか、

色々模索した上での意図的な記述なのか、

というのが判断できない

一方で、要件が予め網羅されている場合は、最初から書き直したほうが速い、という可能性もある

これはちょっと飛び過ぎか

このスライドが80行程度のプログラムを題材にしているのでそういう発想になるのかも

思うのは、テストコードって割と隙間が多くなりがちではないのか？という点

インクリメンタルにやっていけるのは強みだろう

抽象度の高い要件を明確に見出して、それに対してアプローチする

最初に要件が全てわかってるなら、最初から全てのテストケースを書けば良い

実際は、実装にランダム性があったりして、実装を修正しないとテストが通らない、ということもあり、TDDの回転はそれに対しても効果的にアプローチできている

参考