프로그래밍의 규칙

seok9***l2024-06-25

유명한 게임 회사의 공동 설립자이자 책임자가 이야기하는 프로그래밍 규칙 이야기를 다루고 있다. 여기서 규칙이라는 것이 포인트인데 이 책에서 다루는 모든 규칙은 실제로 저자의 회사 개발 조직에서 하고 있는 것들인데 이것이 그들의 문화 그 자체라고 한다. 그리고 이것을 강하게 지키는 것이 성공을 이끌었다고 말한다.

가장 인상 깊었던 내용을 정리해 봤다.

생각하게 하지 말라

일관성의 핵심은 모든 것이 최대한 기계적이어야 한다는 것이다.
명명과 관련된 팀의 규칙이 판단의 여지를 주거나 깊이 생각하게 만든다면 그 규칙은 잘 작동하지 않을 것이다.
일관성을 형성하는 가장 쉬운 방법은 모두가 따르는 기계적인 규칙을 정하는 것이다.
가장 중요한 것은 명명 규칙의 세부 사항이 아니라, 기계적이고 잘 문서화돼 있으며 잘 지켜지는 강력한 규칙을 갖고 있다는 사실 그 자체다.
덕분에 우리는 모두가 같은 것에 같은 이름을 선택하고, 다른 사람과 일하는 것이 마치 나 자신과 일하는 것처럼 느껴지는 낙원으로 향한다.

저자는 꽤 단호한 어조로 내용을 전개한다. 하지만 설득력 있는 예시와 경험 사례로 왜 이렇게 생각하는지, 그리고 자신의 팀과 조직이 왜 이런 규칙을 만들고 지켜나가는지에 대해 풀어나간다.

최근에 여러 가지 경험을 하면서 나의 개발방법론이라는 것이 윤곽을 드러내고 있는 것 같은데 이를 조금 더 구체화할 수 있는 좋은 시간이었다. 코드를 작성하는 사람으로서, 개발자로서 나와 조직의 생산성과 효율성을 올리기 위해 규칙을 정해야 한다면 이 책을 읽어보는 것을 적극 추천한다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

moo***l2024-06-25

프로그래밍의 규칙: 실무에서 빛나는 21가지 개발 비법

크리스 짐머만의 "프로그래밍의 규칙"은 더 나은 코드를 작성하기 위한 21가지 개발 비법을 소개하는 책입니다. 주로 프로그래밍 경험이 있는 개발자들을 대상으로 하고 있습니다.

이 책은 각 장마다 프로그래밍의 중요한 규칙을 다룹니다. 이 규칙을 통해서, 단순성의 중요성과 그것을 유지하는 방법, 테스트의 중요성과 상태 유지 코딩의 어려움, 명확한 네이밍의 중요성, 불필요한 일반화를 피할 것, 성급한 최적화의 위험성 등을 파악할 수 있습니다. 또한 코드 리뷰의 중요성, 실패 케이스의 제거, 실행되지 않는 코드의 문제점, 요약 가능한 코드 작성 등의 주제도 다룹니다. C++ 코드 읽기에 대한 파이썬 및 자바스크립트 개발자들을 위한 부록도 제공하여 다양한 언어를 사용하고 있는 개발자들을 대상으로 이해를 돕습니다.

체계적이고 실용적인 프로그래밍 규칙을 제시한다는 점에서 이 책이 돋보입니다. 다양한 언어와 환경에 적용할 수 있는 일반적인 원칙들을 다루고 있어, 폭넓게 활용할 수 있습니다. 책에서 제공하는 다양한 예제와 조언들은 실무에서 직접 활용할 수 있는 실용적인 내용입니다. 이 내용을 통해 개발자들은 보다 안정적이고 효율적인 애플리케이션을 개발할 수 있을 것입니다.

하지만, 일부 내용들이 초보 개발자들에게는 다소 어렵게 느껴질 수 있습니다. 핵심 개념에 대한 보다 자세한 설명이나 실습 예제 등을 통해 독자의 이해도를 높이는 시도를 했으면 어땠을까 하는 아쉬움이 있습니다. 또한 책의 내용이 작가의 경험이 바탕이 되는 만큼 게임 개발 중에서 적용된 규칙이라 볼 수 있어 다른 영역에서 개발하고 있는 사람에게는 수용하기가 쉽지 않은 부분도 있는 것 같습니다.

이 책에서 다루는 내용은 실제 프로젝트에서 코드의 가독성, 재사용성, 유지 보수성, 테스트 용이성, 확장성 등을 향상시키는 데 유용하게 활용될 수 있습니다. 개발자들은 이 책의 내용을 바탕으로 실제 프로젝트에 적용해서 효과적이고 효율적인 소프트웨어를 개발할 수 있을 것이라 기대합니다.

마무리

"프로그래밍의 규칙"은 프로그래밍 분야에서 유용한 할 21가지 규칙을 다루고 있습니다. 각 규칙에 대한 상세한 설명과 실제 사례를 제공하여 이해도를 높였습니다. 규칙들이 실제 프로젝트에서 어떻게 적용될 수 있는지 구체적으로 보여주고 있어, 전반적으로 프로그래밍 실력 향상과 효율적인 코드 작성을 위한 유용한 지침을 제공하고 있습니다. 이 책은 중급 이상의 개발자들에게 추천할 만하며, 실무 활용도를 높이는 데 도움이 될 것입니다.

한빛미디어 < 나는리뷰어다 > 활동을 위해서 책을 제공받아 작성된 서평입니다.

binsoop***l2024-06-23

프로그래밍을 어떤 규칙에서 작성하고 있는지 생각해 보게 하는 책

> 진행에 앞서

개발자로 오랜시간 지내다보면 종종 하게되는 생각이 있다.

'지금 작성하는 코드는 최선일까?'

'어떻게 작성하면 더 좋은 코드를 작성할 수 있을까?'

그래서 이와 관련된 여러 책을 보기도 한다.

이러한 책을 볼 때마다 느끼는 것은 내가 실제로 체험한 경험에 비례해서 공감이 된다는 사실이다.

내가 쉽게 이 길을 가기 위해 경험이 별로 없는 내용이나, 혹은 고민의 흔적이 별로 없는 것에 대해서는 책을 읽어도 별로 들어오지 않는다.

또한 그 당시에는 익혔다 할지라도 실제 내 개발상황에서는 적용되기가 어렵다.

그것은 나의 고민이 빠졌기 때문이다.

그래서 이런 책은 나의 고민과 함께 읽어야만 진짜 내것이 될 '확률'이 높아진다.

또, 이런 고민은 나의 경험에 비례해서 올라간다.

이번에 책을 읽으면서는 나의 경험이 얼마나 누적되었는지를 생각해볼 수 있었던 시간이었다.

> 책에 대한 간단한 정보

책의 표지는 단순하다. 프로그래밍을 작성하는 규칙을 정석으로 알려줄 것만 같다. 그래서 좋았다.

다만, 이 책의 표지는 안쪽으로 감싸있지 않고, 그냥 미국책과 같은 스타일로 겉면만 감싸도록 되어있다.

그래서 이 책을 보면서 모서리가 쉽게 해지는 것을 경험하였다.

> 인상깊은 부분들

이 책의 가이드를 서문에서 수록하였다.

책을 읽으면서 이런 개발자와 같은 설명이 담긴 책은 흔치 않아서 좋았다.

어떤 부분을 어떻게 표현했다고 적혀있으니 이런 것만 잘 숙지하면 이 책을 읽는데 어려움을 느끼지 않을 것이다.

목차를 보면 규칙이 어떤 식으로 적혀있는지 알 수 있다.

가령 다음과 같은 것들이다.

규칙01. 최대한 단순하게, 그러나 너무 단순하지 않게

규칙02. 버그는 전염된다

규칙03. 좋은 이름은 최고의 문서다

규칙04. 일반화에는 세 가지 사례가 필요하다

규칙05. 첫 번째 최적화 교훈: 최적화하지 말라

...

생각보다 흥미로운 제목이 많다.

따로 노트에 적어놓고 새길 정도의 규칙들이다.

필요없는데도 미래에 할지도 몰라서 구현한 것이 많았던 나의 지난 과거를 회상하게 하였다.

언젠가 필요할지 모르니 파라미터를 좀 더 유연하게 해야한다거나, 이름을 좀 더 일반적인 이름으로 만들자는 것 등 많은 것들이 현재 필요한 것을 넘어서서 구현하고 있었다.

하지만 여기에서는 분명히 이야기 한다. '필요하지 않으면 구현하지 말라'

XP의 YAGNI(You Ain't Gonna Need It)가 생각났다.

사실 미래의 조건은 미래에만 알 수 있기 때문에 현재는 확정적으로 알 수가 없다.

그래서 불필요한 고민을 야기시킨다.

코드를 개발하다보면 이것을 점진적으로 변화시켜나갈 것인가. 아니면 새롭게 갈아엎고 개발을 할 것인가 하는 고민이 오는 순간이 있다.

그것에 대한 결정의 기준을 '두 배 좋은가'라고 간단히 물어보고 있다.

그렇게 확실하지 않다면 해당 이슈는 점진적으로 처리하는 것이 좋다.

일단 새롭게 재작업을 한다면 큰 비용을 치루는 것은 자명한 일이다.

하지만, 그만큼 새롭게 정의된 모든 스펙을 만족할만 한 개발이 시작될 것이기에 이에 대한 장점도 가져올 수 있다.

이런 갈림길에 있을 때 자신만의 원칙을 세워야 한다면 이렇게 세우는 것은 매우 합리적인 판단을 하는 데 도움을 줄 수 있을 것이다.

이 책에서 소개한 규칙은 '고스트 오브 쓰시마'를 개발한 서커펀치 프로덕션의 경험을 가져와서 한 것이 많다.

그런데 우리가 처한 상황은 각자 다를 수 있다.

그래서 서두에 언급한 내용이지만, 결국 나에게 해당하는 규칙은 각자마다 어느정도 차이가 있을 수 있다.

그래서 나만의 규칙을 만드는 것이 중요하다.

이 책이 교과서가 아닌 참고서 정도가 된다는 것을 명심하자.

이 책의 예제는 어떤이에게는 매우 아쉽게도 C++을 기반으로 작성되어 있다.

물론 요즘시대에 개발 언어가 무엇이 그리 중요하겠냐마는 어느정도 중요하기는 하다.

보통 개발 10년차 이상이 된다면, 자신의 주력언어를 모국어처럼 다룬다고 생각한다.

반면에 그 주력언어를 제외한 다른 언어는 외국어와 같이 보일 수 있다.

숙련도에 따라 영어 혹은 일본어 등과 같이 보인다는 것이다.

모르지는 않겠지만, 그다지 와 닿지 않거나, 와 닿도록 해석하는데 노력이 든다는 것이다.

그래서 그것을 도와주기 위한 부록이 들어있는 것이 그나마 다행이라는 생각을 했다.

사실 서커펀치 프로덕션은 사람들에게 잘 알려져있는지는 잘 모르겠다.(게임에 관심이 있는 사람은 알 것이겠지만)

오히려 고스트오브쓰시마는 잘 알려져 있어서 나조차도 게임 이름을 통해서 이 프로덕션을 알게 되었다.

그래서 이곳에서 체득한 경험이라면 다른 일반 개발자들에게 도움이 될만하겠다는 생각을 하게 한다.

> 괜찮은 부분

1. 괜찮은 주제이다.

프로그래밍의 규칙이라니, 얼마나 설레는 제목인가 싶다. 내가 열심히 하려고 노력하고, 잘 하기 위해 애쓰는 그 분야에도 규칙이 있다니, 그것을 빨리 익힐 수 있기를 누구든 원할 것이다. 물론 누구나 본인도 모르게 이런 규칙을 다 갖고는 있겠지만, 이러한 참고서와 같은 책을 통해서 확인받고 싶어할 것이다. 그런 관점에서 이 책은 괜찮은 주제를 가지고 나왔다고 생각한다. 또한 깔끔히 정리해서 21가지를 내어놓았으니 숫자로 정해놓고 정리하고 싶은 개발자의 특성상 더 와 닿을 제목과 주제를 가지고 왔다고 생각한다.

2. 설득해 가는 과정이 인간적이다.

이 책에서는 시작부분부터 서로의 생각이 있음을 인정한다. 그래서 이 규칙을 곧이곧대로 받아들이지 않았으면 좋겠다고 말까지 한다. 독자를 생각하게 하고, 그것에 대해 반론을 제기할 필요가 있다고도 말한다. 그러면서도 무엇인가를 받아들여야만 한다면 그 과정에서 필요한 방법도 제시한다. 이런 내용이 꽤 인간적으로 보였다. 책은 사람을 잘 설득하는 데 목적이 있으며, 사람이 설득되는 데에는 수려한 문구와 잘 정돈된 형식들도 중요하지만, 무엇보다도 마음을 흔드는 부분이 중요하다. 마음을 흔드는 과정에서는 공감과 대안제시가 중요한데, 그런 것들을 처음부터 인정하고 시작한 책이라는 사실이다.

3. 유명 개발사 프로덕션의 사례로 온 내용이다.

콘솔 게임에 조금이라도 관심이 있다면, 실제 플레이 여부와는 관계없이 '고스트 오브 쓰시마'라는 게임을 알 것이다. 이 게임은 소니의 퍼스트파티 게임으로서 작품성과 게임성 자체가 검증된 게임이다. 이런 게임을 만드는 과정에서 작성한 코드가 어떤 규칙에 의해 개발되었는지 안다고 하면 꽤 도움이 된다. 보기 쉽지 않은 레퍼런스이기 때문이다. 사실 사람들이 어느 직장에 들어가는 것은 그 회사만의 문화와 규칙을 배우기 위함이라는 것도 무시할 수 없다. 그런 관점에서 이 책은 이런 니즈를 충족시켜준다.

> 아쉬운 부분

1. 책의 표지는 매우 아쉽다.

작은 부분이라고 생각할 수 있지만, 이 책을 약 한달이 안되는 기간동안 가지고 다니면서 읽었는데, 이 책의 상태가 그리 깔끔하지 않다는 것을 발견했다. 표지 부분이 말아올라가는 현상이 매우 쉽게 발생했다. 옛날에 나온 책이라면 그러려니 하겠지만 2024년에 나온 책. 그것도 잠시 잠깐 읽을만한 책도 아니고 오래두고 읽을만한 책이 이렇게 관리가 어려운 스타일로 되어있다면 이것은 매우 아쉬운 선택이라는 생각이 든다.

2. 채택된 언어가 C++인 것은 아쉽다.

사실 이것은 게임을 주제로 다루었기 때문에(언리얼 등 게임엔진에서는 C++을 사용) 어쩔 수 없는 부분이라는 생각도 들고, 이것을 파이썬 독자를 위해 코드 읽는 방법을 부록으로 수록했을 정도로 아쉬움을 달랬기 때문에 어느정도는 해소가 되었다고 생각이 든다. 하지만, 그래도 여전히 남아있는 사실은 C++이라는 사실이다. 사실 이것은 개인차가 있기 때문에 C++이라서 마음에 든 사람도 있었을 것이라고 생각이 든다. 하지만 자바나 C, 파이썬 등으로 나왔다면 좀 더 일반적으로 쉬운 관점에서 널리 읽히기 좋은 책이 되지 않았을까 하는 아쉬움도 든다. 이런 유사한 내용으로 다른 언어와 함께 수록된 책이 나왔으면 하는 생각이 들기는 했다.

> 추천 독자

코드를 잘 작성하고 싶은 일반 개발자

> 개인적인 평점

- 가격: 7 / 10

- 내용: 9 / 10

- 디자인: 7 / 10

- 구성: 8 / 10

> 정보

저자: 크리스 짐머만

옮긴이: 박상현

출판사: 한빛미디어(오라일리)

가격: 32,000원

전체 페이지: 460페이지

** 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

jhl2***l2024-06-23

프로그래밍의 규칙-더 나은 코드를 작성하는 21가지 개발 비법 책 리뷰

안녕하세요!

프로그래밍에서 규칙을 공부하고 싶거나

더 좋은 코드를 작성하고 싶은 분들께 추천드리는 책

"프로그래밍의 규칙-더 나은 코드를 작성하는 21가지 개발 비법"을

리뷰하려고 합니다.

도서명: 프로그래밍의 규칙-더 나은 코드를 작성하는 21가지 개발 비법

설명: 독자가 더 나은 코드를 작성하는데 도움이 되는 규칙의 모음집

지은이: 크리스 짐머만 지음

옮긴이: 박상현 옮김

정가: 32,000원

이 책의 가장 큰 장점은 바로 휴대하기 편하다는 점입니다.

460P 분량의 책이지만 매우 가볍기 때문에 짜투리 시간에

읽기 정말로 좋습니다.

프로그래밍이라는 어려운 분야에서

해당 도서는 프로그래밍을 해본 적 있는 사람이라면

누구나 공감할 만한 상황들을 이야기합니다.

책을 수월하게 읽을 수 있던 건 겪어본 적 있고 충분히 공감가는

상황을 이야기해주고, 내용을 읽고 싶게 만드는 제목 때문이지 않을까 생각합니다.

이렇게 내용이 구성되어 있어서 읽기 편했어요!

코드를 작성할 때 불필요한 코드는 없애고 최소화하라는 말을

들어본 적 있으신가요?

저는 그 말을 들을 때면 최소화를 하라는데 압박감을 느끼곤 했답니다 ㅎㅎ

하지만 1장을 읽으면서 '너무 단순하지 않게'라는 의미를 파악할 수 있었어요.

규칙01. 최대한 단순하게, 그러나 너무 단순하지 않게

이 도서에서는 프로그래밍의 규칙 중 코드 리뷰에 대해서도 다루고 있습니다.

규칙 06. 코드 리뷰의 세 가지 장점
✔코드 리뷰는 지식 공유다
✔금지된 코드 리뷰
✔코드 리뷰의 진정한 가치
✔코드 리뷰는 본질적으로 사회적 활동이다

코드 리뷰는 더 좋은 코드를 구현하기 위해, 코딩을 공부하기 위해서도

필요한 활동이기 때문에 틈틈이 하고 있지만

금지된 코드 리뷰에 대해서는 처음 접하게 되었습니다.

개인적으로 2번째 내용에서 흥미롭게 읽었어요.

도서 내용 속에는 프로그래밍 코드가 꽤 많이 존재합니다.

코드 구현 시 단순화하는 방법, 새로운 함수를 추가하는 등

다양한 상황에서 코드를 작성하는 과정을 보여주고 있습니다.

프로그래밍 입문자분들은 코딩을 꽤 하신 후 읽으면 좋고,

개발직에 근무하시는 분들은 더 나은 코드를 작성하고 싶거나

프로그래밍의 규칙을 공부해보고 싶다면

'프로그래밍의 규칙-더 나은 코드를 작성하는 21가지 개발 비법'를

추천드립니다!

이상으로 프로그래밍의 규칙 도서 리뷰를 마칩니다.

모두 즐거운 프로그래밍 공부하시길 바랍니다!

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

dlstj***l2024-06-23

[서평] 프로그래밍의 규칙

한빛미디어에서 출간된 <프로그래밍의 규칙>은 PS4, PS5에서 최근 스팀으로 이식되어 큰 사랑을 받고 있는 '고스트 오브 쓰시마'의 개발사인 서커펀치 프로덕션의 공동 설립자인 크리스 짐머만이 회사 내에서 사용되고 있는 프로그래밍 규칙을 공유한 책입니다. 개인적으로 게임 개발자분들이 하시는 일에 경외감(?)을 느끼곤 하는데, 이 책을 통해서 수 많은 개발자가 하나의 게임을 만들기 위해 어떤 방식으로 협업하는지를 엿볼 수 있어서 좋았습니다.

규칙 05. "최적화하지 말라", 규칙 08. "실행되지 않는 코드는 작동하지 않는다"와 읽으면서 과거를 반성할 수 있었던 내용도 좋았지만, 사실 이 책에서 가장 좋았던 부분은 서문에 있었습니다.

우리에게 옳은 규칙이 다른 사람들에게는 그를 수도 있습니다. ... 다시 말해 서커펀치와 여러분의 조직이 어떤 면에서 다른지를 알아야 합니다. 바로 그 차이가 해당 규칙이 서커펀치에서는 잘 작동하지만 여러분의 조직에서는 잘 작동하지 않는 원인이기 때문입니다.

서문 덕분에 최근 우리 곁은 멤돌았던 '클린 코드', 'MSA'와 같은 주제들에 대해 다시 한 번 고민해보고, '지금' 우리가 좋은 제품/서비스를 만들고, 덜 힘들고 재미있게 일하려면 어떤 요소들이 필요할지 생각해보는 시간을 가질 수 있었습니다.

이 책이 가진 단 하나의 옥의 티는 모든 예제가 C++로 작성되었다는 점입니다. 게임 업계에서 가장 많이 사용되는 언어가 C++이고, C++을 사용해보지 않은 사람들을 위해 부록에 파이썬과 자바스크립트를 이용해본 사람들을 기준으로 C++ 코드를 읽는 방법에 대해 소개하는 친절함이 있긴 합니다. 하지만 그럼에도 불구하고 예제가 다른 언어로도 제공되었다면, 게임 업계의 노하우를 다른 사람들이 조금 더 잘 이해할 수 있었을 것이라는 아쉬움이 남아있습니다.

어떤 방식으로 코드를 작성하는 것이 더 좋은 방법일까 고민하는 모든 분들에게 이 책을 강력 추천합니다.

- 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다. -

doupler0***l2024-06-23

프로그래밍의 규칙 - 언어를 벗어난 효율적 규칙들

이 책은 처음부터 읽기 부담스럽다면 서문에서 권유한 것처럼, 목차에서 흥미를 끄는 규칙을 찾아 읽어나가는 방법도 괜찮다. 총 21개의 규칙을 예시 코드와 함께 설명하고 있다.

가장 첫 규칙인 ‘최대한 단순하게, 그러나 너무 단순하지 않게’에서는 단순성의 중요성을 강조하며, 코드의 단순성을 측정하는 기준으로 동료가 코드를 쉽게 이해할 수 있는지를 제안한다. 실제로 실무에서 코드를 작성할 때 난 두 가지 기준을 두고 작성한다. 내가 내 코드를 타인에게 잘 설명할 수 있는가, 그리고 내 설명이 없더라도 내 코드를 내 동료가 보았을 때 이해할 수 있는가, 혹은 납득할 수 있는가. 물론 실천하는 일이 쉽지는 않지만 최대한 노력하고 있는데, 비슷한 맥락에서 단순하지만 직관적으로 코드를 작성하는 방법에 대해 설명하는 부분이 인상적이었다.

기본적으로 이 책은 C++을 기반으로 쓰여 있는데, 해당 언어를 모르더라도 이해 가능한 규칙들이 있다. 예컨대 ‘좋은 이름은 최고의 문서다’라는 말은 단순히 글자 수를 줄이는 것이 아니라, 좋은 이름을 통해서 생각하게 하지 말라는, 즉 직관적으로 받아들일 수 있게 작명하라는 의미였다. 추가로 모두가 변수에 동일한 규칙을 적용하면 동료의 코드를 자신의 코드처럼 느낄 수 있음을 언급하고 있는데, 컨벤션의 중요성을 다시금 생각할 수 있는 부분이었다.

코딩을 하다 보면 다양한 예외 케이스를 상상하게 되지만, 이건 안전한 습관이기도 하면서 반대로 스스로 빠지는 함정이기도 하다. 모든 케이스에 대해 일반화를 하기 시작하면 코드가 비대해지고 불필요한 사이드 이펙트를 경험하기도 했다. 그런 맥락에서 ‘필요하지 않으면 구현하지 말라’는 규칙은 섣부른 일반화를 통해 절대 실행되지 않을 코드를 작성할 가능성이 크다고 지적하며, 많은 예외 케이스를 산정하고 대응하는 건 물론 좋지만 결국 사용되지 않으면 무의미할 수 있음을 말하고 있다.

그 와중에 직관적으로 다가오는 규칙은 ‘잡초를 뽑으라’는 규칙이었다. 동물의 숲에서 잡초를 주기적으로 뽑아주지 않으면 마을이 잡초로 뒤덮이듯, 개발 또한 코드 베이스에서 생기는 작은 문제들, 즉 잡초를 뽑아줘야 한다는 이야기였다. 하지만 이것이 잡초인지 아닌지 식별해야 하는 선행 과제가 필요하다. 잡초를 뽑는 일은 쉬운 일이지만 동시에 그렇기 때문에 외면하기도 쉬워지기 마련인데, 그 또한 언급하며 꾸준히 관리해 줘야 함을 언급하고 있다.

이 책은 다양한 측면에서 실용적이고 직관적인 규칙들을 제시하고, 좀 더 효율적이고 이해하기 쉬운 코드를 작성할 수 있도록 돕는다. 각 규칙은 게임을 구현한 현실적인 코드와 함께 제시되어 있어 좀 더 와닿는 부분이 있다. 언젠가 C++이 지금보다 친숙해지면 한 번 더 읽어보고 싶은 마음이 든다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

alas0***l2024-06-23

자신의 코드 작성방법이 정체되어 있다는 생각이 드는 개발자라면

* 한빛미디어 서평단<나는리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

예전에는 작은 규모의 개발팀에서만 일해서 서로 코드가 겹칠일도 거의 없었고, 개발자가 좀 있더라도 각자 맡은 부분만 계속 작업해서 코드에 대한 협의를 따로 진행하지 않았다. 주로 내가 편한 스타일대로 만들었던 경우가 많았었는데, 이번 회사에서는 기존에 서비스 중인 프로젝트를 유지보수하면서 새로운 버전으로 리뉴얼하는 작업에 투입되기도 했고, 프로젝트를 바라보고있는 사람만해도 스무명 가까이 되다보니, 우리팀에서 거의 모든 업데이트 일정에 포함되어 있는 나 조차도(프론트엔드 개발자라 UI 들어가는 부분은 PC웹뷰, 모바일웹뷰 포함 모두 참여함) 모르는 새에 만들어진 것들이 정말 만다. 내가 입사하기 이전에 만들어진 코드들과 내가 만들었음에도 다른 분에 의해 기능이 추가되고 수정된 코드들이 있으면 그것들을 해석하는데만해도 많은 시간이 필요했던 것 같다.

이 책에서는 더 나은 코드를 작성하는 21가지 방법을 예시와 함께 설명해 준다. C++을 예시코드로 보여주고 있어서, 대학교 1학년때 배우고 거의 13년만에 보는 언어라 조금 두렵기도하고 반갑기도 했다. (C++이 너무 어려워서 개발자 안하겠다고 생각했던 19살의 나ㅎ)
책을 한번 싹 훑으면서 내가 나 편하자고 했던 것들이 이 책에서 제시하고 있던 방법 중 하나인것도 있었고, 내가 놓치고 있던 것들이라던가, 확장성을 위해 만들었던 것들이 사실은 더 효율을 떨어트리는 것들이 있어서 반성하는 계기도 되었다.

특히 가장 인상적이었던 파트는 "최적화하지 말라" 라는 부분이었다."우리는 같은 작업을 더 빠르게 수행하도록 바꾸는 것이 아니라 불필요한 작업을 제거함으로써 성능을 개선합니다. 불필요한 작업을 하는 코드 또는 한번만 해도 될 일을 여러번하는 코드를 찾아내세요. 이러한 코드를 제거하면 프로그램이 더 빠르게 동작됩니다." 라는 부분이 정말 머리를 띵하게 만들었다.
왜냐면 이 부분을 보고 있을 때쯤, 최적화를 한답시고 자바스크립트 파일 하나를 뜯어 고치고 있던 중이었는데, 정말 필요한 것은 필요없고 중복되는 것을 찾아 줄이는 것이 우선이라는 것을 깨달았다.

좋은 이름은 좋은 문서다 라는 부분도 인상적이었는데, 예전에는 함수의 이름이나 변수의 이름을 최대한 짧고 단순하게 만드는 경우가 많았다면, 최근에는 많은 사람들이 코드를 보고 있으니 누구나 처음보더라도 이 함수와 코드가 어떤 목적으로 만들어졌는지, 어떻게 사용해야 알 수 있는지 한번에 알수 있도록 표기하려 노력하는편인데, 아무래도 오랜 습관으로 모든 사람들이 그런 방식으로 작업을 하지 않아서 다른 분들의 코드를 볼때 조금 시간이 걸리는 것같다. 솔직히 함수의 이름이나, 변수의 이름을 길게 늘여쓰면서 혹시 성능에 문제가 있지 않을까? 걱정하면서도 다시 봤을때 나 편하자는 마음에 그렇게 작성했던 것들이 있었는데, 좋은 판단이었던 것 같아 다행이라는 생각이 들기도 했다.

이미지 캡션또한 산사태를 일으킨 조약돌을 찾으라 라는 부분도 보면서 꼭, 이번 업데이트가 끝난다면 코드리뷰를 하면서 같이 해결해야지 하는 생각을 했다.
책에서 다뤄진 예제 코드가 C++인데, C++을 모르더라도 이미 다른 언어를 충분히 경험한 사람이라면 어떤 이유로 이 예제코드를 보여주는지 이해하는데 어려움이 없었다. 그리고 뒷부분에 파이썬과 자바스크립트개발자를 위한 C++코드 읽는 방법도 알려주고 있기 때문에, C++을 사용해본적이 없는 사람들이라면 이 마지막 파트를 먼저 읽고 책을 읽는다면 이해가 잘 될것 같았다.

또 코드를 많이 다루는 실무자들 중에서도 5년차 이상의 개발자들이 자신의 코드 작성방법이 정체되어 있다고 느낀다면, 신입개발자들을 가르쳐야하는 경우가 생겼는데 자신의 코드를 돌아보니 이게 괜찮나? 싶은 생각이 드는 사람들이라면 이 책을 보고 좋은 해결점을 찾길 바란다.

guygi***l2024-06-22

프로그래밍의 규칙, 나는 어떤 규칙을 갖고 있을까?

“한빛미디어 < 나는리뷰어다 > 활동을 위해서 책을 제공받아 작성된 서평입니다.”

회사를 다니는데 하나의 프로젝트를 혼자서 계속 하는 경우는 드물지도 모른다. 보통은 하나의 프로젝트를 여럿이서 나눠 하면서 각자 맡은 부분을 작성하고 있을 거다. 당연히 GIT 같은 형상관리툴도 쓰고, GitHub 같은 걸 통해 코드리뷰도 진행할 것이다. 페어 프로그래밍을 하는 경우도 있을 것이고… 심지어 ChatGPT를 통해 작성된 코드를 참고해서, 아니면 수정해서 사용하는 경우도 있을 것이다.

그렇게 작업을 하다보면, 나의 코드와 남의 코드 사이에 발생하는 괴리감을 느낀다. 명시적인 코딩 컨벤션이 있다면 그 정도는 덜할 텐데, 암시적인 코딩 컨벤션이 존재하고, 그걸 철저히 준수하지 않아서, 이전 코드와 지금 코드 간의 괴리감도 많이 느낄 것이다. 또한 리뷰어의 성향에 따라 철저하게 코딩 컨벤션을 준수하라고 할 수도, 자신의 스타일을 은근슬쩍 강요할 수도, 이도 저도 아니고 알아서 하라고 할 수도 있을 거다.

누군가가 초기에 세팅해둔 툴 덕분에 코드 컨벤션 일부는 강요되므로 준수해나가는 경우도 있을 것이고, 남이야 어떻든 내 코드는 내 스타일대로, 남의 스타일은 맘에 안 들어서, 무시하고 계속 작성해 나갈 수도 있을 것이다. 남의 코드 수준이 자신보다 떨어지는 것 같아, 내 식대로 다 바꿔버리는 경우도 있다. 그러다가 다른 걸 작업하게 되어 작업하던 프로젝트를 다른 사람이 맡아서 또 바꾸고 하다보니, 어느 순간인가 코드 베이스에 여러 스타일이 넘쳐나서 당최 뭐가 어떻게 돌아가는지 알 수가 없는 경우도 생긴다.

이를 테면, 응답값에서 snake case를 쓰고 있었는데 난데없이 camel case를 쓰는 경우도 있었다. 덕분에 호출하는 쪽에서 일괄적으로 응답값을 관리할 수 없어 경우에 맞게 작성하느라 애를 먹기도 하는데, 또 이걸 이어 받아 작업하던 개발자가 이 사정을 제대로 파악하지 못해 수정했다가 버그가 발생하기도 했다.

여러 사람들과 협업하는 것은, 소통 문제도 문제지만, 결국 결과물이 나오는 것도 문제가 많아질 수밖에 없다. 이걸 해결하기 위한 게 표준이다.

가령 우리가 늘상 사용하는 화장실에서 수도꼭지가 표준을 따르지 않는다고 한다면 어떤 일이 생길까? 뭐 기본적인 사용을 할 때는 문제가 되는 줄도 모를 테지만, 어딘가 고장이 나서 고쳐야 하는 상황이 발생하면 문제가 복잡해진다. 맞는 부품을 구하는 것도, 교체하는 방법도, 표준에 벗어나기 때문에 훨씬 더 많은 비용을 지불해야만 한다.

프로그래밍도 마찬가지였다. 정말 상식적이라고 생각하는 부분은 표준을 따를지도 모르겠지만, 실제 작업하는 영역에 들어오면 이 표준이 있냐 없냐에 따라 결과물이 확연히 달라진다.

20년이 넘는 개발을 해오면서 저자가 말하는 실수를 사실 지금도 하고 있다. 안타까운 것은, 어쩌다보니 십수 년째 한 프로젝트를 혼자하는 경우가 너무 많았다는 거다. 그러다보니 이러한 점을 지키는 게 의외로 암묵적으로 진행하고 있었다. 그래서 팀원이 가끔 생길 때마다 이걸 조율하는 게 쉽지가 않았다. 사실 누구나 자신만의 스타일을 갖고 있다보니 자기가 편한대로 개발하고 싶어 했다. 그런 이유로 어느 순간 굉장히 기본적이 굉장히 명확한 부분은 어느 정도 서로 인정하는 표준을 따르게 되는데, 그게 보통은 해당 언어가 보편적으로 따르게 다소 강제하는 부분이라거나, 사용하는 lint 툴의 가이드라인대로 진행하는 거다. 이건 언어 측면의 표준 정도일 뿐이고.

좀더 고차원으로 올라가면, 경험칙만 있다. 몇 년 동안 나보다 고수 개발자들한테 귀동냥으로, 때로는 코드 리뷰를 받으며 깨지고, 또는 작업했던 코드가 버그를 유발해서 그에 대한 반성으로 등 다양한 방면에서 얻은 그 경험칙들이다. 이걸 문자로 남기는 건 제대로 하지 못했는데, 이 책에서 상당히 많이 볼 수 있었다. 아쉬운 점이라면 저자가 비디오 게임 개발자여서, 게다가 C++ 개발자여서, 알려주는 점과 예제 코드가 이해는 되지만, 완전히 와닿지 못하는 점이 있다는 아쉬움은 있다. 하지만 대체적으로는 내가 완전히 수긍하고 또 역으로 배워서 써먹을 점이 많은 부분이 있음을 부정할 순 없다.

제일 와닿는 규칙을 몇 개 나열해보면 아래와 같다.

규칙 01. 최대한 단순하게, 그러나 너무 단순하지 않게
규칙 02. 버그는 전염된다
규칙 03. 좋은 이름은 최고의 문서다
규칙 08. 실행되지 않는 코드는 작동하지 않는다
규칙 13. 산사태를 일으킨 조약돌을 찾으라
규칙 15. 잡초를 뽑으라

그외 규칙은 조금 이해가 되거나 잘 납득할 수 없는 규칙들이다. 틀렸다고 말하고 싶은 게 아니라, 어딘가 나한테는 맞지 않는다거나 공감할만한 경험을 해보지 않은 게 아닐까 싶다.

팀원이 있던 시절, 그 팀원에게 한 얘기가 규칙 01이다. 그 전에 나도 어렴풋이 알고 있었다가 코드 리뷰를 받으면서 리뷰어에게 들은 말이기도 하고, 실제 그렇다는 걸 코드로 증명까지 해봤기 때문에 가장 가치 있는 규칙이다.

내가 리뷰를 하는 날인데, 코드가 무척 장황하게 만들어 왔더랬다. 불필요한 코드도 잔뜩 들어 있고 결론에 이르는 과정이 꽤나 복잡하기도 했던 그런 코드였다. 그래서 간단하게 말한 내용이다.

“코드가 길면 무조건 버그가 있는 겁니다.”

그걸 저렇게 잘 풀어내면 규칙 01. 최대한 단순하게, 그러나 너무 단순하지 않게, 가 된다. 그러면 그 팀원은 어떻게 했을까? 다시 작업해서 딱 필요한 내용만 남기고 정리해 왔다. 결론은? 잘 동작했고, 오히려 단순하게 했기 때문에 코드 상으로만 봐서는 알 수 없는 오류를 잘 파악할 수 있어서 코드 보완이 수월했다. 외부 입력값이 문서나 경험을 벗어나는 값으로 전달 받아서 버그가 발생할 수밖에 없었던 상황이었기 때문이다.

규칙 02. 버그는 전염된다. 이거 부정할 수 있는 사람 있을까? 버그는 무조건 다른 버그를 유발한다. 사용자에게 잘못된 행동을 유발시키든, 화면 처리를 요상하게 하도록 잘못된 코드를 양산시키든, 해당 버그를 가진 코드를 호출해서 내가 잘못된 결론을 내고 엉뚱한 코드를 작성하든, 아무튼 한 번으로는 안 끝는다. 그 여파는 지속되어 최악의 경우 잘못된 데이터를 생성해 DB 데이터까지 요염시킨다. 그러면 그 오염된 데이터 때문에 데이터팀이든, CS팀이든 개발팀 내 다른 팀원이든 그들의 업무를 대폭 늘리게 된다. 그러니 버그는 전염이 맞다.

규칙 03. 좋은 이름은 최고의 문서다. 이걸 부정하는 개발자가 있을까? 일을 하다보면 다소 근시안적인 접근을 하는 개발자, 기획자가 은근 많다. 지금도 변수 이름 하나, 함수 이름 하나 정할 때마다 어려움을 겪곤 한다. 이름 한 번 잘못 정하면 두고두고 그 뜻을 이해하느라 애를 먹는다. 보통은 당장의 그 시점만 고려하는 경우가 많다. 하지만 한 번 쓰고 버릴 코드가 아니라면 이걸 사용하기 시작하는 시점과 이를 중간에 다시 쓰는 시점 등 다양한 시점을 고려해야 하는데, 상상력 부제인 건지, 당장의 문제만 해결하면 된다는 건지, 지금 당장만 통하는 경우만으로 이름을 정한다. 그러면 지금은 의미가 있을지 모르지만, 시간이 지나면 십중팔구 문제를 일으키기 쉽다. 이걸 이해하려면 경험이 쌓여야 하는 것 같다. 아니면 백날 얘기해도 이해하지 못할 게 뻔하니까.

규칙 08. 실행되지 않는 코드는 작동하지 않는다. 와… 이건 뭐 말해 뭐해, 느낌이다. 실행되지 않는 코드를 누가 건드리겠는가? 변화가 있을 때 관련 코드를 건드리고 테스트 하지 않는다면 이건 무조건 문제가 생긴다. 안 쓰는 코드는 버리는 게 맞다. 지금 안 쓰면 나중에도 안 쓸 확률이 매우 높다. 어쩌다가 다시 쓴다? 저자도 git에서 다시 되살리면 되지 않느냐 하는데, 내 경험으로는 그러는 경우는 사실 없다고 봐도 무관할 것 같다. 이걸 되살리는 경우는 지우지 말아야 하는데 지워서 원복하는 경우 말곤 솔직히 못봤다. 삭제됐던 코드가 정상 작동한다고 보장할 수도 없고, 어차피 되살려봐야 이해하고 고쳐야 할 점을 찾는 게 더 비용이 큰 것 같다. 그냥 현재 요구사항에 맞는 내용으로 재작성하는 게 더 빠르더라.

규칙 13. 산사태를 일으킨 조약돌을 찾으라. 지금도 옆에서 그런 모습을 많이 본다. 경력이 많은 이들은 정말 열심히 파고 들어서 증상을 직접적으로 일으키는 점 뿐만 아니라, 이를 유발한 조약돌까지 찾아 근본적인 해결을 하려고 든다. 그런데 대충 경력이 얕거나 경력이 많아도 그렇게까지 하기 귀찮은 사람들은 증상만 해결하고 끝낸다. 그러면 보통은 당장 해당 순간은 넘어가는데 머지 않아 더 큰 문제를 만나 더 큰 비용을 지불하고 해결해야 한다. 그 동안 고객은 회사에 실망하고 이탈하는 데 말이다. 조금만 더 신경쓰면 서로 윈윈했을 텐데 말이다.

규칙 15. 잡초를 뽑으라. 아… 저자는 예제로 주석문 얘기를 했지만, 내가 이 규칙을 읽었을 때 머릿속에 떠오는 건 바로 며칠 전에 회사 동료에게 했던 말이었다. 뭔가를 수정하고 빌드를 진행하고 있었는데, 그 동료가 컴파일이 오래 걸린다고, 레거시 시스템이라 그렇다는 말을 했다. 하지만 나는 그게 왜 그렇게 오래 걸리는 줄 알고 있다. 내가 담당하지 않아서, 당장 다 뒤집을 수 없어서 몇 번 언급만 했었던 것이지만, 역시 일이 커지고 하기 싫은 일이다보니 해결이 안 됐던 부분이었다. 바로 컴파일러가 내뱉는 경고 문구들 때문이었다. 2, 300여 개의 경고문을 출력하느라 컴파일 속도가 느린 것이다. 이걸 한 번 테스트 삼아 정리했고 10개 내외는 정말 없앨 방법이 없어서 남겨뒀었는데, 컴파일 속도가 확연히 달라졌었다. 그래서 이 점을 인지하고 알렸는데, 저자 말처럼 못질하고 싶지 않은 사람이 훨씬 많았던 터였다. 회사 초창기에는 팀장이 경고 무시하지 말고 무조건 해결하라고 했었는데, 지금은… 안타깝다.

공감되는 내용과 더 노력해야 할 내용들을 읽게 되어서 상당히 많은 도움이 되었다. 내가 완전히 공감하지 못하는 부분들에 대해서는 내 나름대로의 방향을 정리하는데 가이드라인으로 사용할 법하다. 내용을 차분히 읽어보면 이야기꾼 면모가 보이는 것 같다. 번역을 깔끔하게, 맛깔나게 잘 하셔서 더 그런 것 같다. 번역투도 아니고, 실제로 저자가 한 말을 잘 이해해서 우리말로 잘 옮겨놓았다. 그래서 품질이 좋다. 그러다보니 저자가 하고자 하는 내용도 잘 이해되는 효과도 있고.

예제 코드를 단발성으로 사용하지 않고, 점진적 개선을 통해 저자가 하고자 하는 내용들을 증명하며 전개해 나가서, 코드를 읽을 수 있는 개발자라면 확실히 도움이 될만한 팁이 많다. 개인적으로는 규칙 19. 평행 재작업 부분이 덜 이해가 되어서, 이 부분을 다시 보면서 파봐야한다. 왜냐하면 이 내용이 현재 내가 겪고 있는 어려움과 직접적으로 연관된 내용이기 때문이다. 낡은 코드, 문제가 되는 코드들을 개선해야 하는데, 건드릴 때마다 문제가 많이 생겨서 애를 많이 먹고 있기 때문이다. 이걸 잘 풀어보면 해결 실마리를 얻을 수 있지 않을까 기대해본다.

뭔가 본인의 개발 틀을 잡고 싶다면 이 책은 강추하고 싶다. 초심자가 이 책에서 얼마나 많은 걸 얻어갈 수 있을진 모르겠지만, 적어도 이런 점이 있다는 걸 인지하고 있으면, 앞으로 개발 업무를 해나갈 때 선임의 말이나 코드를 이해하는 데 많은 도움이 될 거라고 믿는다.

원래 조언처럼 말해주는 건 당시에는 이해하기 어려운 법이다. 내 생각이 너무 강해서 그렇다. 그래서 겪어봐야 아는 것이지만. 결국 이렇게 말할 테니까. “그때 그 말대로 했어야 했는데!”

hji7***l2024-06-22

규칙 다운 규칙

"규칙", "격언"을 말하는 건, 쉽고도 어려운 일인것 같습니다. 물론 충분히 규칙을 이야기하고 격언을 만들어 낼 만큼 많은 지식이나 경험을 가진 사람이라면, 모르겠지만, 대충 중2병에 걸려서, 얇은 종잇장 같은 지식으로 규칙을 만들어 낸거라면, 섣부르게 그 규칙을 사용했다가는 낭패를 만날 수도 있거든요. 그런데, 이 책의 제목이 "규칙"입니다. 모가 아니면 도일 가망성이 높다는 거죠.

그런데, 저자인 크리스 짐머만은 제게는 생소한 이름입니다. 지금까지 이분의 책을 읽어본 일이 없거든요. 게다가 책에 소개된 프로필도 너무 짧습니다. 게임 회사 공동 창업자라니... 그래서, 링크드인과 아마존에서 저자를 찾았습니다. 역시 짧습니다. 다만, 저자는 대학 졸업후 MS에 입사해서 일하다가 9년이 넘은 다음 퇴사해서 써커펀치라는 게임회사를 친구들과 만들었고, 이미 25년이 넘게 그 회사에서 일하고 있다는 것 뿐입니다. 저자의 프로필이 간단한건, 저자의 커리어가 너무 단순하기 때문인지도 모르겠습니다.

책을 읽기 시작하면서, 약간 신선함을 느낄 수 있었습니다. 예제 코드가 저자의 주장을 설명하는 설명 언어로 사용되었기 때문입니다. 그리고 다음 표현을 만납니다.

25년 전에 제가 서커펀치의 첫 코드를 작성한 이후로 코드베이스가 지속적으로 발전했습니다. 아직은 이러한 발전이 끝날 기미가 보이지 않습니다.
우리의 코드는 25년 전에 비해 훨씬 더 복잡해졌지만 우리는 복잡성을 잘 통제해왔고, 효과적인 진전을 이룰 능력이 여전히 있습니다.
본문 42쪽

요즘 저는 "소프트웨어 성장 이론"에 관심을 가지고 있습니다. 프레드릭 브룩스가 <맨먼스 미신> 20주년판에 "소프트웨어를 구축하지 말고 성장시키라"고 한 말을 가져온 것인데요. 브룩스는 소프트웨어를 작성하는 것을 빌드(구축)한다고 하는 메타포가 낡고 오래되었으며 바꿀때가 되었다고 말하며 소프트웨어는 성장시켜야 한다고 했습니다. 무려 38년전에요. 하지만 우리는 소프트웨어를 성장시킬 생각은 하지 않고 아직까지도 소프트웨어를 구축하고 있죠. 말도 그렇게 쓰고요. '빌드 해봐~~' 이렇게요.

소프트웨어를 성장 시켜야 하는 이유에 대해서도 브룩스는 언급했는데요. 그건 "성장"이라는 게 자연에 여러 동식물들을 은유하기 때문입니다. 생물들은 단순한것 처럼 보이지만 단순하지 않고, 차츰차츰 성장하는 가운데 매우 복잡한 구조를 가지면서도 안정적이고 다양하고 자기 보호적이고 스스로 갱신하기 까지 하거든요.

그런데, 마이크로 소프트의 경험만으로 창업을 한 저자가 그걸 25년간 해오고 있는 것입니다. 지속적으로 발전했고, 발전의 기미가 끝날 보이지 않는 코드베이스를 가지고 있다고 고백하고 있으니까요 게다가 앞으로 더 성장시킬수 있는 코드베이스라고 자신하고 있기까지 하거든요. 첫번째 규칙을 설명하는 장을 읽으면서 저자의 사상에 수긍하기 시작한셈이네요. 짐머만의 규칙은 도가 아니라 모에 해당하는게 맞은 것 같습니다.

그후 책을 읽어가면서 짐머만이 애자일에 영향을 받았다는 생각을 조금씩 하게 되었습니다. "필요하지 않으면 구현하지 말라"라는 YAGNI(You ain't gonna need it) 같은 철학을 언급하기도 하고 익스트림프로그래밍(XP)개발 방식의 창시자인 켄트 벡을 인용하기도 하거든요.

이 추론 과정은 정신적 저글링을 수반합니다.
181 쪽

추론 과정을 저글링에 비유하는 건, 켄트 백의 <테스트 주도 개발> 책에 첨부되어 있는 마틴 파울러의 이야기에서도 나오는 개념인데, 짐머만도 비슷한 방식으로 이야기를 전개하고 있고요.

특히 코드 리뷰와 Doxygen에대한 견해는 반가웠습니다. 켄트 백의 글들을 보면 코드 리뷰가 어떤 의미를 가져야하는지를 알수 있는데요. 일반적으로 우리는 코드 리뷰 과정에서 버그를 찾아 낼 수 있다고 기대하지만, 코드 리뷰의 의미는 '남이 내 코드를 보는 과정'보다 '남이 볼 코드를 내가 작성하거나 검토하는 과정'에 있거든요.

누군가가 보고 있다는 것을 안다면 모두가 더 좋은 코드를 작성한다.
133 쪽

짐머만의 견해도 정확히 같은 거죠. 또한 Doxygen에 대해서는 다음과 같이 이야기합니다.

신중하게 사용하면 Doxygen은 여전히 유용하지만 보통은 그렇지 않습니다.
345 쪽

특히 이 이야기를 전개하는 섹션의 제목이 "이야기에는 목적이 있어야 한다"입니다. Doxygen은 사실 주석으로서의 기능이 아닌 Doxygen에 입력할 목적으로 주석을 넣는 코드가 많아야 하는 툴입니다. '이야기'가 있지만 '목적'은 없는 셈이지요.

아참 헝가리안 표기법을 이야기 하는 부분은 정말 흥미로웠습니다. 헝가리안 표기법은 찰스 팻졸드가 <프로그래밍 윈도우즈>에서 언급해서 유명해진 방식인데요. C나 C++코드에서 변수 이름을 선언할 때 변수의 형(변수 타입)을 나타내는 접두사를 붙이는 방식입니다. 마이크로소프트의 전설적인 개발자 "찰스 시모니"가 변수명을 그렇게 썼었다고 하는데요. 찰스 시모니를 기리기 위해서 헝가리안 표기법이라고 부르는 것이죠. 그런데 헝가리안 표기법이 병폐가 있는 경우가 있습니다. 절대적인 룰로 집착하다 보니 헝가리안 표기법으로 만든 변수명이 외계어처럼 되어버렸던 것이죠.

그런데 여기서 반전이 있습니다. 사실 헝가리안 표기법은 C언어의 간단한 타입들을 대상으로 한 것이 아니라 C로 작성한 객체지향 성격의 프로그래밍에서 인스턴스의 변수 이름을 짓는데 사용하는 방식이었습니다. GUI 컴포넌트에 대한 접두사였던 셈이죠.

이 책에서 짐머만이 쓰고있다는 헝가리안 표기법은 객체 인스턴스들을 대상으로 하는 것이었습니다. 그래서 외계어 같지도 않았고요. 마이크로소프트 출신다운 면모이기도 하네요.

전반적으로 재미있는 책이었습니다. C++을 안정적으로 사용해서 25년이상 코드 베이스를 성장시킬 수 있었던, 공부많이 하는 현자의 깨달음을 들어보는 책이었다고 말할 수 있겠네요.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

jen3***l2024-06-21

나만의 프로그래밍 규칙 찾기

더 나은 코드를 작성하는 21가지 개발 비법에 대한 설명을 담은 책이다. 저자가 운영하는 서커펀치라는 곳에서의 경험을 바탕으로 21가지의 규칙을 설명하고 있는데? 사실 읽어 보면, 결론은 하나다. 결국에는 자신이 속한 회사와 자신이 처한 상황에 맞는 규칙을 만들고 코드를 작성하라는 것이다. 물론 포괄적으로 적용할 수 있는 규칙도 존재하긴 한다. 아마도 누구나 알고 있지만, 모두가 실천하기는 쉽지 않은 그런 규칙 말이다. 예를 들어 "단순하게 작성하라.", "다른 개발자가 봤을 때 알아볼 수 있게 작성하라." 등등 말이다. 알고는 있지만, 막상 시간에 급급해 작성을 하다 보면 단순한 것과는 거리가 멀어지기 마련이다. 그리하여 단순하게 표현할 수 있는 것도 복잡하게 표현이 되어 버린다. 그런데 그 복잡한 코드들은 어찌어찌 돌아가기는 한다. 이런 악순환이 반복되는 것과 멀어져야 하지만, 생각보다 쉽지 않다는 걸 우리는 알고 있다. 아니 나는 알고 있다. 아무튼 '규칙'을 통해 설명하는 이 책은, 내가 읽기에는 조금 어려웠다. 그 이유는 예시 코드들이 C++로 작성되어 있었기 때문이다. Java라면 그래도 이해했을 것 같은데, C++은 정말이지 이해하기 너무 어려웠다. 어떤 설명을 할 때 코드 위주로 하는 것도 꽤나 있다 보니, 그런 부분들은 사실 이해가기 어려워서 텍스트 위주로 읽었다. 개인적으로는 어려운 책은 다 읽기보다는, 자신에게 필요할 것 같은 부분을 발췌독 해서 읽기를 추천한다. 저자 또한 일단 규칙 1은 가장 먼저 읽기를 추천했지만, 이후로는 마음에 드는 규칙을 찾아서 읽으라고 했다. 내가 가장 재미있을 것 같다고 생각했던 부분은 코드 리뷰 부분이다. 실제로도 다른 부분들보다 잘 읽혔다. 코드를 작성할 때는 단순하지 않은 코드를 작성한 후에 실행만 되도록 작성하는 게 아니라, 항상 이러한 마음으로 작성하라는 것. '누군가가 보고 있다는 것을 안다면 모두가 더 좋은 코드를 작성한다.' 코드뿐만 아니라, 일을 하는 것에 있어서도 마찬가지가 아닐까 싶다. 아무튼 이 책은 C++을 알아야 조금 더 읽기 수월할 것 같다. 21가지 규칙이나 언급하지만, 그걸 곧이곧대로 받아들일 필요는 없다고 하니, 읽어본 후에 나에게 필요한 것을 발췌해 나만의 규칙을 만들어보는 기회로 삼으면 될 것 같다.

한빛미디어 서평단 <나는 리뷰어다> 활동을 위해서 책을 제공 받아 작성된 서평입니다.

jjkwa***l2024-06-21

망망대해에 나선 프로그래머들을 위한 등대 역할

프로그래밍의 규칙
더 나은 코드를 작성하는 21가지 개발 비법
크리스 짐머만 저/박상현 역
한빛미디어, 2024

이 책의 저자 크리스 짐머만은 세계적으로 유명한 서커펀치 프로덕션의 공동 설립자이자 스튜디오 책임자입니다. 서커펀치 프로덕션은 전 세계적으로 천만 장 가까이 판매된 메가 히트 게임인 고스트오브 쓰시마, 슬라이 쿠퍼 시리즈, 인퍼머스 시리즈 등 유명한 게임들을 제작했다고 합니다.

이 책에는 "더 나은 코드를 작성하는 21가지 비법"이라는 부제가 달려 있는데요, 크리스 짐머만이 서커펀치 프로덕션을 설립한 후 25년간 프로그래밍 팀을 이끌면서 사용한 규칙들이라고 합니다. 대규모 팀을 이끌어 오면서 습득하고 적용하여 다듬은 이 규칙들은 더 좋은 코드를 작성하는데 도움이 되어 노력의 소모를 줄이고 효율을 끌어 올리는데 큰 도움이 될 것 입니다.

- 주요 목차 -

최대한 단순하게, 그러나 너무 단순하지 않게
코드가 스스로 이야기하게 하라
복잡성을 격리하라
일반화에는 세 가지 사례가 필요하다
코드가 아닌 결과에서부터 작업하라

각 챕터가 각각의 규칙들이며, 각각의 규칙들은 독립적 입니다. 목차를 보면서 재미있을 것 같은 규칙을 발견하게 되면 바로 해당 페이지를 펼쳐 보면 됩니다. 이 책은 규칙별로 읽을 수 있도록 구성되어 있습니다.

혹시나 마음에 들지 않는 규칙이나 이해되지 않는 규칙이 있으면 해당 부분이 읽는 이의 약점일 수 있으므로 더 신경 써서 읽으면 좋습니다.

단, 규칙 1 - 최대한 단순하게, 그러나 너무 단순하지 않게는 반드시 가장 먼저 읽어야 한다고 조언 합니다. 다른 규칙을 익히기 위한 준비운동이 되기 때문입니다.

이 책은 곳곳에 이 책에서 제시한 규칙대로 눈으로 바로 확인할 수 있는 코드 개선 사항을 예시로 보여 주고 있는데요. C++ 로 작성되어 있습니다. 그렇다고, 너무 겁먹을 필요는 없습니다. C++ 로 작성된 코드 자체가 매우 단순화 되어 있어서 조금 눈에 익숙해지면 이해하는데 그렇게 어려움이 없습니다.

좀 더 심도있게 이해하고자 하는 파이썬 또는 자바스크립트 프로그래머라면 부록으로 추가되어 있는 파이썬 프로그래머를 위한 C++ 코드 읽기나 자바스크립트 프로그래머를 위한 C++ 코드 읽기 부분을 먼저 읽어 볼 것을 추천 합니다. C++ 코드를 소화하는데 도움이 될 것 입니다.

옮긴이도 곳곳에 추가 설명 주석으로 옮긴이의 의견과 책의 내용에 부연설명을 친절하게 달아 두어 읽는 이로 하여금 최대한 이해할 수 있도록 배려한 점도 훌륭합니다.

마치 자기계발서를 보는 듯한 내용전개도 보는 이로 하여금 편안함을 느끼게 합니다.

모든 프로그래머가 알아야 할 필수 지식과 개발 아이디어를 자극하는 인사이트가 가득 담겨 있으며, 코드를 작성할 때뿐만 아니라, 디버깅과 최적화 관련 지식도 함께 다루고 있어서 게임 분야 뿐만 아니라 모든 분야의 프로그래머에게 유용한 지식을 제공합니다.

많은 프로젝트들이 기획관점과 개발시 실제 접하게 되는 이슈가 판이하게 달라 개발을 진행하다 좌초하고 어쩔 수 없이 다 뒤엎은 후 새로 개발하거나 포기하게 되는 경험을 하기도 합니다. 유지, 보수가 용이하고 오래 지속되는 프로그램을 만들려면 동일한 상황에 대해 동일한 코드를 작성해야 하는데, 이는 많은 훈련을 필요로 하고 늘 지키는 원칙을 요구 합니다.

이 책은 프로그래밍이라는 항해를 나선 사람들을 위해 모범사례와 같은 21가지 규칙들을 소개함으로써 망망대해에 나선 프로그래머들을 위한 등대 역할을 제대로 하고 있습니다. 팀원들의 개성도 다 다르고 배움의 정도나 실력 수준도 다 다르기 때문에 무언가 나침반 역할을 해 줄 표지가 꼭 필요한 것이죠.

표지의 등대 그림이 정말 잘 어울리는 책이라고 생각합니다.

"한빛미디어 < 나는리뷰어다 > 활동을 위해서 책을 제공받아 작성된 서평입니다."

ted1***l2024-06-20

더 나은 코드를 작성하고 싶다면!

<프로그래밍의 규칙>은 작가의 말에서도 나와있듯 이러한 좌절과 실수를 줄이기 위해 등장했다. 책은 더 나은 코드를 작성할 수 있는 21가지 규칙을 담고 있으며, 이는 작가가 몸 담고 있는 게임 회사 서커펀치의 프로그래밍 규칙이기도 하다.

그 규칙을 알아보기 위해 책을 펴면 C++에 익숙하지 못한 사람들은 조금 주춤할 수 있다. 작가의 말에 나와있듯, 모든 예제는 C++로 이루어져있기 때문이다. 필자도 평소에 자바스크립트로 개발을 하는 편이라 배우지 않은 언어에 잠시 머뭇거렸는데, 다행히 부록으로 자바스크립트 프로그래머를 위한 C++ 코드 읽기 챕터가 들어가 있어 빠르게 훑고 넘어갈 수 있었다. 이외에도 파이썬 프로그래머를 위한 C++ 코드도 부록으로 있으니 파이썬을 주로 다루었던 분들이라면 해당 부록을 읽어보면 되겠다.

그렇게 부록으로 시작한 <프로그래밍의 규칙>은 독자가 다시 처음으로 돌아가 읽기 시작한 순간, 소소한 감동을 주었다. 책의 수익이 '코딩하는 소녀들' 단체에 기부 된다는 사실과 그 이유를 읽으며 '이 작가가 프로그래밍과 더 좋은 코딩환경에 대해 진심이구나.' 하는 신뢰를 얻어갈 수 있었다. 이 신뢰를 보답하듯 그가 제시한 규칙들은 꽤 타당하다.

특히, 개인적으로 여섯번째 규칙인 코드 리뷰에 대한 부분이 가장 와닿았다. 작가가 말하는 서커펀치의 코드 리뷰 과정은 이와 같다. 비공식적이지만 누군가가 리뷰를 요청하면 응한다. 리뷰어가 도구를 이용해 변경사항을 살펴보는 동안 리뷰이는 변경 사항을 설명한다. 리뷰어는 충분히 이해될 때까지 질문하고 수정을 제안한다. 리뷰이는 리뷰어의 제안을 모두 메모한다. 이 과정에서 작가는 코드 리뷰는 대화이며, 코드리뷰가 중요한 이유는 팀 내에 지식을 전파하는 탁월한 수단이라고 말한다. 단순한 행위가 아니라 '공유'의 측면에서 바라봤다는 점, 사회적인 측면까지 고려했을 때 더 중요할 수 밖에 없다는 점을 들며 규칙을 제안한 지점이 좋았다.

<프로그래밍의 규칙>에는 이 외에도 팀 내에 도움이 될만한 조언들이 많다. 최적화에 대해 신중해야 한다는 조언도 와 닿았는데 그만 두기 직전까지 사이트 최적화에 대해 고민했던터라 괜히 찔렸다. 개인적으로 느낀 것만 이정도이니, 독자들 각자의 개발 경험을 베이스로 어떤 규칙을 적용해볼지 고민하며 읽어볼만하다. 프로그래밍에 있어서 좀 더 실수와 좌절을 규칙을 알고 싶다면 이 책을 읽어보길 추천한다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."