몇 달 뒤의 나를 위한 코드를 작성하자

1. 쏙쏙 들어오는 함수형 코딩 (Grokking Simplicity: Taming complex software with functional thinking)
2. 파이브 라인스 오브 코드 (Five Lines of Code: How and when to refactor)
3. 전문가를 위한 C++ 5판 (Professional C++, 5th Edition)

개요

• 회사에서 한달에 30만원씩 개인업무지원비를 주는데 덕분에 좋은 책들을 잘 읽고 있다.
• 2023년 상반기 정말 감명깊게 읽은 책 3권을 정리해본다.
• 목표는 더 나은 코드를 작성하는 것.

더 나은 코드란?

• 다양한 관점이 있겠지만, 산업계에 있는 사람으로써, 무엇이든 돈을 아껴주는 코드가 좋은 코드라는 생각이 든다.
  • 개발회사에 있어 돈이란, 결국 개발자의 인건비가 대부분일 것이다. 즉, 돈을 아끼기 위해서는 개발자의 인건비를 아껴야 한다. 여기서 인건비를 아낀다는 말은, 돈을 조금만 들인다는 뜻보다는, 높은 월급을 받아가는 개발자의 생산성을 높인다는 측면이다.
  • 개발은 코드를 작성하는 시간과 코드를 읽는 시간으로 구성된다. 그리고 통상적으로 후자가 더 많은 비율이라고 알려져있다.
  • 즉, 개발자가 코드를 읽는 데 들어가는 시간을 아낄 수 있으면 개발자의 인건비를 아낄 수 있다고 생각한다.
• 사설이 길었다. 결국, 기계가 읽기 쉬운 게 아니라 사람이 읽기 쉬운 코드가 좋은 코드라고 생각한다.
  • 말그대로, 극단적으로, 자연어처럼 술술 읽혀야 한다고 생각한다. 그래야만 읽고 이해하는 데 들어가는 시간을 줄일 수 있기 때문이다.
    • ps. 특히 C++ project 의 경우 O3 수준에서는 컴파일러가 결국 로직을 다 만지기 때문에, 세부적인 프로그래머의 잔잔바리 차력쇼는 지양되어야 한다고 생각한다 (e.g., 더 중요한 건 근본적으로 O(1)인데 O(n)을 채택하고 있지는 않은지. O(n)이더라도, accuracy에 영향을 주지 않는 선에서 n자체를 줄일 수 있는지 등. 가장 좋은 부품은 ‘없는’ 부품.)
• 근데 그것으로 충분할까? 개발자가 코드를 읽는 시간이 왜 자꾸 많이 소요될까? 심지어 남의코드도 아니고 불과 몇 달전 내가 작성했던 코드인데?
  • 더욱이 이 문제는 코드를 단순히 몇 달 뒤 다시 돌려보는 데 그치는게 아니라, 기능을 확장해야만 하는 사태가 벌어질 때 더 중대해진다. 여기를 고쳤더니 저기가 안되는 일들이 발생하고…, 다시 코드베이스 전체를 뜯어봐야 하는 일, 이 현실에서 벌어진다.
  • 점점 나의 뇌기능이 퇴화되서일까? 그게 아니라면 근원적으로 내가, 실리적인 방식으로 코드를 작성해오지 않았다는 말이 된다. 그리고 그게 좀 더 현실적이고, 극복가능한 명제일 것이다.
• <여기를 고쳤더니 저기가 안되는 일들이 발생하고…, 다시 코드베이스 전체를 뜯어봐야 하는 일> 따위의 사태를 시스템적으로 막을 수 있는 구현습관이 만약 있다면?
  • 그런 평소의 질문에 답해준 책들 3권이다.

1. 쏙쏙 들어오는 함수형 코딩 (Grokking Simplicity: Taming complex software with functional thinking)

• 원제가 더 마음에 든다: Grokking Simplicity: Taming complex software with functional thinking
• 단연 올해 내 마음속 상반기 1등 책이다.
  • 읽다보면 functional coding(도 당연히 다루지만)이 아닌 functional thinking 에 대한 필요성부터 빌드업을 해나가는 것이 일품이었다.
• 핵심은, 함수는 side-effect 가 없어야 한다는 것이다.
  • 굳이 이름을 붙이자면 “pure function” 이라고도 한다.
  • 책 초반부에 이것을 강요한다기 보다 (모든 상황에 항상 이렇게 하자 라기보다), 이런 마인드 를 장착하자고 권유해나가는 빌드업이 친절하고 강력했다. 그래서 앞부분에 이야기가 길고, 실제 함수형API 테크닉은 꽤나 지나서 중반쯤부터 나온다.
    • 맵리듀스니 커링이니 하는 것들은 어떻게 보면 기술적인 차력쇼에 지나지 않는 느낌이 들었다. 이런 외형적으로 드러나는 현상적인 것에 함수형프로그래밍이라는 고정관념적 딱지를 붙여두고, 지금까지 함수형은 이래서 OOP에 비해서 안돼, 별로야, 단점이 분명히 있을거야 라며 관심을 많이 가지지 않아온 건 아닌가 반성을 하는 기회였다.
  • 더 좋았던 것은 마인드에 그치지 않고 실용적이기까지 하다는 점이다. 예를 들어 conventional 한 for loop를 어떻게 함수형으로 변환하는지 과정을 차근차근 밟아나간다. 그리고 책 뒷부분에서는 여러 어려운 용어들이 곁들여지는 함수형프로그래밍 테크닉들도 결국 소개되는데, 이쯤되면 이미 본질을 알고 (중요한 것은 함수형API가 아닌 함수형사고) 앞에서부터 너무 친절한 가이드를 받았기 때문에 마음이 압도되지 않고 함수형프로그래밍에 익숙해질 수 있었다.
  • 결론은 한 줄인데, 이렇게 친절하게 가이드 하지 않으면 사실 저 결론을 마음에 심을 수 없었을 것이다.
    • ps. 이 책을 읽을 때의 느낌을 받는 적이 자주 있지는 않다. 그나마 최근에는 밑바닥부터 시작하는 딥러닝 3권 이 그랬었다 (여기서도 역시 핵심은 ‘계산그래프로 수행하는 auto diff 가 딥러닝의 모든 것이다’ 인데 그걸 직접 구축해나가는 과정이 일품이었다).
• 반성타임
  • SLAM open source 들을 보다보면 하나의 만능클래스를 구성하고, 이 클래스가 변수를 수십개 가지는 식의 구현을 자주 보게 된다. 이른바 노드단위 싱글파일 인데… 여러모로 유지보수 관점에서 좋지 않다는 생각이 든다. 코드를 읽는 데 시간이 점점 많이 소요될 것이다. 만능클래스 메서드는 클래스의 모든 변수에 접근가능하게 되므로 실제 인자로 받지 않은 변수들까지 맘대로 접근하고 고치는 만행들이 메서드 여기저기에서 벌어질 것이다. 그러면 언젠가 하나의 메서드 수정 시 다른 메서드들이 영향을 받는 순간이 오고.. 코드 전체 (몇천줄) 를 다시 다 뜯어봐야하는 시간이 올 것이다. ROS노드단위로 싱글파일을 작성하다보니 전역변수도 마구 사용하고 있는데 이 역시 모든 함수에서 접근가능하다는 점에서 만능클래스의 변수들과 같은 처지이다.
  • 전역변수가 나쁘다는 건 쉽게 생각할 수 있었지만, 이 책의 관점에서, 무인자(zero-argument) 함수 역시 (매우!) 나쁜 것이었다. getter만이 신성한 무인자 함수가 되어야하지 않을까? 무인자의 탈을 쓰고 실제로 함수 내부에서 함수외부의 변수들에 마구 접근하는 만능메서드들이 생기게 되는데. 더 큰 문제는 구현자(프로그래머) 가 이런 현상을 잘못 지지 (함수 인터페이스 설계 시 인자 개수가 적을수록 무조건 좋아!) 하고 오남용하는지도 모르게 클래스가 비대해지는 상황이 아닐까. 가장 큰 피해자는 몇 달 뒤 내가 될 것이다. 이런걸(스스로도 예상하지 못한 현상들을) 고친다고 시간을 다 쏟고 있노라면, 버그를 잘 만들고, 그걸 빨리 못고치는 프로그래머라는 평판을 듣게 되진 않을까. 성장의 가장 큰 동력원은 두려움이다.
  • ps. 최근 본 예쁜 SLAM code 는 kiss-icp 였다. 듣기로 저자가 엄청 의식적으로 코드를 잘 짜려는 습관이 있으셔서… 디펜던시 마저도 최소화 하려고 하신다던데. 그래서 ICP도 직접 J구해서 수행하는 부분이 일품이다.

2. 파이브 라인스 오브 코드 (Five Lines of Code: How and when to refactor)

• 앞의 책보다 좀 더 급진적인 의견을 제안한다. 하나의 함수는 5개의 실행 이하로 구성되어야 한다고 주장한다.
  • 이를 뒷받침하기 위해 실제로 모두 코드기반으로 전/후 를 보여주며 설명한다. 봐, 할 수 있지?
• 어쨌거나 그런 코드들도 그저 하나의 예시이기 때문에, 이 책에서는 역시 내 고정관념을 깨고자 하는 울림정도를 얻어가는 기회로 삼는 데 집중하였다.
• 그런데 생각해보면 앞의 책과 이어지는 맥락이 있다. 사이드 이펙트를 없애려고 노력하다 보면, 개별 함수들이 알아야하는 사전 지식 (인자 개수) 을 의도적으로 잘 설계해서 제한해야만 한다. 그렇게 잘 하다보면 함수마다 5개 이하의 실행으로 구성할 수도 있을수도 있지 않을까? 라며 마음이 열리는 듯(저자의 의견에 동의하는) 하였다.
• 역시 앞의 책에서 얻은 가장 큰 수확인 마인드탑재, 처럼, 이 책에서도 그러한 마인드를 탑재하는 것에 노력했다. 상황상 당연히 모든 함수를 다 5줄 이하로 구성하는 것은 때때로 더 쓸데없는 시간이 소요되는 일일수도 있겠다. 어쨌거나 핵심은 모든 경우에 그렇게 무조건 하자가 아니라, 최대한 그렇게 할 수 있는 상황이라면 그렇게 하려고 한번 더 생각해보자, 라는 마인드라고 생각한다.
• 그리고 클린코드가 어쩌네 저쩌네 사실 피곤한 부분들이 많은데, 5줄이하로 하려고 노력해라! 라는 지침은 단순해서 어쨌거나 실용적이라고 생각한다. 한번 읽어볼만한 책.

3. 전문가를 위한 C++ 5판 (Professional C++, 5th Edition)

• 사실 5판 번역을 기다리고 있었는데 이제 나와서 산 책이다. 4판으로 C++ 기초문법을 공부하는 데 도움을 받았어서, 의리로 산 책.
• … 이라기엔 C++20 feature 들을 다루고 있는 현재 번역서 중 가장 충실한 책이라, C++20 을 미리 공부할 겸 구매한 책, 이며 그 부분에 대해서 만족하며 읽고 있다. 그 외에는 4판과 거의 유사하다.
• 마치 C++기초플러스… 같은 두꺼운 책인데 그 책보다는 좀 더 전개나 설명이 쉬운 것 같아서 이 책을 좋아함. 두껍기 때문에 한두달만에 한번읽고 끝낼 책은 아니긴 하다. 짬날 때마다 한챕터씩 봤던 챕터도 한번씩 또 보고 하는 책.
• ps. 4판이든 5판이든 이정도 문법을 한두번 정도 본 다음에는 cppcon의 talk들을 보는 것이 실무관점에서는 좀 더 도움이 되고 있다.

결론

• 근데 최고로 중요한 (그리고 제일 어려운) 건 이름짓기 가 아닐까…