|
1. 질문의 힘
＜KODE VICIOUS 개발 지옥＞은 개발자를 위한 문답 책이다.
2. 클린 코더
특히 다음 문장이 마음에 들었다.
현업에서 일을 하다 보면 히스토리가 중요하다는 이야기를 많이 듣는다. 하지만 고객의 입장에서는 지금 현재의 프로그램이 어떻게 동작하는지가 가장 중요하다. 그 옛날 스타크레프트에서 프로토스, 테란, 저그의 적절한 벨런스를 위해 다양한 패치가 있었다. 과거는 과거이니 더 이상 안 쓰는 소스를 주석 처리하여 클린하지 않게 관리하지 않겠다고 생각했다.
3. 멘토 트렌드는 계속 변화하고 공부할 것은 많다. 그럼에도 개발자를 놓을 수 없는 이유는 성취감 때문이다.
훌륭한 멘토 KV를 만나서 즐겁다. 이 리뷰는 출판사로부터 도서를 제공받아 작성하였습니다. https://blog.naver.com/kyoyo21/222968100033 |
|
네이버 블로그 링크: https://blog.naver.com/rock1192/222877401352
이 책은 저자가 무려 15년 동안 잡지에 기고한 컬럼을 엮어서 만든 책 이다 꽤나 재미있는 5개의 챕터 87개의 컬럼으로 구성 되어있다
저자는 프로그래머라면 개발을 하면서 한번씩 고민해봤거나 겪어봤던 상황들을 각 주제마다 재미있고 뛰어난 문장력으로 분노하는 케릭터를 연기하며 흥미롭게 풀어내고 있다 책을 읽으면서 저자의 지혜를 옅볼 수 있으며 이러한 사고를 넓혀주는 책을 프로그래머들이 반드시 읽어보면 좋을 것 같다 독자 대상
도서 특징
예전에는 비행기, 기차 및 자동차용 시스템을 구축하는 임베디드 컴퓨팅 분야에서 일하는 소수의 전문가들만 작은 메모리를 들여다봐야 했다 비록 IoT로 칭해지는 대상들에게 RAM과 관련된 사항들은 옛날의 임베디드 시스템들과 밀접하지만, 그 외의 나머지는 사촌 격인 데이터 센터에 위치한 서버들에게 맡긴다 이 서버들의 메모리는 MB 단위에서 몇 GB 정도로 어림잡을 수 있다 값싼 컴퓨팅 장치가 계속 확산됨에 따라 새로운 세대의 코더들은 다시 메모리라는 귀중한 자원을 인식하고 효율적으로 작업하는 방법을 반드시 배워야 한다
떄론 소프트웨어의 한 조각에서의 문제가 코드 속 어떤 라인에 있는 게 아니라 이것들이 어떻게 배치되고 쓰이는지에 있는 경우가 있다 소프트웨어를 개발한다는 것은 단순히 수천 줄의 코드를 순차적으로 작성한다기보다는 그것들을 조합하는 행위에 가깝다 제대로 작성된 소프트웨어는 다른 이들이 사용하기 쉽도록 안배되어 있는데, 만약 그걸 원치 않는다면 모든 프로그램을 단 하나의 함수만 가진 파일 하나로 해서 10,000줄 이상의 코드로 작성하면 된다 우리는 이것을 '불합리해 보이는 정원사의 비유'를 통해 볼 것이다
코드 재사용은 경우에 따라 칭찬 받기도 하지만 남용이 되기도 하고, 조롱 당하거나 어떤 때에는 적절한 조치가 되기도 한다 코더의 매크로일 수도 있고 다른 코더의 라이브러리일 수도 있다 아니면 전혀 말이 안될 수도 있다 소프트웨어에게 주어진 유연성을 감안했을 때, 우리가 적용하려는 목적에 맞지 않는 코드 조각을 재사용하고 싶은 충동이 들 때가 종종 있다 하지만 그것은 코드 남용이다 재사용이 아니라
머릿속에서는 그럴싸하게 느껴지지만, 막상 글로 적어 보면 그다지 좋아 보이지 않는 경우가 있다 이 둘의 차이를 일찍 깨닫는 것이 코딩 커리어에 있어 중요한 사항이다 물론 우리 모두는 자신의 작업이나 다른 이의 작업을 들여다보면서 늘 좌절을 겪고 있다 그 와중에 저마다의 다채로운 표현들을 허용하고 싶어하지만, 이런 코드를 버전 컨트롤 시스템에 영구 보관하는 것은 벽에 대고 소리치는 것만 못하다 소프트웨어 개발이라는 것은 결국 많은사람들에게 이러한 코딩 부산물들을 제공하는 것이므로 코딩도 은밀한 소수의 전유물이 아니라 공개적인 행위로 취급되도록 해야만 한다 따라서 우리는 코드, 주석 및 다른 어디라도 무엇에 대해 말하고자 하는지와 전하는 방법에 대해 신중하게 고려해야 한다
코더들이 자신의 시스템에 대한 문서를 남기는 것을 싫어한다는 것은 오랫동안 내려져 온 믿음이다 '글로 쓰기 어렵다면, 이해하기도 어렵다'라는 말처럼 사실은 문서화되지 않은 대량의 코드를 살펴본 경험이 있는 사람들은 누구나 좋은 문서의 가치를 알고 있다 사람들이 자신의 코드나 디자인을 문서화하는 데 어려움을 느끼는 이유는 좋은 글귀나 소설과 수필, 함수 블록, 하드웨어 기능에까지 내러티브가 필수라는 사실을 받아들이지 못했기 때문이다 내러티브 없이는 독자들에게 아무런 정보도 제공 못하고 그저 글귀를 흩뿌리는 것에 불과하다 아이러니인 점은 소프트웨어에서 흔히말하는 함수는 내러티브와는 거리가 멀다는 것이다 함수는 주로 어떤 입력값을 받아 출력값으로 변환하는 역할만 한다 좋은 내러티브는 초현실주의 소설과 다르게 독자를 무지의 장소가 아니라 꺠달음의 장소로 안내한다 여러분들이 하나의 함수에 대해서 문서화를 시도할 때 다음 네 가지 질문에 답변을 하면 좋은 문서화가 될 것이다
적절한 추상화는 좋은 시스템 디자인의 핵심이다 왜냐하면 추상화가 잘못되면 복합성이 저하될 가능성이 매우 높기 때문이다 그렇게 되면 전체 시스템이 유기적으로 동작하지 않고, 설령 작동할지라도 결점이 있을 것이며 서로 자연스럽게 맞물리지 않을 것이다 추상화를 올바르게 하지 않으면 두 컴포넌트 사이에 오해가 생기게 된다 그리고 오해하는 버그를 유발하고, 버그는 시스템 실패를 유발한다 추상화가 제대로 고려되지 않아 시스템이 실패하면 구성 요소를 구현해야 했던 코더가 아니라 디자이너가 책임을 지게 된다
사람들은 코더 중 대다수가 낙관주의자들이란 사실을 믿지 않는다 여기서 보안과 관련된 일을 하는 사람들을 제외하고 말한거고, 대다수 코더, 즉 열에 아홉은 낙관론자이다 우리가 하는 일을 보면 이게 무슨 말인지 알 수 있을 것이다 시스템이 크거나 난해한 코드가 동작하게 하는 건 환장할 정도로 성가시고 어려운 일이기 때문에 코드가 빌드되면 대부분의 코더는 그것이 동작될 거라고 확신하곤 한다 이런 낙관주의의 단점은 이 책에서 다양한 표현으로 언급되고 있는데 그중 가장 빈번한 건 코드를 커밋하기 전 테스트 부족이다 소프트웨어 개발은 90퍼센트 또는 그 이상의 공통된 노력의 대상이기 때문에 코드를 커밋하기 전에 테스트하지 않는 것은 소프트웨어 개발의 주요 죄악 중 하나이다 코더들에게서 보이는 이러한 지속적인 경향에 대해 가장 실망스러운 점은 이제는 컴퓨터가 엄청 빨라져서 가장 큰 시스템을 실행하는 데에도 몇 분이면 충분한데도 그러지 않는다는 점이다 오늘날엔 빌드를 위한 인프라는 대기업의 일터에서만 사용할 수 있는 것이 아니라 가장 작은 오픈소스 프로젝트에서도 사용할 수 있다 실제로 많은 시스템의 빌드 및 테스트 인프라는 노트북에서도 수행 가능하다
이 책은 저자가 15년동안 잡지사에 기고한 분노를 유발시키는 프로그래머들이 저지르는 실수들에 대한 컬럼을 엮어 놓은 책이다 자신이 분노를 유발시키는 프로그래머 유형에 속하는 프로그래머가 아닌지 깨닫게 해주는 흥미로운 주제들이 가득하다 목차에서 총 87개의 컬럼 주제를 보고 흥미로운 부분들을 펼쳐서 읽어보는 식으로 책을 읽어 보아도 좋다 책을 읽어 가다보면 내가 이런 실수를 하고 있지는 않는지 또 이런 것들은 어떻게 풀어나가면 좋을 지에 대한 지혜를 얻을 수 있다 많은 프로그래머들이 간과하고 넘어가서 다른 프로그래머들의 분노를 유발시키는 코드와 시스템을 양산하고 있다 동료 머리를 쥐어 뜯게 만드는 개발자들이 이 책을 꼭 읽고 분노를 유발시키지 않는 개발자가 되는 법은 어떤 것인지 깨닫고 좋은 개발자가 되기를 간절히 바라는 책의 재목이 매우 인상 깊다
|
|
1. 손 안의 코드 : 코드를 손 안에서 쥐락펴락하기 위해서 반드시 고려해야 할 스타일과 코딩의 핵심(정확성, 간결성, 조합성)에 대해 다룹니다.
문서의 중요성 시스템 디자인
안전한 로그 남기기 |
