좋은 프로그래머란?(2) - 언제나 옳은 프로그래밍을 하자

좋은 프로그래머에 대한 생각을 한번 정리하고 나니 하고 싶은 말이 몇가지 더 생겼다. 너무 기본적인 이야기들이지만, 기본을 잘 지킨다는 것이 얼마나 중요한지 알기에 가끔씩이라도 기본을 되새겨 보는 것이 좋다고 생각한다. 가끔씩 한번쯤 읽어보면 좋은 글이 되었으면 좋겠지만, 사실 그렇게 잘 쓸 자신은 없다.ㅎ

이번에 이야기 할 내용도 다른 사람과 함께 프로그래밍 하는 방법에 대한 이야기다. 회사에서 일하다가 어떻게 하면 더 좋은 프로그래밍을 할 수 있을지 개인적으로 고민하고 생각했던 내용을 글로 표현하여 적어 둔 것이다.

예상을 벗어나지 말자

잘 짜여진 프로그램 코드를 읽으면, 처음 읽어도 술술 읽힌다. 어느 정도만 봐도 뒷 부분이 예상이 된다. 남이 짠 코드라도 읽고 이해하는데 큰 어려움이 없다. 왜 예상이 되는 걸까.

코드 리뷰의 중요성은 날이 갈 수록 강조되고 있는데, 코드 리뷰를 하면 제일 먼저 확인 할 수 있는 것이 코드의 구조적 안정성이다. (구조적 안정성이라는 말이 있는지 모르겠지만, 코드의 안정성과는 다르게 봐야 할 부분이라 그렇게 표현해 보았다) 구조적 안정성은 다른 사람이 코드를 처음 접했을 때 얼마나 쉽게 이해할 수 있는지 판단하는 가장 중요한 요소이다.

구조적 안정성이란 작성된 코드의 구조가 전체적으로 일관성(Consistency)을 갖고 내용의 구성이 응집성(Coherence)을 갖는 것이다.

구조가 일관되다는 것은 파일이나 폴더의 구조를 포함해서, 함수나 구조체의 구성이 일정한 형식을 갖는 것이다. 일관성이 있는 코드는 한 눈에 보기에도 구조를 쉽게 파악할 수 있게 해준다.

내용의 구성이 응집성을 갖는 다는 것은 의미적으로 분류가 잘 되어 있고, 분류에 따라 구분지어 위치하고 있다는 것이다. 같은 역할의 정보들이 하나의 구조체, 클래스 안에 있는 것이나 같은 역할의 수행문이 같은 메소드, 함수 안에 있는 것 또는 다른 역할의 수행문을 서로 다른 메소드, 함수로 구분되는 것을 뜻한다.

그렇게 작성된 코드는 읽으면서 바로 다음 코드가 예상이 되기에 코드를 읽는 사람, 특히 처음 접하는 사람에게 큰 도움이 될 뿐만 아니라 추후에 유지보수나 디버깅 할 때도 큰 역할을 한다. 예상대로 구현되어 있다는 것은 함께 일하는 사람들에게는 더 없이 큰 효율을 제공하는 것이다!

코드 리뷰를 올리기 전에 본인의 코드를 보고 빠르게 다시 읽어 보면서 흐름을 확인 해보라. 예상을 벗어나지는 않았는지 확인 하기에 좋은 방법이다.

얼마전에 아래와 같은 코드를 리뷰하게 된 적이 있었다.

get_battery_info(app_data);

데이터를 어디다 가져온다는 것인지 불분명해 보였다. 리턴 값은 아니니 app_data에다가 가져오는 것인가 싶었는데, get_battery_info를 열어보니, app_data의 특정 필드에 데이터를 쓰는 루틴이 있었다. 응집성에 문제가 있는 것이다. get_battery_info라는 함수와 app_data는 불필요하게 묶이게 되었고 외부에서 내부의 동작을 예상할 수 없는 것이 문제다.

*이 예제는 함수형 프로그래밍의 장점을 논하기 좋은 예제이기도 하다.ㅎ

(번역) 함수형 프로그래밍이란 무엇인가?

최소한의 가정을 하자

데모때 사용할 간단한 프로그램을 서둘러서 만들게 되었다. 한사람이 얼른 뚝딱 만들어서 1차 데모를 잘 했다. 근데, 더 높은 분에게 일주일 후에 다시 또 데모를 하게 되었다. 일주일 동안 기능이 추가 되었는데, 예전에 만든 프로그램은 사용할 수가 없었다. 코드는 1차 데모에 한정된 엄청난 양의 가정을 가지고 구현되어 있었다.

데모니까...음...그럴 수 있지...?

두 개의 프로그램이 서로 연동하는 해야하는 프로젝트였다. 주고 받을 데이터는 여러가지가 있었지만 그 중에는 특정 이벤트의 발생 여부만을 알려주는 것도 있었다. 그것을 완전히 독립적으로 구현해놨다. REST API를 사용하면 그 이벤트의 발생 여부가 확인된다. 근데 막상 실제 시나리오를 구현하다보니 그 이벤트가 어떤 상황에서 전달되는 것인지에 대한 논의가 필요했고, 가능한 간단하고 명확하게 정리하고 싶었지만 쉽지가 않았다. 이유는 이미 코드에 그 이벤트는 어떤 상황에서만 들어 온다는 가정이 포함된 채로 구현이 되어 있었기 때문이다.

두가지 사례에서 공통적으로 가정을 최소화 해야함을 강조하고 있다. 가정이 많은 코드는 특정 상황에서만 정상동작하며 따라서 코드의 재사용과 변경이 어렵다!!

가정을 최소화하여 프로그래밍 한다는 것은 사실 추상화를 얼마나 잘 하냐를 뜻하는 것과 같다. 추상화 수준에 대한 이야기가 나오면 이야기도 길어지고 복잡해 질것 같아서 가정을 최소화 하자고 표현했지만, 가정이 많다는 것은 추상화 수준이 낮다는 것이고, 매우 구체화 되어 있는 코드를 만들었다는 것이다.

만약, 간단한 데모를 위한 프로그램을 만들더라도 추상화를 잘 해서 구현했다면 데모의 내용이 바뀌거나 실제 사용될 프로그램을 구현할 때 코드를 재사용 할 수 있었을 것이다. 마찬가지로 추상화가 잘 되어 있는 코드로 프로그램을 구성했다면 시나리오의 변경에도 코드 구조를 쉽게 변경 할 수 있었을 것이다. 근데, 진짜 문제는 추상화 수준에 대한 고민 없이 일단 주문한 코드를 만들고 보는 문화다!!!

내가 제안하는 좋은 방법은 가정을 최소화하고, 말하듯이 프로그램의 동작을 글로 적어본 다음 각각의 내용을 추상화된 문장이다 단어로 구분하여 구현하는 것이다.

"서버에서 정보를 가져와서 특정 이벤트가 있는지 확인하고, 이벤트 존재 유무에 따라서 A와 B행동을 수행한다." 라는 요구사항을 구현하는데, 하나의 함수 안에서 데이터 가져와서 조건문 분기하고 A와 B행동 처리하는 코드까지 한번에 다 넣을 수도 있다. 추상화 수준이 엄청 낮다. 동작에는 문제가 없겠지만, 요구사항이 변경되면 대응하기 힘들다.

언제나 옳은 프로그래밍

언제나 옳은 프로그래밍이라는 주제로 두가지 이야기를 해봤다. 언제나 옳을 순 없겠지만, 가능하면 조금이라도 더 많은 상황에서 옳은 프로그램을 만드는 것에 대한 이야기를 하고 싶었다. 누가 봐도 읽기 쉽고 예상 가능한 코드를 만드는 것. 당장 눈앞의 요구사항만 만족할 수 있는 조건이 많~~~은 코드를 지양하는 것. 둘 다 많은 사람들이, 많은 상황에서 옳다고 생각할 수 있는 코드를 만드는 일이다.

결국 오늘도 지난번 이야기와 마찬가지로 함께 프로그래밍하기 좋은 프로그래머가 되자는 내용이었다.ㅋㅋㅋ 또 다시 말하지만, 다른 사람을 위한 것은 결국 나를 위한 것이다. 시간이 지나고 내가 다시 그 코드를 봤을때 정말 나는 늘 다른 사람이 되어 있기 때문이다.ㅎ