Clean Code ~Ch.7
XPA 코드를 작성하면서 오류코드의 필요성에 대해 느껴서 뿌듯하다고 앞에서 적었다. 근데 그보다 더 나은 방법이 있었다. 아 물론 나는 사용자가 두명뿐이라 오류 코드를 보면서 사용법에 대해 알려주려고 그런 것도 있었다. 하지만 글을 쓰며 생각해보니 이마저도 예외처리를 해서 프로그램에서 알려주는 방법도 생각난다.
스프링을 사용하며 예외를 이전보다는 적극적으로 사용하긴 하지만 여전히 잘 다루지 못 한다는 걸 다시 한 번 느낀 챕터였다.
Chapter.7
간단히 말해, 뭔가 잘못될 가능성은 늘 존재한다.
그전까지 나 혼자 사용할 프로그램은 잘못될 가능성은 염두에 두지 않았다. 하지만 사용자가 있는 (염두에 두는) 프로그램을 만들다보니 무슨 이벤트가 발생할지 모르기때문에 최대한 많은 가능성을 열어두며 코딩을 하게 된다.
처음 느낀 것은 앞에서도 말했듯이 XPA를 만들면서 느꼈지만 스프링으로 백엔드를 다루면서도 많이 느끼고 있다. 어느 프로젝트라고는 말을 하지 않겠지만 프론트에서 정말 API 명세서가 무색할 정도로 기발한 요청이 들어오기도 하고, 백엔드에서 예외처리를 하지 않아서 이상한 결과를 리턴하는 경우도 왕왕 보았다. 그 외에도 코딩이 아직 낯선 친구들이 오류가 났다고 가르쳐달라고 보여주는 코드들에서 정말 다양한 경우를 봤다.
사실 이렇게 말을 하면 나빼고 다 코딩 못 해라는 식의 말을 하는 것 같다. 하지만 나는 이런 경우를 보고 나도 누군가에겐 이런 느낌이라고 생각을 한다. 그래서 나는 회의를 할 때 말고는 뭘 잘 한다고, 안다고 말을 하지 않는 편이다. (틀리면 부끄럽기도 하고)
너무 자만하는 식의 말을 했지만 핵심은 이 문장은 정말 맞는 말이고 나는 정말 겸손해지려고 노력하는 중이다.
오류 코드보다 예외를 사용하라
나는 예외를 잘 다루지 못 해서 오류 코드를 사용했다. 그마저도 직접 카카오톡으로 전해받았다. 물론 사용자가 적어서 가능한 일이었지만 예외를 능숙히 다룰 수 있었다면 조금 더 영리하게 처리할 수 있었을 것인데 아쉬움이 남는다.
하지만 이런 경험이 있기에 예외가 왜 중요한지 더 절실히 느끼고 있다고 생각(정신승리)한다.
Try-Catch-Finally 문부터 작성하라
XPA는 Openpyxl라이브러리를 사용해 엑셀 파일을 조작했다. XPA는 다양한 버전이 존재하는데 첫 버전에서는 예외를 사용하지 않고 (아마 내 기억에 완전은 아닌 것 같다. 구글링에서 찾은 코드에 예외가 있었다면 그대로 사용했을 것이다.) 오류 코드를 사용해 만들었다. 두번째 버전부터 예외를 어느정도 사용하기 시작했다. 지금 생각이 나는 것이 엑셀 파일을 불러올 때 FileNotFoundException을 사용했던 것 같다.
하지만 당연하게도 def __init__()안에 try-catch 문이 존재했고 이것이 코드가 지저분하게 만드는 것을 알고있었지만 마땅히 해결법이 떠오르지 않아서 그대로 뒀다. 책에서는 함수를 따로 분리해서 try-catch 문만 있는 함수로 분리하라고 했고 정말 당연한 것인데 이게 왜 생각이 안 났는지 안타깝고 멍청한 내 모습에 조금 화가 났다… (정말 조금)
다음 XPA는 만들 일이 있다면 C# 으로 만들고 싶은데 클린 코드를 읽은 성과가 나왔으면 좋겠다.
오류를 원거리에서 처리하기 위해 예외를 사용한다.
Checked Exception 주제에서 나온 문장이다.
이 책을 읽으면서 언어에 대해서 꽤 많이 생각을 하게 된다. 내가 코딩 교육을 하면서 늘 하는 말이 있다. 결국 사람이 만든 언어다. 너무 겁먹지 말고 왜 이 단어를 사용했을지 생각해보면 어렵지 않다. 이런 표현이 맞을까 모르겠는데 이 책은 이걸 내가 듣는 느낌이다.
다른 분야는 모르겠지만 적어도 내 생각에 개발 분야에서는 모든 것은 필요에 의해 나왔다고 생각한다. 이미 등장한 뒤 관습이 되어서 굳어버린 경우를 제외하고는 늘 효율을 추구해오고 있다고 생각한다. 굳어버린 관습마저도 최근에는 많이 변화하고 있다고 생각한다.
다양한 문법들부터 클래스, 예외, 비동기를 지원하는 언어부터 디자인 패턴, 아키텍쳐등 다양한 개발 방식까지 모든 것이 필요에 의해 등장하고, 효율에 의해 진화하고 있는 것 같다.
그리고 이 생각들은 이름에 잘 녹아 있는 것 같다. Spring을 공부하며 이 점을 많이 느끼고 있다. 물론 스프링은 오래된 프레임워크이기때문에 이름을 봐도 쉽게 이해 못 하는 개념도 있다. 하지만 개념을 공부하다보면 적어도 왜 이런 이름을 지었는지는 어렴풋이나마 알 수 있다.
쓰다보니 무슨 예외 읽고 이렇게 억지로 엮어내냐 말할 수 있겠지만 적어도 내게는 내가 가르치는 방식을 나한테 적용하지 않는 모습을 반성할 수 있는 계기가 되었다.
하지만 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.
오류가 뜨지 않는 프로그램이 제일 좋지만 불가능하다. 그래서 잘 잡아내야 한다.
실제로 외부 API를 사용할 때는 감싸기 기법이 최선이다.
하늘 고래를 개발할 때, discord.py 라이브러리가 종료가 된다는 말이 나오고 이어받은 라이브러리들이 나올 때였다. 라이브러리를 그대로 사용하는 것은 후에 업데이트가 이루어질 때, 코드를 전부 뒤엎어야한다고 판단했다. 그래서 감싸기 기법이라는 용어를 알기도 전부터 한단계 거쳐서 사용하는 클래스를 만들어서 사용해보자고 생각했다. 하지만 기술의 부족인지 센스의 부족인지 아니면 내 스스로의 불만족인지 무슨 이유인지는 모르겠지만 코드가 지저분하다는 느낌을 받았다. 그래서 코드를 다시 뒤집어 엎고 새로 작성을 시작했다.
나조차도 감싸기 기법을 사용해야한다는 것을 알 정도로 당연한 것이지만 나는 잘 사용하지 못 했다. 더 공부를 해서 이런 것을 잘 녹여내는 코드를 작성하고 싶다…
애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다.
파이썬에서는 null과 비슷한 것인 None 이 있다.
며칠전, XPA 코드를 다시 볼 기회가 있어 깃허브에 들어갔다. 하지만 이 책에서 그토록 싫어하던 None을 넘긴 함수를 발견했다. 당시에 코드를 짤 때는 정말 나름 고심해서 작성을 했었겠지만.. 지금의 나는 이해를 할 수 없었다. 당연하게도 왜 None을 받는지 이유를 몰라서 결국 다시 함수의 원형을 확인하고 나서야 코드를 볼 수 있었다.
null을 넘기는 것은 정말 죄악이다. 어쩌면 플래그 인수를 사용하는 것과 비슷하다고 생각한다. 플래그 인수를 사용하면 결국 함수의 원형을 다시 봐야 이해할 수 있다. null 도 비슷하다고 생각한다. 이외에도 코드를 작성할 때, null을 넘길 이유는 없다. 우리가 프로그램을 만드는 이유는 무언가를 만들어내고 싶기 때문이다.
코틀린을 너무 재밌게 공부했던터라 null에 조금 더 박한 것 같다. 그래도 내가 쓴 코드를 봐서라도 null을 넘기는 것은 옳지 않다는 것을 알 수 있다.