추천사

"사소한 곳에서 발휘하는 정직은 사소하지 않다."

"소프트웨어 개발에서 아키텍처가 중요하다". 는 명제는 정말 유효하다. 단지 그 의미가 무엇인지 정확한 시각이 다를 뿐이다. 테스트 코드만으로 설계를 주도한다는 1990년대 후반 생각으론 더이상 안된다. 그럼에도 세세함에 주의를 기울이는 태도는 전문가에게 더욱 필수적인 자질이되었다.

세세함에는 위대한 힘이있지만 우리가 흔히 동양적인 사고에 대한 편견처럼, 이렇게 삶에 접근하는 태도는 무언가 겸손하고 심오향 향기가 풍긴다.

불행히도 우리는 세세함에 집중하는 태도가 프로그래밍 기술에 핵심적인 주춧돌이라 여기지 않곤한다. 코드에서 일찌김치 손을 뼨다

Chapter 1. 깨끗한 코드

코드가 존재하리라!

코드가 자동으로 생성되는 시대가 도래했다. 그런데 그즘되면 프로그래머는 필요가 없다. 하지만 코드가 사라질 가명성은 전혀없다. 기계가 실행할 정도로 상세하게 요구를 명시한는 작업 바로 이것이 '프로그래밍'이다. 이렇게 명시한 결과가 바로 '코드'이다.

분명 앞으로 프로그래밍 언어에서의 '추상화' 수준은 점차 높아지리라 생각한다. 더불어 특정 응용분야에 적합한 프로그래밍 언어의 수도 점점 많아질것이라 예상한다. 고도로 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세역시 코드이다. 어떤 언어를 사용하든 코드는 기계가 이해하고 실행할 정도로 엄밀하고 정확하고 상세하고 정형화 되어야한다.

언젠가 코드가 사라질것이라 예상하는 것은 '비정형적인' 수학이나오리라 기대하는 수학자와 비슷하다. 우리가 시키는대로 하는대로 하는 기계가 아니라 원하는 대로 돌아가는 기계가 나오리라 기대한다. 하지만 절대 불가능하다.

코드는 궁극적으로 요구사항을 표현하는 언어라는 사실이다. 요구사항에 가까운 언어를 만들 수 있고, 요구사항에서 정형구조를 뽑아내는 도구를 만들 수도 있다. 어느순간 정밀한 표현이 필요하다.

나쁜코드

나쁜코드에 발목잡혀 고생한 기억이 있는가 ? 조금이라도 프로그램을 짜봤다면 필경 수없이 경험했으리라. 우리는 나쁜코드를 헤쳐나간다. 그러나 무의미한 코드만 끝없이 펼쳐본다. 그렇다면 왜 나쁜 코드라고 하는것일까 ?

1. 회사를 망하게 한 나쁜코드

80년대 후반 '킬러 앱' 하나를 구현한 회사가 있었는데 , 제품은 커다란 인기를 끌었으며 수많은 전문가가 구매해 사용했다. 하지만 제품 출시 주기가 점차 늘어지기 시작하더니 , 심지어 이전에 있던 버그가 다음 버전에도 그대로 남아있었다. 프로그램 구동 시간이 길어지고 프로그램도 죽는 횟수도 늘어났다. 프로그램을 쓰다가 결국 닫아버리기 까지 하였다. 그 후로 사람들은 이 회사의 '킬러 앱'을 더이상 이용하지 않았고, 얼마안가 회사는 도산하였다.

알고보니 그들은 출시일이 바빠 코드를 마구 짰고, 기능을 추가할 수록 코드는 예상치 못한 버그로 점점 엉망이 되어감과 동시에 결국 감당하기 힘든 불가능한 수준에 이르렀다. 회사가 망한 원인은 바로 나쁜코드탓이었다.

우리는 이렇게 대충 짠 코드가 "잘 돌아가네?" 라고 안도할 때가 많다. 안돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 적도 많다. 하지만 나중에 다시 정리하겠다고 다짐했었고, 불행히도 그 나중은 다시 돌아오지 않았다.

일하다 혐오스러운 코드에 실증이나 대대적인 재설계 를 요구하기도 한다. 결국 회사의 승인으로 재설계가 이루어지고 태스크팀이 만들어진다. 새로운 시스템을 다시 만들고 , 그뿐만 아니라 그동안 기존 시스템에 가해지는 변경도 모두 따라잡아야한다. 새로운 시스템 기능을 100% 제공하지않는한 기존 시스템을 대체 할 수 없다. 결국 기존 시스템을 따라잡을 즈음 초창기 태스크 팀원들은 모두 떠나고 새로운 팀원들이 새 시스템을 설계하고자 한다. 왜? 그러기엔 코드가 너무 엉망이니까. 우리는 고로, 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이라는 사실을 인정해야한다.

태도와 난제

비유를 하나 들겠다. 자신이 의사라 가정하고, 어느환자를 수술하기전 손을 씻지말라 요구한다. 그것도 환자가 의사에게 요구한다. 시간이 너무 걸리니까. 하지만 의사는 단호히 거부한다. 왜?, 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 환자의 말을 그대로 따르는 것은 전문가답지 못하다.

프로그래머도 마찬가지다. 나쁜코드의 위협을 이해하지못하는 관리자의 말을 그대로 따르는 행동은 전문가 답지 못하다. 고객이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 하지만, 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.

하지만, 기한에 맞춰 작업하려면 필수불가결로 나쁜코드를 양산할 수밖에 없다고 느낀다. 간단히 말해, 빨리 가기위해 시간을 들이려 하지않는다. 진짜 전문가는 이 부분이 틀렸다 라는 것을 잘 안다. 나쁜코드를 양산하면 기한을 맞추지 못하며 오히려 엉망진창인 상태로인해 속도가 곧바로 늦어지고, 결국 기한을 놓치게 될것이다. 기한을 맞추는 유일한 방법은 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관인것이다.

깨끗한 코드라는 예술?

깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷하다. 그림을 보면 대부분의 사람은 잘 그려졌는지 엉망으로 그려졌는지 안다. 그렇지만 잘 그린 그림을 구분하는 능력이 그림을 잘 그리는 능력이 아니다 라는 것도 우리는 잘 알고있다.

깨끗한 코드를 작성하려면 '청결'이라는 힘겹게 습득한 감각을 활용해 자잘한 기법을 적용하는 절제와 규율이 필요하다. 열쇠는 '코드감각' 이다. 이런 감각이 발달되면 좋은 코드와 나쁜코드를 구분할 수 있다. 뿐만 아니라 절제와 규율을 적용해 ''나쁜코드''를 ''좋은코드''로 바꾸는 전략도 파악할 수있다.

다시말해 프로그래머는 빈 캠퍼스를 우하한 작품으로 바꿔가는 화가와 같다.

C++언어의 창시자 '비야네 스트롭스트룹'은 '우아한' 이란 단어를 자주사용한다. 그가 말하길 깨끗한 코드는 '보기에 즐거운'코드이다. 잘 만드는 오르골이나 잘 디자인된 차를 접할 때 처럼 깨끗한 코드는 보는사람에게 즐거움을 선사해야한다는 것이다.

효율도 마찬가지로 강조한다. 효율이란 단순히 속도만을 뜻하는 것이 아니라 , 컴퓨터 자원을 낭비하는 코드도 우아하지 못한다 라고 한다. 그리고 '우아하지 않는 코드'는 바람직하지 않는 결과를 초래한다. 그리고 그것을 '유혹'이란 단어로 그 결과를 표현한다. 그리고 나쁜코드는 '나쁜 코드'를 유혹한다. 나쁜코드를 고치면서 오히려 나쁜코드를 만든단 뜻이다. 나쁜코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 하지만 깨끗한 코드는 한가지만 집중한다.

전에 읽었던 실용주의 프로그래머 저자는 '깨진창문' 비유를 자주하였는데, 아무도 신경을 안쓴나머지 결국 자발적으로 창문을 깨버린다. 낚서와 쓰레기가 쌓여도 치우지 않는다. 일단 창문이 깨지고나면 쇠퇴하는 과정이 시작된다.

'그레디 부차'는 깨끗한 코드란 가독성이 좋아야 한다고 말한다. 잘 쓴 문장처럼 잘 읽혀야 한다는 시각을 특히 좋아한다.

1. 깨끗한 코드와 나쁜코드의 차이는?

깨끗한 코드란, 예술적으로 '보기에 즐거운', '가독성 있는', '질서 정연하고 청결한' 코드 임과 특징으론 한가지의 목적에 집중한다는 것이다.

반면 나쁜코드는 보기에 난잡하고, 가독성이 떨어지며, 방치되어있는 코드라 할 수 있다. 또 한가지의 코드에서 여러가지 일을 하려다 보니 버그가 양산될 수밖에 없다.

2. 깨끗한 코드를 작성하기위해 어떻게 노력해야할까?

1. 모든테스트를 통과해야한다

2. 중복이 없다

3. 시스템 내 모든 설계 아이디어를 표현한다

4. 클래스,메서드,함수등을 최대한 줄인다.

   ​ - 간단한 코드 만들기 , 책 13page

중복과 표현력만 신경써도 '깨끗한 코드'라는 목표에 성큼 다가선다. 지저분한 코드를 손볼때 이 두가지만 고려해도 코드가 크게 나아진다. 하지만 나는 한가지 더 고려한다. 그것은 추상화 고려하기이다.

예를 들면, 직원정보가 저장된 데이터베이스든 , 키/값이 저장된 해시맵이든 여러값을 모아놓은 배열이든 프로그램을 짜다보면 어떤 집합에서 특정 항목을 찾아낼 필요가 자주 생긴다. 이런 상황이 발생하면 추상 메서드와 추상 클래스를 만들어 '실제 구현'을 감싼다. 그러면 여럿 장점이 생기는데 첫번째로, 집합을 추상화 하면 '진짜' 문제에 신경쓸 여유가 생긴다. 간단한 찾기 기능이 필요한 온갖 집합기능을 구현하느라 시간과 노력을 낭비할 필요가 없기때문이다.

중복을 피하라, 표현력을 높여라, 초반부터 간단한 추상화를 고려하라.

결론

예술에 대한 책을 읽는 다고 예술가가된다는 보장은 없다. 책은 단지 예술가가 사용하는 도구와 기법 그리고 생각하는 방식을 소개할 뿐이다. 이 책역시 그렇고, 읽는다고 뛰어난 프로그래머가 된다는 보장이 없다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교, 도구를 소개할 뿐이다.

이책은 앞으로 나쁜코드를 좋은코드로 바꾸는 방법도 소개할것이다. 그리고 우리가 앞으로 해야할 것은 바로 연습.. 연습이다.!

느낀점

사실 표현력과 간단한 추상화 고려는 책의 설명에 와닿지 않는것 같다. 앞으로 이 부분에 의문점을 가지고 읽어나가야 할듯싶다.