1.5코드베이스의 망령

프로그래머로서 자질은 자신이 작성한 코드가 아닌, 그것을 대하는 태도와 작성하는 방식에 의해 결정된다.

보통의 프로그래머는 오랜 시간 동안 자신의 코드를 관리하지 않는 경향이 있다. 자신의 똥통에 뒹굴지 않고 남의 똥통에 뒹굴거나 똥을 쌀 새로운 곳을 찾는다. 참 대단하다. 심지어 애정 가득한 프로젝트도 흥미가 사라지면 방치하는 경향이 있다.

— 76 페이지, 개인적으로 너무 찔렸다.

예전에 작성한 코드를 살펴보면 몇가지 이유로 끔찍한 기분에 휩싸일 수도 있다.

외관

레이아웃 이슈들이다. 저자는 C++의 사례를 드는데, 개인적으로 자바스크립트에선 아주 큰 이슈가 있진 않았다. 다만 회사에 처음 왔을때 문장 끝에 ;가 없는건 약간 어색했다.

최신 기술

라이브러리의 진화는 과거에 작성한 코드를 뒤처지게 만든다.

관례

오래된 코드에는 종종 관례에서 많이 벗어난 것들이 보인다. 올바른 관례를 몰라서일수도 있고, 관례가 정립되기 전에도 있다. 저자는 C++에서 람다 식 등 새로운 기능이 추가되면서 트램펄린 같은 코딩 방식이 낙후된 것을 예로 든다.

설계 결정 사항

더 많은 것들을 배우면서, 코드 설계를 수립하는 더 나은 방식을 깨닫는다.

버그

새로운 시각에서 재검토해보면, 때로는 이전에 놓친 명백한 문제를 발견할 수 있다. 특정 종류의 버그에 지독하게 당해본 뒤에 예전 코드를 보면 그 코드의 버그를 자연스럽게 발견할 수 있게 된다.

기존의 코드를 돌아보는 것은 자신을 위한 코드 리뷰이자 가치 있는 행동이다. 시간의 흐름과 더불어 프로그래밍 세상이 얼마나 변화했는지, 그리고 자신의 기술이 얼마나 나아졌는지에 대해 감사하는 것은 중요하다. 더 이상 적절하지 않은 과거의 코드를 찾아내는 것은 좋은 일이다.

---

🥸 생각해보기

1. 예전의 코드가 지금은 어떻게 보이는가? 그다지 나빠 보이지 않는다면, 최근에 새로운 뭔가를 배우지 않았음을 뜻하는 것인가?

회사에서도 가끔 예전에 내가 썼던 코드를 새로 쓸 때가 있고, 개인 프로젝트의 코드도 갈아 엎을 때가 있다. 그럴때면 그때그때 다른 이유로 과거의 자신이 매우 부끄럽다. 초기에는 조건문을 너무 장황하게 썼던것들이 부끄러웠다(이 책 2장에서 지적한 내용 같은). 가끔은 한치앞도 못 내다본 나쁜 변수명이 부끄러웠다.

이 블로그 프로젝트를 기준으로 한다면, mdx 문서에 들어갈 다양한 커스텀 컴포넌트들이 있는데, 이름을 너무 길게 지어서 쓰기에 불편하다(말하고 나니 조만간 고쳐야겠다는 생각이 든다). 처음에 지을때는 EmphasisBox, Highlight 식으로 무슨 컴포넌트인지 잘 알 수 있게 만들었는데 생각해보면 어차피 혼자 볼 프로젝트인데 굳이 그렇게 하기보단 EB, Ht 이런 식으로 간단하게 할 수 있지 않았을까 하는 생각이 든다. 그런데 그런 생각으로 최근에 만든 Bq(Blockquote) 컴포넌트는 출처를 source라는 이름의 매개변수로 받는다. 이것도 src로 만들었어야하는데...하는 생각이 든다.

최근에 새로운 뭔가를 배웠어도 보기에 나쁘지 않은 코드를 쓸 수 있을것이라 생각한다. 아마 그것을 목표로 해야하지 않을까. 물론, 기능이 바뀌고 라이브러리가 나아졌더라도 당시에는 그것이 최선이었음을 인정할 수 있는 그런 코드.

하지만 동시에, 내 삶의 신조가 '후회하는 삶을 살자'이다. 후회할 짓만 골라서 하자는 의미는 아니고, 계속해서 발전하고 그것을 토대로 과거에 잘하지 못한 선택이 있다면 솔직하게 인정하고 나아가자는 의미다. 과거의 후회스러운 코드는 내가 성장했다는 뜻으로 그런대로 받아들이고 넘어가면서, 매순간 코딩할때는 후회하지 않을 것이라 자신할만한 코드를 써야할 것이다.

2. 주요 언어로 얼마나 오랫동안 일했는가? 그사이 언어 표준이나 내장 라이브러리가 얼마나 많이 바뀌었는가? 당신이 코드를 작성하는 스타일을 형성할 때 어떤 언어 기능에 영향을 받았는가?

자바스크립트(및 슈퍼셋 언어, 라이브러리, 프레임워크)를 써서 프로젝트를 한지 이제 3년이다. 그 사이 체감상 가장 큰 변화는 Next.js는 당시에만 해도 Pages Router가 더 선호되었지만 이제는 App Router 위주다.

또, ECMAScript의 최신 문법들을 가끔 보면 배열에 새로운 메소드(Array.prototype.at()이나 Array.prototype.groupBy(), Array.prototype.toSorted())가 생겼다거나, Web Worker를 통해 성능을 개선한다거나 하는 기능들이 계속 추가되고 있는것으로 보인다. 이러한 요소들은 사실 두 가지 요소 때문에 배우고 쓰기 꺼려졌다.

1. 동료들이랑 싱크가 맞지 않으면 잘난척 하는것처럼 보일까봐
2. 아직도 호환되지 않는 브라우저가 많을 것이라 생각하여(고백하면, 실제로 caniuse에서 찾아보거나 하진 않고 막연히 안될것이라 생각해 시도를 하지 않았다. 앞으로는 적어도 알아보고 미리 공유해보는 태도를 가져야겠다고 생각한다.)

코드를 작성하는 스타일은 아무래도 내게 코딩하는 법을 가르쳐준 사람들(Udemy의 Jonas와 Max가 생각난다)의 영향을 받았다. 또, 회사 동료에게도 큰 영향을 받았다. 다른 사람들과 협업하는 경험을 하지 않았더라면 나는 아마 class문법은 건드리지도 않았을것 같다.

3. 무의식적으로 사용하는 일반적인 관례의 일부에 대해 생각해보자. 이들이 오류가 발생하지 않도록 하는데 무엇이 도움이 되는가?

casing 관련된 관례들이 오류가 발생하지 않도록 하는데 큰 도움을 주는것 같다. 컴포넌트와 클래스의 이름은 대문자로 쓴다거나, 변수나 함수의 이름은 camelCase로 적는다거나 하는 방식으로 해당 이름이 무슨 성격인지 직관적으로 알 수 있다.