한빛출판네트워크

책은 얇은 편이다.

책의 내용이나 구성도 어려운 편은 아니어서

재미있게 읽어내려간거 같다.



책의 내용은

읽기 좋은 코드 즉,

가독성이 좋은 코드를 작성하기 위한 방법에 대해서 다루고 있지만

그러한 가독성을 위한 과정에서

여러 다른 개념도 복합적으로 다루고 있다.



지금까지 프로젝트를 하면서

다른 사람이 봤을때 읽기 쉬운 코드라기 보단

내가 프로그램 개발에 있어 내가 일정이나 관리를 보다 쉽게 하기 위해

쓰던 그런 방법들이

많이 나와 있어서 재미있었던거 같다.



현재는 프로젝트를 할때

모든 용어를 메타로 관리하기에

필드 하나하나도 메타에 있는 용어로 쓰도록 제한하는 경우가 많다.



사실 이러한 부분도 좋은 점도 있지만 현실적으로 힘든점도 있다.



그러한 부분을 떠나서

좋은코드 에 대해 보다 실제적으로 다루고 있어

좋았던거 같다.



이러한 가독성이 좋은 코드 방식에 대한

책이 요새 0여러권 나오는거 같은데

시간이 되면 한번 읽어봐야 겠다.

소프트웨어 개발자에게 있어서 소프트웨어가 폐기되는 것보다 더 무서운 것은 무엇일까? 개인적인 생각은 소프트웨어 유지보수가 소프트웨어 폐기보다 더 무서운 일이 아닐까 생각해본다.



지난 시간에 열심히 코드를 만들어서 기껏 동작하게 해놨더니 오류 투성이에 동작도 제대로 안한다. 밤을 새든, 주말 출근을 하든 코드가 동작하게 해도 더욱이나 중요한 것은 내가 다시 그 코드를 볼 때다.



하루도 아니고 조금이라도 시간이 흐른 다음 본 코드는 광역시 쓰레기 매립장과 그 모습이 흡사하다.



비단, 내가 만든 코드가 아니라 할지라도 그건 변함 없는 사실이다.



그러면 소프트웨어는 어떻게 해야 잘 개발할 수 있을까? 아니 그 보단 어떻게 해야 만들기도 쉽고 유지보수도 쉽게 하게 할 수 있을까?



"읽기 좋은 코드가 좋은 코드다"의 저자인 더스틴 보즈웰과 트레버 파우커는 자신들이 경험한 나쁜 코드와 좋은 코드를 어떻게 구분하는지 그 해결책은 무엇인지 찾아본다.



이 코드를 누가 볼꺼야?



소프트웨어는 개발하는 사람과 유지보수 하는 사람이 작은 회사의 경우에는 같다. 하지만 회사의 규모가 커지고 개발하는 인력이 많아지면 자연스럽게 개발 인력과 유지보수 인력이 나뉘어진다.



물론 이런 구조가 조직 운영의 측면에선 훌륭한 운용 방법이겠으나 소프트웨어 개발에 있어서도 정말 행복한 운용 방법일까?



사람에 따라서 이 질문에 대한 대답은 다를 수 밖에 없을 것 같으니 쓸데없이 진 빼지 말고 코드를 누가 볼것인지 생각해봐야 한다.



내가 생각하는 대답은 이렇다.



자신이 소프트웨어 개발자라면 자신이 만든 코드는  자신이 볼 가능성이 70% 이상이다.



근데 내가 만드는 코드를 내 맘대로 만들면 되지. 왜 읽기 편하게 만들어야 하느냐고 묻는다면 코드는 온전히 본인의 것이기 때문이다.



코드는 미학이다!



코드를 읽기 좋게 만든다면서 자신만 알아볼 수 있는(심지어 자신도 잊어먹는) 코드를 만들어놓고 와! 이건 완전 예술이야! 라고 자신이 감탄하는 코드를 만들어 놓고 나 잘났다~



독자는 이런 종류의 행동을 하면 안된다! 물론 읽기 좋은 코드는 보기에 아름다워야 하니 미학적인 모습을 가지고 있어야 하기는 하지만 그렇다고 해서 무슨 미술관의 추상화 그림처럼 코드를 만들라는건 아니다.



읽기 좋은 코드는 명확한 이름들을 가지면서 코드 정렬을 맞추고 의미있는 순서로 재배치하며 명확한 주석을 기록해야 한다. 그러면서도 소프트웨어 개발에 정해져있는 코딩 규칙이 있으면 그를 따라줘야 한다.



잘 동작하는 코드 vs 명확한 코드



나도 코드를 만들다 보면 명확한 코드보단 그저 잘 동작하는 코드에 집중하게 된다. 그런데 잘 동작하는 코드가 항상 명확한 것은 아니다. 오히려 명확한 코드가 잘 동작하는 코드인 경우가 많다.



잘 동작하는 코드에서 명확한 코드로의 변경은 코드의 제어흐름의 조정과 거대한 표현은 잘개 쪼갠다. 그리고 무엇보다 변수는 말 그대로 자주 변할 수 있으니 그 사용범위가 제한되어야 한다.



이 코드 다른데서도 쓸 수 있을까?



리팩토링에서도 나올 수 있는 이 주제는 코드에 있어서도 프로그램에 완전히 종속하는 기능인지 다른 코드에서도 쓸 수 있는지 확인해보아야 한다. 



이와 같은 이유로 코드에서 분리될 필요가 있는 문제를 찾아서 코드를 분리하는 작업이 필요하다. 또한 작업은 한 번에 하나씩 하도록 코드를 만들어야 한다.



개발자들이 항상 하는 일 중 하나는 있는 라이브러리를 다시 생성한다거나 하는 일인데 우리가 만드는 프로그램은 항상 작은 코드 크기를 유지해야 한다. 그럼으로서 우리는 코드를 조금 더 쉽게 유지보수하고 명확한 문제 해결책을 가지게 된다.



코드만 읽기 쉬워선 안된다 - 선택된 주제들



많은 경우 우리는 소프트웨어 개발에 있어서 기능은 개발하지만 기능에 대한 면밀한 테스트는 잘 해보지 않는다. 그리고 하나의 잘 독립된 소프트웨어를 개발하는 경우도 별로 없다.



많은 경우의 소프트웨어 개발자들은 하나의 잘 설계된 소프트웨어 개발이 아닌 시간에 쫓기는 개발을 하기 때문인데, 이와 관련해서 저자는 한 가지의 해결방법을 제시했다.



테스트 케이스 작성을 통한 테스트를 해결책으로 제시했는데 많은 경우 소프트웨어 개발에서 테스트는 겉

읽기 좋은 코드가 좋은 코드다.(한빛미디어)

책 제목 그대로 코딩을 어떻게 해야 하는지를 설명하는 책이다. 누구나가 프로그램 코드를 봤을 때, 우선 읽기 편하고 실행이나 디버깅이 없이 프로그램의 작은 파트 또는 전체 프로그램의 흐름을 눈으로만 파악하도록 코드를 만드는 방법에 대해서 설명하고 있는 책이다. 특히 한국에서 프로그램을 개발하는 사람들이라면 반드시 읽고 넘어가야 하고, 자신의 코딩 스타일에 대해서 다시 한번 생각을 할 수 있도록 만들어주는 책인 동시에, 코딩 스킬을 한 단계 업그레이드 하도록 만들어 주는 가장 기본기를 가르쳐주는 유익한 책이다.

책의 앞부분을 읽을 때, 학교에서 배운 프로그래밍 코딩 작성 방법에서 조금 더 구체적으로 설명하겠지 라는 나의 생각을 완전히 뒤 엎어버렸다. 책의 두께에 비해 중요한 정보들을 가득 담고 있을 줄은 전혀 예상하지도 못했다. 코딩은 단순히 내가 요구하는, 내가 목표로 하는 결과만을 동작시키거나 만들어 내면 된다는 나의 생각을 완전히 부셔버렸다. 변수나 함수 하나의 이름을 붙이는 것에서부터, 전체 프로그램의 개발 방법까지를 어떤 방식으로부터 시작해서 어떻게 마무리를 해야지만 버그가 적고 유지 보수를 쉽게 할 수 있는 지를 깨우쳐 준다. 이 책의 저자가 말한 대로, 원래부터 간결하고 효율적으로 코드를 작성하는 능력을 가진 사람이라면야 굳이 이 책을 읽을 필요는 없다. 하지만, 한국에서 저자가 말한 이상형의 개발자는 극히 찾기 드물다. 엄청난 작업량과 바쁜 스케줄 때문에 모든 개발자들이 좀더 좋은 코드를 만들기 보다는 단순히 돌아가기만 하면 되는 코드들을 양산해 낸다. 얼마 전 나 자신만 하더라도 프로젝트 스케쥴에 쫓겨 우선 돌아가기만 하면 된다라는 생각을 갖고 코드 작성하였고, 지금에 와서는 내가 왜 이렇게 코드를 만들었는지, 또 이 함수는 어떻게 돌아가는지 등 유지 보수에 엄청난 시간을 재투자 하고 있고 다시 코드를 만들어 냈다. 이게 얼마나 어리석은 짓이고 낭비인지를 이 책을 읽으면서 나 자신에 대해 반성을 했고, 좀 더 일찍 이 책을 접했더라면 이라는 아쉬움이 밀려왔다.

비록 책의 두께는 얼마되지 않지만, 개발자들이 고쳐야 하는, 또 개선시켜야 하는 내용들이 가득 담겨져 있다. 나 자신을 위해서, 그리고 내 코드를 읽고 유지 보수해야 하는 다른 사람들을 위해서도 반드시 읽어보고 또한 이 책에서 말한 전부는 아니지만 코드를 작성할 때 좀 더 깊이 생각을 하게 만든다. 변수 명명에서부터 주석까지, 누구나 코드를 읽어도 이해하기 쉽도록 어떻게 하면 가독성과 어떤 식으로 생각을 해야 거대한 함수를 하나의 작은 기능을 갖는 단위로 쪼갤 수 있고 및 코드의 양을 줄이는 방법까지 경험을 통해 설명하는 괜찮은 책이다.

책을 읽다 보니, 어느날 선배 중에 한 명이 역시 저자와 마찬가지로 한국인 아닌 서양에서는 하루에 10줄을 코드를 작성하더라도 디버깅 및 테스트 등의 여러 가지 사항들을 모두 확인하여 보기 좋게 코드를 만든다고 했던 말이 기억이 난다. 과연 한국 실정에서는 가능한 얘기일까 반문 하고 싶지만, 그래도 아름답고 간결하게, 누구나 읽어도 코드 작성자의 생각을 싶게 파악하는 코드를 만들어야 하지 않을까 하는 생각이 든다.

좋은 프로그래머가 되기 위한 좋은 습관들은 읽기 쉽고 통일되게 코딩 원칙을 준수하는 것을 들 수 있을 것이다.

하지만 현재 프로그램의 대부분은 팀의 공동 산출물로서 한 명 및 다수의 잘못된 코딩 습관은 프로젝트 전체에 영향을 주게된다.



"읽기 좋은 코드가 좋은 코드다"는 Part 별로 "① 표면적 수준에서의 개선, ② 루프와 논리를 단순화하기, ③ 코드 재작성하기, ④ 선택된 주제들" 단계를 두고 예제를 활용하여 현재의 상태와 변화되는 상태를 간접적으로 경험이 가능하게 작성되어 프로그래머가 조금씩 변화를 느낄 수 있게 된다.

또한 컴파일러 및 개발도구의 변화로 불필요한 과거의 코딩 방법에 대하여 예제를 들어 이러한 문법의 부자연스러움을 강조하고 가독성을 높이는 방법를 자세히 설명하고 있다.



내가 읽지 못하는 코드는 남도 읽지 못한다는 생각과 올바른 프로그래밍 습관 및 원칙을 가지게 도와주는 가장 기본적인 서적으로 활용이 가능할 것이다.



하지만 이 책의 내용을 무조건 적으로 맹신하여 무리하게 적용한다면 무엇보다 "아무리 좋은 것도 과하면 아니한 것만 못하다"는 속담처럼 전체(및 본인)의 이상과 현실에서 적당히 타협하여 실천해 나가야할 것이다. 또한 설명에 강조를 하기 위함인지 일부 예제 코드들이 현실성이 떨어지는 부분들이 있기도 하다.

"읽기 쉬운 100줄의 코드는 읽기 어려운 50줄의 코드에 비해서 훨씬 낫다"



회사의 프로젝트를 수행하면서 직접 개발을 하는 경우가 많지만, 이에 못지않게 이미 개발된 소스코드를 분석하는 일도 많다.

남의 소스코드를 분석하다보면 잘 이해가 되는 소스가 있는 반면, 여러번 봐야하고, 심지어 필기를 해가며 분석을 해가야 이해가 되는 소스가 있다. 함수가 어떤 동작을 수행하는지 알기 위해 코드 한줄 한줄을 다 읽어야 이 함수가 무슨 일을 하는 지 알수 있다면 이 코드의 분석은 정말 끔찍하고 피하고 싶은 일이 될것이다.

이 책을 읽고 난 뒤, "이 코드는 이 부분 때문에 가독성이 참 떨어지네" 라고 잡아낼 수 있는 감이 생긴 것 같다. 물론 직접 코딩을 할 때도 많은 도움이 될 것이다.



이 책은 얇다. 삽화, 소스코드, 글 들이 잘 배치가 되어있어서 지루하지않고 재미있게 읽을 수 있고, 250페이지 정도여서 짧은 시간에 읽을 수 있는 분량이다.

저자들은 예제를 통해서 이 코드는 왜 나쁜지, 어떻게 하면 읽기 좋은 코드가 되는지를 설명하고 있다. 저자들이 직접 개발했던 코드들, 오픈소스 코드들(크로미움 프로젝트 등)에서 어떠한 부분이 읽기 좋지 않았고, 어떻게 개선이 되서 읽기 좋은 코드가 되었는지 잘 설명을 해주고 있다. 설명을 위해 만든 코드가 아닌, 문제가 있었던 코드들을 찾아서 사용하고 있어서 그런지 예제들이 참 좋았던 것 같다.



이 책은 총 네 파트로 구성 되어있다.

첫번째 파트 (표면적 수준에서의 개선) - 파트 이름대로 표면적 수준에서의 개선할 수 있는 내용들을 설명하고 있다. 변수명, 함수명, 주석등을 통해 코드를 접했을 때 바로 보이는 부분들을 다루고 있다.

두번째 파트 (루프와 논리를 단순화하기) - 조건문, 루프 (do/while, goto)를 분석하기 쉽게 구성하는 방법, 큰 논리를 단순한 작은 논리로 단순화하여, 읽는 사람이 쉽게 소화할 수 있는 방법을 제시하고 있다.

세번째 파트 (코드 재작성하기) - 큰 흐름과 관계없는 작은 문제들로 쪼갠다음 분리하고, 작업은 한번에 하나씩이라는 원리를 토대로 작업을 재정리하는 방법을 다루고 있다.

네번째 파트 (선택된 주제들) - 이 파트에서는 테스트 코드의 가독성에 대해 다루고, 분/시간 카운터 설계 및 구현과정을 진행하면서 어떻게 가독성을 높여가는지 보여주고 있다.



소프트웨어 엔지니어라는 직업을 가지고도 변수 명, 변수 선언 위치 등에 대해 고민하고 구현을 했었던 적이 과연있었나 싶고, 부끄럽기까지하다. 이 책의 내용들을 통째로 머릿속에 집어넣고 다니고 싶다. 코드를 작성하는 사람이 아닌 코드를 읽는 사람의 입장에서 구현을 하라는 말을 명심한다면 읽기 좋은 코드를 작성할 수 있을 것이다.



자신의 코드를 남에게 보이기 부끄러웠다면, 당장 이 책을 사서 보길 바란다.

이 책은 좋은 코드를 작성하기 위한 친절한 가이드입니다.



읽기 좋은 코드가 좋은 코드다. 그러면 읽기 좋은 코드가 왜 좋은지 그리고, 어떻게 해야 읽기 좋은 코드가 되는지를 기술하고 있습니다.

이런책이 나왔으면 좋겠다 하고 있었는데 마침 IT쪽으로 쉽고 재미있는 글을 쓰시는 임백준님의 번역으로 출간되어서 기대감을 갖고 읽기 시작했는데 역시 100% 만족시켜주었습니다.





코딩작업에서는 끊임없는 변화가 일어납니다. 기존코드에 새로운 기능을 추가한다든지 기존 기능을 변경한다든지 할 때 문제가 없으려면 기존코드에서 로직을 잘 파악하고, 코드를 추가후 제대로 동작하는지 테스트를 해야합니다.

작업시간의 대다수가 코드를 읽으면서 자신이 오래전에 작성해서 기억이 가물하거나, 동료나 남이 작성해서 잘 모르는 기존 로직을 파악하는데 사용됩니다. 시간이 많이 소요되며 이 단계가 잘못되면 나중에 큰 문제가 발생할 수 있습니다.



그래서 이 책은 언어와 상관없이 일반적인 코드의 가독성이라는 측면에서 코드 읽기를 개선시키는 방법들을 설명해줍니다.



Naming부터 주석달기, indentation등 쉽게 적용할 수 있는 표면적인 수준에서의 개선에서부터

루프 논리를 단순화하기 단계, 코드 재작성단계 를 거쳐

최종적으로 책에서 설명한 원리들을 적용시키는 예제를 통해 설명을 마무리 짓습니다.



각각의 팁들은 짧게 설명은 개선 전 코드와 개선 후 코드의 비교를 통해, 그림을 통해 , 때때로 충실한 본문을 통해 잘 전달되고 있습니다.

물론 코드를 보기 좋게 포맷팅해주는 것은 요즘 이클립스같은 통합 IDE들에서 단축키를 통해서도 무의식적으로 할 수 있지만, 어떤 원리를 통해 코드 다듬기를 하는지를 알고 하는것과 모르고 코딩하는것은 큰 차이가 있다고 생각됩니다.



하나하나 적용해가면서 내가 작성한 코드가 남에게 조금 더 보기 좋고, 이해가 잘되게 한다면 회사내에서 일이 더 즐거워질테고, 팀이 생산성 및 품질이 증대될것이라 생각됩니다.



그리고 마지막에 나온 Appendix의 도서들은 코드를 작성하는데 도움이 되는 주옥같은 책들입니다. 번역된 책들도 있으니 읽어보시면 좋을것입니다.