요즘 예전의 알고리즘 머리를 다시 깨우고자
열심히 하루에 하나씩 프로그래머스에서 알고리즘 문제를 풀고 있다.
오늘은 알고리즘 문제를 풀면서 개인적으로 느낀 점에 대해 얘기해보고자 한다.
생각보다 현업과는 거리가 있는 알고리즘
알고리즘 두뇌가 활성화되면 복잡한 요구사항에 대한 구현에 도움이 되는 것은 사실인 것 같다.
조금 더 빨리, 명확하게 요구사항을 구현할 방법을 찾게 된달까?
그런데 빠른 구현, 정확한 구현과는 별개로 최적화, 성능에 대해 고려하는 부분에 대해서는
겪고 있는 현업마다 입장 차이가 존재할 것 같다.
오히려 성능을 올리기 위한 알고리즘이 현업에서는 파악하기 힘든 코드, 재활용하기 힘든 코드가 될 수도 있겠다는 생각이 들었다.
원래 내가 지향하던 코드 작성 방법은 미래의 나와 협업하는 사람들을 위해 '읽히기 쉬운 코드'를 작성한다.
그런데 이런 내 코딩 스타일은 지나치게 모듈화하는 경향이 있어서, 함수를 타고 타고 들어가는 경우가 많아지게 된다.
물론, 프론트엔드 단에서는 백엔드보다 비교적 성능에 대한 이슈가 적은 편이기 때문에 지금까지 문제없이 개발해왔지만
함수형 프로그래밍에 대해 공부해보면서 기존에 내가 가진 스타일만이 전부가 아니라는 사실을 다시 한 번 직면하게 되면서 고민이 더 깊어진 것 같다.
이 점에 대해서는 중급, 고급 개발자분들도 생각이 다양한 것 같다.
이전에 이직을 위한 면접을 진행했을 때, 코드 리뷰 문화에 대해 이야기를 나누면서 나의 이런 고민을 말씀드릴 기회가 있었는데 면접관 분께서는 코드 스타일은 다양하기도 하고, 어느 코드가 좋은 코드라고 말하기 애매한 부분이 있어서 진행하지 않는다고 말씀하시기도 했다.
오히려 성능적인 부분은 비용을 들여 하드웨어를 업그레이드 했을 때 더 휼륭한 퍼포먼스가 나오기도 하기 때문에 분야에 따라서 무조건적인 최적화가 옳지 않을 수도 있겠다는 생각이 많이 들었다.
예외케이스를 미리 고려하는 습관이 미래의 내 시간을 아껴준다.
프로그래머스에서는 문제 제출 전에 입력된 케이스로 미리 코드를 돌려볼 수 있는 기능이 있다.
몇 가지 정도는 프로그래머스에서 자동입력이 되어있지만, 이 입력된 데이터들이 모든 예외케이스들을 반영해주지는 않는다.
그러다보니 프로그래머스에서 미리 입력해준 데이터 케이스를 이용해 코드를 돌려보았을 때에는 모두 정답이었지만
실질적으로 코드를 제출하였을 때는 오답인 경우도 상당히 많았다.
이에 대해, 어떤 사람들은 미리 예외상황에 대한 테스트 케이스를 많이 작성해두어 테스트를 진행한 다음에 제출하는 것이 오답을 줄일 수 있는 좋은 방법이라고 제시하기도 하였다.
실제로 현업에서도 테스트 코드를 미리 작성하는 습관을 좋게 생각하는 것 같다는 느낌을 받았다.
실제 채용 JD에서도 테스트 코드를 작성하는 개발자를 우대하는 경우를 종종 접하기 때문이다.
실제로, 요구사항을 단면적으로 분석하고 예외케이스를 고려하지 않은 상태로 코드를 작성하면
이후 에러 발생 후에 코드를 수정해야 할 일이 많아진다.
앞으로는 코드 작성 이전에 예외케이스에 대한 분석을 철저히 해야겠다는 생각이 들었다.