김성렬 개발 블로그

대부분의 프로그래머가 품질에 대해 압박을 받는다지만 일정에 대한 압박만 못하다.

이렇게 일정이 빠듯할 땐 리팩토링 얘길 꺼내지 말고 몰래 실시하자.

-마틴 파울러in 리펙토링 .팀장에게어떻게 말을꺼내나 -

이미지 출처 https://www.slideshare.net/madvirus/mvp-63161829

리펙토링이란 외부적으로 보이는 기능에는 영향을 주지 않으면서 내부 구현을 변경하는 작업을 말한다.

대부분의 소프트웨어가  초기 설계 목적에 맞게 비지니스가 흘러간다면 리펙토링이란 것은 필요없을 것이다.

해당 s/w의 도메인에 대한 이해부족 또는 기획에 다 담지 못한 요구사항이 개발 단계 또는 개발 이후 드러나 설계가 변경되어야 하거나

사업 확장으로  추가되는 기능이 현 설계로는 비효율적이다 판단 될때

소프트웨어는 재설계 되어야 한다.

굳이 이런 거창한 의미가 아니더라도 신입 프로그래머들의 미숙한 추상화와 구글링을 통해 복붙한 소스코드들은 가만히 두면 나중에 타격을 맞기 때문에 사수역할의 선임 프로그래머는 이를 잡아 내어

해당 부분의 리펙토링을 지시 해야 한다는 부분에서도 리펙토링은 당장 내 옆에서도 이루어 질수 있는 작업이고 수시로 꾸준히 이루어 질수 있는 업무다.

객체간 결합도가 높아지면 해당 소프트웨어의 복잡도는 겉잡을 수 없이 증가한다.

결합도가 높은 소스코드 위에서 코딩을 한다면 그 이후 이루어지는 소스코드들은 서로간 긴밀하고 타이트한 관계를 유지 할수 밖에없다.

창업 초기 기획이 이루어 지지 않은 상태에서 개발을 시작했고

기획과 개발이 동시에 진행되면서 개발 경험 부족이라는 문제와 함께 기획 부족이라는 문제를 같이 겪으면서 아주 죽을 맛이 였다.

어차피 만들어놔도 다시 바뀔껀데 라는 생각은 사람을 의욕 저하상태로 빠트리기 충분했고  

정말  소스코드는 꼴도 보기 싫을 만큼 더러웠다.

STS 를 열어 보는 것이 두려웠고 뭐하나 기능수정해달라는 것도 인상을 쓰면서 "이걸 어찌 해야 하나"라는 생각에 한숨부터 쉬면서 소스코드를 만졌다.

결론은 

지금 당장에 잘 짜여진 소스코드가 아니라면 그 이후 계속되는 코딩 작업은 소프트웨어 자산에 제 3금융권 어깨 형님들의  기술 부채를 계속 끌어다 쓰는 것과 같다.

지금 당장 자금이 충분해서 안정되듯이  프로그램은 잘 돌아 가지만 부채가 쌓여서 이자가 겉잡을 수 없이 늘어났을 때 

버그라는 어깨형님들이 당신에게 들이닥쳐 당신의 휴식시간을 집어던지고 깨부시면서

윽박 지를 것이다.

" 돈을 빌렸으면 갚아야지!!"

프로그래머에게 품질에 대한 일정은 주어지지 않는다.

그러나 품질에 대한 책임은 프로그래머에게 있다.

버그가 생겼을때 그 것을 잡아야 되는 당사자는 경영진이 아니다.  

경영진에게  지금 잘돌아가는 소프트웨어에서 

1천라인 짜리 1개 클래스는 객체지향적이지 않으니 

고쳐야 한다고 이해시키는 것은 불가능하다.

이해시키기 위해서 당신은 객체지향이 아닌 prinf("Hello C World\n"); 부터 경영진에게 가르쳐야 할 것이다. 

그냥 마틴 파울러의 조언처럼 몰래 실시하고 품질에 대한 시간을 스케줄에 당연히 포함되도록 일정을 계산해야 한다.

프로그램을 작성할 때 습관적으로 유닛테스트 코드를 작성하는 사람과 그렇지 않은 사람 사이엔 그 자체로 이미 프로그래머로서 가능함기 어려울 만큼 깊은 수준차가 존재하는 것이다.

 -임백준(BaekJoon online 운영자)-

유닛 테스트는 정말 중요하다.  군대에서 토비 스프링을 통해 스프링을 처음으로 접했고

이일민 개발자님의 책을 읽으면서 유닛테스트의 목적을 배우고

테스트 코드는 단순히 잘 돌아가나? 를 보기위한 대충작성하는 것이 아니라는 것을 배웠다.

단위테스트를 하는 이유는 개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빨리 확인받기 위해서다.

이때 확인의 대상과 조건이 간단하고 명확할수록 좋다.

-토비 스프링 vol1-

 창업당시 서비스 오픈을 최대한 빠르게 해야 했다.

최소한의 창업 준비 또는 진행 성과가 좋아야 학교에서 청년 창업을 위해 지원하는 투자금을 타낼수 있었기 때문이다.

클라우드서버 구입과 관리 서버내 리눅스로 환경구성하는 것 대한 문제도 전부 나의 업무였다.

AWS를 쓰려다가 클라우드서버 사용경험이 전무했기때문에

"그래도 한국 업체이면 전화문의로 한국말로 도움을 받을수 있지 않겠느냐 "라는 의견들이 나와서 KT UCloud  를 이용하기로 했었다. 

(지금생각하면 후회한다. 상업화되지 않은 테스트 단계에서 AWS 프리티어로도 충분했는데 큰돈은 아니지만 쌩돈을 썼다.)

처음 하는 일은 늘 그렇듯 힘들었다.

(내가 최고권한서버관리자인데 왜 permission deined 냐

권한좀 주세요 ㅠㅠ 리눅스님 ..

-09월21일 카톡 일기-)

 그러나 어플서버 개발또한 병행 되어야 했고

서버쪽은 개발이 가능한 사람은 나뿐이였기 때문에 많이 지쳐갔다.

그렇기에 나는 매우 합리적인? 결정을 내렸다.

유닛테스트코드를 생략했다. 그때 당시  CRUD 관련 유닛테스트 코드들은 잘 작성 되있었고. Service 계층을 짜는 단계라서

"db에서 잘받아 오는데 뭔 문제 있겠어

문제가 있으면  로그 찍어서 어찌어찌 해결 되겠지"라는 생각을했다

처음에는 문제가 없었다.

그러나 문제는 어플과 연결시킨 한참뒤에 벌어졌다.

입력값이 몇 개가 비었을때, 특수 문자 입력을 막아지 않을것, 과 같이 클라이언트(어플)단의 굉장히 사소한 문제들이 

Service 단에서 예외 처리를 미숙하게 해놓은점 ,선언적 트랜잭션 처리를 생각없이 전부 선언 한것 과 같은 나의 미숙함이 곂치면서 심심하면 어플이 꺼지는 문제가 생겨났다.

문제는 어디서 발생한 에러인지 정확히 몰랐기 때문에 하나의 버그가 발생하면

하나의 기능에 관여하는 클라이언트와 서버 의 모든 클래스를 까봐야 했다.

에러로그로 간단하게 잡히는 문제들도 있었지만

문제는 같은 에러를 잡아 놓고도 다음주가 되면 새로운 에러를 잡기위해 완벽하다 생각했던

소스코드를 다시 검토 해봐야 했다.

기능 추가로 새로운 도메인?이 필요하여 DB에 테이블을 추가하고 그에 필요한  클래스들에는 지금있는 버그들 때문에 바쁘다는 핑계로 테스트코드를 작성하지 않았다.

이런 악순환은 계속되었다.

그때 조금만 더 고생하더라도 테스트 코드를 작성해놨으면 

같은 소스코드를 반복해서검토하고

그때그때 이거 돌아가나? 라는 생각에 main열어서 임시로 돌려보고 다시 지운다던지

하나의 클래스를 테스트하기 위해 어플 부터 서버db 끝까지 전부 한번 돌려봐야만

기능 테스트가 가능한 이런 끔찍한 문제가 안일어 났을까란 생각이 든다.

그때 내가 자주 했던 부끄러운말이 있다

"오늘 서버 테스트 해봐야될거있으니까 다들 모여주세요"

나는 책을 통해 수많은 문제들을 보았고 그 문제들을 해결하는 솔루션을 책을 통해 배웠지만

실제 상황에서 대처하지 못했다.

Junit을 쓸줄알고 mokito를 사용해 더 깔끔한 테스트 코드를 만들어 내는 것과 같은 일들을

아는것과 하는것은 전혀 다른 문제 같다.

개인적인 생각이지만

개발과 설계,관리는 분리되는게 맞는것같다. 두개를 동시에 하기는 힘든 것 같다.

컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다.

좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

-마틴 파울러-

데이터를 뽑고 빼는건(CRUD) 정보처리라는 소프트웨어의 사용목적에 있어서 가장 기본적인 기능이다

하나의 도메인에 대한 CRUD 처리는 너무나 쉽다 구글에 널려있는 jdbc 예제 소스코드를 긁어온다면

Crtl+C,V 3가지 버튼 만으로도 구현 할수 있다.

그러나 10개의 도메인에 대한 CRUD 처리는 좀더 어렵다. 1:N M:N 문제로 여러 테이블들이 서로 얽매여서

비지니스에 핵심적인 도메인이 무엇인지 선택하고 결정하는 것은 향후 개발에 있어서 큰 문제를 일으킬수있다.

예를 들어

우체국에서 사용할 소프트웨어는  '주소' 는 도메인이다.

주소를 통해 물류들을 분류하고 주소를 활용하여 거리를 측정하고 배송비용을 산정한다.

우체국을 위한 소프트웨어를 개발해야한다면 설계자는 주소를 도메인으로 인식하고

주소에 대해 처리될수 있는 여러 비지니스적 문제들을 깊게 파고 들어 설계를 해야 할것이다.

그러나 다른 소프트웨어 에서 '주소'는 회원 정보의 애트리뷰트(속성) 정도만으로도 큰 문제 없이 사용될수있다.

같은 '주소'라는 정보를 처리하는 방식은 그 소프트웨어를 사용하는 클라이언트가 누구냐에 의해

우리(개발자)들은 다르게 인식해야한다.

다시 돌아와 도메인에 대해 얘기 하자면

도메인을 결정하기 위해서는 그 도메인에 대한 이해가 필요하다.

도메인간 연관 관계에 대한 이해 , 그에 맞는 설계 가 진행되지 않는다면 소프트웨어는 개발될수없다.

나는 그점을 간과했다.

경영팀에 해당하는 팀장역활을하는 친구의 말을 너무 쉽게 받아들였다.

"게시판이 필요하고 메시지를 우리 어플 유저끼리 보낼수 있어야해"

"우리 어플에서 만들어진 정보들을 기반으로 pdf파일을 생성하서 메일을 보내줘야해 "

 같은 문장들을 게시판, 메시지, 메일 과 같은 단일 도메인으로 받아들였고

나는 망언을 했다

"그거 쉽겠네 한 3주일이면 될거 같다"

게시물을 등록하는 기능

메시지를 보내는 기능

메일을 보내는 기능

은 너무나 쉽다.

구글링을 하면 발에 치이는 것이 위 기능들에 대해 설명하는 소스코드들이다.

나는 1개의 도메인을 처리하는 소프트웨어를 여러 개 만든다고 생각을 해서

이 기능들을 쉽다고 망언을 뱉었다.

결론을 말하자면 3주만에 끝내겠다던 프로젝트는 5달동안 질질 끌었고(중간고사 기말고사 문제이 껴있긴했지만)

개발이 되는 과정에서 기획은 기능구현이되자마자 변경되는 일도 많았다.

기획이 날아올랐다.

어찌보면 기획은 잘못이 없을수도 있다.

소프트웨어의 끊임 없는 변경은 소프트웨어공학이 해결하고자 했던 오랜 문제 이며

 그 문제를 해결하기 위한 여러 방법론 개발론들이 있다.

나는 단순 기능 구현에만 집중했고 좀더 객체지향적이고 ,추상화를 통해 소프트웨어 결합도를 낮추고자하는

 노력과 실력 그리고 경험이 없었기 때문에 설계가 망가졌다.

나중에는 서버측 하나의 기능테스트를 하려면 개발팀(4명) 전부가 모여야만 가능할만큼 소스코드는 망가져있었다 

(이 부분은 단위테스트의 중요성에서 자세히 다룰것이다.)

 마틴 파울러가 말했다.

컴퓨터가 이해하는 코드는 어느 바보나 다 짤수있다.(돌아가는 코드는 누구나 다 짠다.)

좋은 프로그래머는 사람이 이해할수 있는 코드를 짠다.

나는 바보 였나 보다.

창업을 통해 시작한 프로젝트는 실패했다.

비즈니스적 목적에서나  소프트웨어의 개발 완성 자체에 의의를 둔다면 실패라는 단어가 부적절할수 있지만

나는 개발자로서 이 프로젝트가 실패했다고 결론을 내리고 싶다.

서로가 서툴렀기 때문에

 기획, 개발, 디자인 3요소가 일관성 있는 프로세스에 의해 진행되지 못했다는점

향후 유지보수성이 현저히 떨어질만큼 추상화가 엉망이라는 점

커뮤니케이션이 서툴렀던 점

나의 고집

경영진에게 소프트웨어의 특수성을 이해시키려고했다는 점

설계의 미숙함

실패의 원인 또는 아쉬움을 말하자면 끝이 없다.

그 내용들에 대해 글을 써보고자 한다.

창업 경험 게시글들은 태그 #창업을 전부 걸어놓는다