# First, After, Later, Never

> Tidying을 언제 하는 게 좋을까? Tidy first? A personal exercise in empirical software design 2부 중에서 발췌, 요약.

[Tidying](https://wiki.g15e.com/pages/Tidying.txt)을 언제 하는 게 좋을까? [Tidy first? A personal exercise in empirical software design](https://wiki.g15e.com/pages/Tidy%20First%20-%20A%20personal%20exercise%20in%20empirical%20software%20design.txt) 2부 중에서 발췌, 요약.

안하기never, 나중에 하기later, 직후에 하기after, 직전에 하기first 옵션이 있음.

## 안하기

- 코드를 고칠 일이 다시는 없는 경우(정말 가끔 이럴 때도 있긴 있음. 이럴 땐 정말로 "망가진 게 아니라면 손대지 마세요").
- 설계 개선에서 배울 게 없는 경우.

## 나중에 하기

코딩할 시간이 1시간 쯤 있는데 새로운 기능 추가를 시작하기엔 좀 애매할 때, 나중에 하려고 미뤄둔 tidying을 하면 좋음.

- 당장 충분한 이득을 주지 못하는 큰 tidying 묶음이 있는 경우
- 작은 묶음 단위로 할 tidying들이 있는 경우

## 직후에 하기

기능 구현을 마치고 한 시간 쯤 tidying을 하는 건 적절. 기능 구현 후 일주일 간 tidying을 하는 건 부적절. 후자의 경우라면 "나중에 하기" 후보.

- 나중으로 미루면 tidying 작업의 비용이 커질 것 같을 때
- 당장 tidying을 안하면 작업이 끝났다는 성취감이 들지 않을 때

## 직전에 하기

Tidying 자체에 너무 매몰되지 않는다면, 되도록 '직전'. 손해보다 이득이 큰 경우가 많음. 단 너무 교조적으로 따르지 말고 다른 옵션(직후, 나중, 안하기)도 고려.

- 당장 고쳐야하는 코드의 이해 또는 수정을 도와주는 경우
- 어떤 tidying을 어떻게 하면 좋을지 보이는 경우