[TIL 7] 실용주의 프로그래머 #7. 코딩하는 동안

오늘 TIL 3줄 요약

• 의도적으로 프로그래밍하자
• 가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.
• 코드를 리팩토링할 이유는 없다.

TIL (Today I Learned)

2022.04. 02

오늘 읽은 범위

7장. 코딩하는 동안 p273-p348

책에서 기억하고 싶은 내용을 써보세요.

우연에 맞기는 프로그래밍

• 우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다.
• 의도적으로 프로그래밍해야 한다.
• 우연에 기대다 보면 결국 문서화되지 않은 에러나 예외적인 경우의 동작에 의존하게 되고 만다.

=> 우연에 맞기는 프로그래밍, 나도 종종 해왔던 프로그래밍 방식이다. 기능을 구현해서 테스트코드를 작성하고 테스트는 초록불이 들어왔다.(어떻게 성공했던 걸까..) "음.. 좋아! 잘되네" 거침없이 PR을 보낸다. 우연으로 테스트에 성공한 내 코드는 프로덕션 환경에 배포된다. 조금 지나자 에러 로그가 기록되면서 cs가 들어왔다. 잘 되던 기능이 갑자기 안 된다는 것이다. 그렇다. 나는 내가 작성한 코드가 어떻게 돌아가는지 원리를 잘 파악하지 못한채, 우연히 성공한 테스트에 의존한 것이다. 다시 한 번 더 우연한 성공에 의존하지 않아야 겠다고 다짐하게 되는 구절이었다.

의도적으로 프로그래밍하기

• 언제나 여러분이 지금 무엇을 하고 있는지 알아야 한다.
• 더 경험이 적은 프로그래머에게 코드를 상세히 설명할 수 있는가? 그렇지 않다면 아마 우연에 기대고 있는 것일 터이다.
• 자신도 잘 모르는 코드를 만들지 말라. 완전히 파악하지 못한 애플리케이션을 빌드하거나, 이해하지 못한 기술을 사용하면 우연의 함정에 빠질 가능성이 높다. 이것이 왜 동작하는지 잘 모른다면 왜 실패하는지도 알 리가 없다.
• 신뢰할 수 있는 것에만 기대라. 가정에 의존하지 말라. 무언가를 신뢰할 수 있을지 판단하기 어렵다면 일단 최악의 상황을 가정하라.
• 코드뿐 아니라 여러분이 세운 가정도 테스트해 보아야 한다. 어떤 일이든 추측만 하지 말고 실제로 시험해 보라.
• 앞으로 어떤 것이 잘 돌아가는 듯이 보이기는 하지만 여러분이 그 이유를 모를 경우, 그것이 우연은 아닌지 반드시 확인하라.

=> 기능을 구현하고 코드 리뷰를 할 때, 코드를 왜 이런식으로 작성했는지 상세히 설명하지 못한 경우가 있다. 동작 원리는 잘 모르겠지만 일단 성공했고, 원하는 대로 잘 돌아가는듯 해서 구현이 완료됐다고 했던 것이다. 팀장님에게 자주 들었던 말이 있다. "기술을 사용 할 때는 기술이 어떻게 돌아가는지 파악하고 사용해라, 그렇지 않으면 문제가 발생했을 때 어떻게 대체해야 할지 모르고 최악의 경우엔 작성된 코드를 전부 갈아 엎어야 할 수도 있다." 지금도 이 말을 항상 떠올리며, 의도적으로 프로그래밍하기 위해 노력한다. 확실히 우연에 맡기지 않는 프로그래밍을 하다보니 문제가 발생해도 원인을 이상한데서 찾지 않고, 정확하게 문제점을 찾을 수 있게 된 것 같다.

실전에서의 알고리즘 속도

• 사용하는 알고리즘의 차수를 측정하라.
• O(n2) 알고리즘(선택정렬, 삽입 정렬)이 있다면 분할 정복(퀵 정렬, 힙 정렬)을 사용하여 O(n log n)으로 줄일 수 없는지 시도해 보라.
• 어떤 일을 하는 코드인지 코드 자체에 대해서도 생각해 보라.
• 입력 값 n이 작을 경우, 단순한 O(n2) 코드가 복잡한 O(n log n) 코드보다 더 좋은 성능을 내기도 한다.
• 가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.

=> 알고리즘은 상당히 어려운 학문이다. 아마 개발자로 일한다면 평생 공부하면서 함께 가야 하는 동반자가 아닐까 생각한다. 나는 보통 기능을 완성하고 잘 동작한다면 조금 더 나은 방향의 최적화는 없을지 고민한다. Clean한 코드 작성 방법은 없을지, 3초 걸리는 작업을 1초로 줄일 수는 없는지 말이다. 최적화를 위해 우선 속도가 빠른 알고리즘을 선택해서 코드에 적용해보고 테스트 해보자. 적용 후 속도가 적용 전보다 늦을 수도 있다. 그래도 괜찮다. 우리가 해야 할 것은 항상 실무에 더 적합한 방법은 무엇이 있을지 더 고민하고 시도하는 것이다.

리팩터링은 언제 하는가?

• 여러분이 작년이나 어제, 심지어 10분 전과 비교해서 더 많이 알게 되었다면, 리팩터링을 한다.
• 언제나 바로 지금이 최적기다. 코드를 리팩터링할 이유는 아주 많다.

=> 코드를 작성하다가 지금 당장은 더러워도 기능이 잘 돌아가니까 다음에 리팩토링해야지 한 적이 있을 것이다. 나도 그랬다. 하지만 그 다음은 절대 오지 않았다. 리팩터링을 다음으로 미루지 말고, 발견한 즉시 실행에 옮기자. 다음은 절대 오지 않는다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

스스로 많은 반성을 하게 만드는 내용이었다. 그동안 잘 모르는 내용에 대해서 우연에 맞기고, 리팩토링은 나중에 해야겠다면서 미뤄왔다. 이번 장은 나에게 해주고 싶은 말을 압축적으로 풀어 쓴 내용이란 생각이 들었다. 오늘부로 프로그래밍을 할 때는 우연에 맞기지 않고 의도적으로, 같은 코드라도 더 나은 방법은 없을지, 리팩토링의 진행은 언제나 바로 지금이라는 마음으로 임해야 겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

알고리즘은 역시나 어려운 내용이였다. 철저하게 복습해서 내 것으로 만들자!