(리팩터링 2판) 1장, 2장 - 성능, 경제적인 효과

지엽적인 성능 개선에 집착하지 마라

리팩터링 하다 보면, 예를 들어 반복문을 분리면서 같은 인덱스로 반복을 2번 돌게되는 경우 같은, 성능 관점에서 비효율적인 코드를 종종 마주치게 된다. 그 때 읽어보면 좋은 글.

무엇보다도 반복문을 쪼개서 성능이 느려지지 않을까 걱정할 수 있다. 이처럼 반복문이 중복되는 것을 꺼리는 이들이 많지만, 이 정도 중복은 성능에 미치는 영향이 미미할 때가 많다. … 경험 많은 프로그래머조차 코드의 실제 성능을 정확히 예측하지 못한다. 똑똑한 컴파일러 들은 최신 캐싱 기법 등으로 무장하고 있어서 우리의 직관을 초월하는 결과를 내어주기 때문이다. 또한 소프트웨어 성능은 대체로 코드의 몇몇 작은 부분에 의해 결정 되므로 그 외의 부분은 수정한다고 해도 성능 차이를 체감할 수 없다. …

때때로 리팩터링이 성능에 상당한 영향을 주는 경우라도 나는 개의치 않고 리팩터링한다. 잘 다듬어진 코드라야 성능 개선 작업도 훨씬 수월하기 때문이다. 리팩터링 과정에서 성능이 크게 떨어졌다면 리팩터링 후 시간을 내어 성능을 개선 한다. … 결과적으로 더 깔끔하면서 더 빠른 코드를 얻게 된다.

따라서 리팩터링으로 인한 성능 문제에 대한 내 조언은 ‘특별한 경우가 아니라면 일단 무시하라’는 것 이다.

마틴 파울러의 리팩터링 2판, 챕터 01 에서

리팩터링의 본질은 코드베이스를 예쁘게 꾸미는 데 있지 않다.

… 하지만 내가 볼 때 사람들이 빠지기 쉬운 가장 위험한 오류는 리팩터링을 ‘클린 코드’나 ‘바람직한 엔지니어링 습관’처럼 도덕적인 이유로 생각하는 것이다. 리팩터링의 본질은 코드베이스를 예쁘게 꾸미는 데 있지 않다. 오로지 경제적인 이유로 하는 것이다. 리팩터링은 개발 기간을 단축하고자 하는 것이다. 기능 추가 시간을 줄이고, 버그 수정 시간을 줄여준다. … 리팩터링하도록 이끄는 동력은 어디까지나 경제적인 효과에 있다.

마틴 파울러의 리팩터링 2판, 챕터 02 에서

Design Stamina Hypothesis

https://martinfowler.com/bliki/DesignStaminaHypothesis.html