티스토리 뷰
오랜만의 개발을 주제로 한 이야기입니다.
그동안 일을 하며 지내다보니 블로그에 개발을 주제로 글을 쓸 여력도 거의 없었는데.. 마침 얼마전에 일을 한지 1년을 넘겼더라고요. 어찌보면 약 1년 간의 개발 경험을 가지게 된 셈인데, 이에대해 개인적인 회고이자 마음 속 옹알이를 글로서 표현좀 해보고자 합니다.
참고로 아래 회고록에서 나오게 될 개발 용어, 코드는 Ruby/Ruby on Rails를 기준으로 작성했습니다.
코드리뷰를 통한 실력발전
' 내 코드는 못믿는다 '
' 코드 속 오타, 오류는 내 눈에 안보인다'
한번 쯤 개발을 하면서 흔히 이런말을 들어본 적이 있곤 했을겁니다.
우리 회사는 개발을 하면서 뭔가 기존의 기능이 수정되거나, 새로운 걸 개발을 해내면 개발팀 내부에서 코드리뷰를 거치는 과정이 있습니다. 그리고 코드리뷰를 통해 내 눈에 안보이는 문제가 되는 코드 혹은 조금 더 효율적으로 짤 수 있는 코드를 제안을 받을 수 있습니다. 매번 코드리뷰를 받으면서 느끼는 거지만, '이런 생각도 할 수 있구나' 라 느낄 정도로 코드 피드백을 받곤 합니다.
Q. 유저(current_user)가 가진 데이터에 있어, 300개 이후의 데이터를 조회하시오
data_ids = [4752, 4912, 5122, 5301, 5302, 5306, 5307, 5310, 5313, ...]
# 내가 짠 코드
Data.where(id: data_ids.drop(299))
# 제안받은 방식
Data.where(user: current_user).where('id < ?', data_ids[300])
하지만 '코드리뷰가 내 실수를 다 커버해주겠지' 하는 마음으로 너무 빈번하게 코드리뷰를 요청하면 이는 팀에게 있어 실례이면서 개발 초기에 이런 마인드를 가지고 리뷰를 요청한것도 있었습니다. 팀원들도 자신의 시간을 희생하며 내 코드를 보고 최대한 남의 코드를 이해하며 피드백을 해주는거다보니 리뷰를 요청할 때에는 신중하게, 리뷰를 받더라도 오타와 같은 피드백을 받기보단 코드의 퀄리티를 향상시킬 수 있는 피드백을 받을 수 있도록...
변수명에 대한 고민
변수를 생성하면서 네이밍을 짓는건 정말 어렵습니다.
초반엔 정말 네이밍을 막 지으면서도 별로 중요하게 생각 안했던건 아무래도 학창시절 아래와 같은 방식의 코딩 때문이었던 것 같습니다 -,-
int a = 0; // 구구단 입력 input
int i = 0;
printf("구구단 몇 단? :\n");
scanf("%d", &a);
for(i=1;i<10;i++)
{
printf("%d * %d = %d", a, j, a*j);
}학창시절 때에는 위 코드와 같이 [전혀 변수명을 고려하지 않고 코딩, 혼자서 개발해왔던 습관, 설명은 주석으로] 라는 습관이 실무개발 초창기 때에도 무섭게 바로 드러납니다.
코드를 보면서 변수 이름만을 보더라도 해당 변수가 무슨 역할을 하는지, 또 변수 이름 길이는 너무 길지 않은지, 변수 성격에 따라 값이 들어갔는지 등을 따져가며 변수의 이름을 짓는게 제일 베스트입니다. 하지만 이를 암에도 불구하고 지금도 변수명을 짓는다는건 정말 쉽지않은 고민입니다.. 😥
아래는 제가 변수 값의 성격에 따라 고민을 하며 지어본 변수명 예시입니다.
# 여러개의 ID값을 가진 변수
ids = [13, 17, 21, 34, 35, 39]
# boolean값을 가지는 변수
is_paid = true
is_done = false
# 기간을 가지는 변수
read_at = '2021-06-25 00:52:06 +0900'
물론 주석이 나쁜건 아니지만, 주석이 첨언되면 주석을 먼저 보고 코드를 봐야하는 수고가 필요하다보니, 웬만해서는 주석이 없더라도, 하물며 코드를 짠 사람한테 물어보지 않더라도 웬만하면 변수명만을 통해 코드를 이해시키려는 노력을 하곤 합니다.
남의 코드는 정말 이해하기 어렵다.
학창시절 때 주로 혼자서 개발을 하곤 했는데, 이게 지금도 아킬레스건이 되어 제 발목을 붙잡고 있습니다.
협업을 할려면 지금 기존에 짜여진 코드에 대한 이해, 특히 남이 짠 코드에 대한 이해가 중요합니다. 우리회사 같은 경우에는 기능의 유지보수나 신기능을 만들 때 코드리뷰 기간을 항상 가지곤 하지만, 이를 이해하는 과정이 지금도 고통스럽곤 합니다.
특히 특히 기존의 코드에는 많은 메소드와 Model 콜백이 얽혀있다보니 이 히스토리를 다 파헤쳐야 하는것도 있고, 남이 짠 코드에 있어 내가 모르는 문법도 종종 보이곤 하는데 모를 때 찾아야 한다는 수고가 있다보니 남들에 비해 시간이 걸리는 것은 제게있어 큰 딜레마입니다.. 😥
또한 내가 개발을 참여하지 않은 기능일지라도, 사전 코드리뷰를 통해 미리 타인이 개발한 코드를 익혀두고, 후에 유지보수나 코드의 오류를 해결해야 할 때를 대비해야 함도 있습니다.
낯선 기술에 대한 이해의 요구
때로는 낯선 기술과 연계해서(서비스에서는 기존부터 쓰여왔지만, 나는 써본적 없는 기술) 개발을 해야할 필요가 있곤 한데, 필자에게 있어선 한번도 경험해보지 못한 기술이 있을 경우 이를 빨리 배워내고 응용을 해내어 개발을 해내야 할 필요가 있곤 합니다. (뭐.. 간단히 예를들면 Redis 등과 같은?..)
기존 코드를 통해 익혀나가면 되긴 하나, 첫 째로 어디서부터 봐야할지 몰라서 어쩔 줄 몰랐었던게 있었고, 둘 째는 해당 기술에 대해 어디까지 기초지식을 알아야할지 몰라서 많이 애를 먹곤 했습니다. 지금은 활용과 구현에 있어선 과거에 비해 나아지긴 했지만.. 이제는 '기능의 완성' 보단 '최적화'를 생각하며 개발을 해야한다는 중요성을 깨달아가지고, 최적화를 생각하며 개발한다면 여전히 어렵게 느낍니다.
커뮤니케이션
1. 내가 생각하는 것이 정답이 아닐 수도 있다.
개발자는 주어진 기획을 기반으로 개발을 하는데, 가끔 긴가민가하게 내용이 적혀있을 때가 있습니다. 하지만 그 긴가민가한걸 괜히 '당연히 내가 생각하는게 맞겠지' 하는 마음으로 소통없이 개발을 하다 나중에 알고보니 그게 답이 아니어가지고 다시 시간을 빼앗겨가며 개발을 하는 수고로움이 있었습니다.
뭔가 긴가민가한건 내 마음대로 해석하기보단, 기획서를 제공해준 담당자에게 직접 물어보는 의사소통 과정을 필수적으로 하는게 최선입니다.
2. 개발을 하는 과정에서 비전공자에게 설명을 해야할 때
때론 비전공자에게 개발용어를 섞어가며 뭔가 설명이 필요한 때가 있습니다. (서버 부하 이슈, 코드가 내부적으로 어떻게 돌아가고 있는지 설명할 때 등) 사실 저도 초반에 이를 설명할 때 정말 큰 어려움이 있으면서도, 설사 설명을 할지라도 어떻게 설명을 해야할지 몰라서 말이 꼬이는 경우가 많곤 했습니다.
최근에는 이를 해소하는 방법 중 하나로서, 뭔가 일상적인 비유를 하며 설명을 통해 커뮤니케이션을 해내고 있습니다.
3. 핵심먼저, 부연설명은 후에
저는 대화를 할 때 설명을 길게 늘으면서 하는 스타일입니다. 상대방이 내 작업물의 히스토리를 모를까봐 장대하게 설명을 해야겠다고 느끼다보니 길게 설명을 하곤 했는데, 이러한 대화 성향이 문제가 많이 제기되곤 했습니다. 사실 말을 듣는 입장에서도 딱 결론을 먼저 듣고 싶어할텐데, 이같은 모습을 보면 많이 답답해하곤 했을겁니다. 그래도 이러한 부분에 있어 감사하게도 주변 동료분들이 피드백을 통해 '두괄식 대화법'을 제안해주셨습니다.
두괄식 대화법은 결론을 먼저 꺼내는 대화론이라고 보면 됩니다.
그리고 핵심을 말하더라도 '왜요?' 라고 되물어보면 그때사 슬금슬금 긴 히스토리를 꺼내며 설명을 해냅니다.
이 대화법이 서로에게 피곤하지 않으면서도 깔끔하다는걸 몸소 느끼게 되었습니다.
하지만... 뭔가 설명하는 성향이 많은 저로선 여전히 어려우면서도 지금도 종종 실수를 하는 화법입니다.. 😥
구현이 다가 아니다
이번 회고록에서 제일 풀고싶은 썰입니다.
예전에는 뭔가 기능을 하나 만든다면 내부 로직은 크게 신경쓰지 않고, 결과만 잘 보여지면 되겠거니 했지만.. 이는 큰 실수라는걸 개발 초기에 깨달았습니다.
1. 한번만 해도 될 일을 N번을 해낼 필요는 없다.
예를들어, 뭔가 특정 데이터를 찾아야 한다는 상황이 있습니다.
그래서 첫 째로, 일단 데이터 표현을 Array 형태로 해봤습니다.
ship_arr = [
{:id => 152, :status => "배송중", :shipping_code => 152436456},
{:id => 153, :status => "배송완료", :shipping_code => 351754634123},
{:id => 154, :status => "배송중", :shipping_code => 61289312}
]하지만, 154번 데이터의 shipping_code 값을 알아야 할 경우, 아래와 같은 방법으로 접근을 해야 합니다.
ship = ship_arr.find { |data| data[:id] == 154 }
ship[:shipping_code]하지만 위 방법은 반복문과 같으면서도, 154번 값을 가진 ID는 맨 끝에 있다보니 모든 데이터를 다 훑어봐야 하는 문제가 있습니다.
그러면 데이터를 Hash로 표현해낸다면?..
ship_hash = {
152 => {:status => "배송중", :shipping_code => 152436456},
153 => {:status => "배송완료", :shipping_code => 351754634123},
154 => {:status => "배송중", :shipping_code => 61289312}
}
ship_hash[154][:shipping_code]반복문도 필요없을 뿐더러 단 한줄만으로 원하는 결과를 알아낼 수 있습니다.
이와같이 한번만에 해낼 일을 굳이 N번을 해낼일은 없을텐데.... 이런 방법이 즉흥적으로 떠오르질 않다보니 종종 이런 실수를 범하곤 합니다. 그래서 뭔가 데이터를 탐색을 함에 있어, 반복문을 쓰는방법을 최대한 자제함으로서 코드 실행시간을 낮추는 방향으로 짜도록 많은 고민을 하고있습니다.
2. 신 기능 개발 후, 유지보수에 손을 못대선 안된다.
새로 짜는 코드야, 기존 코드를 생각할 것도 없이 내 마음대로 짤 수 있다보니 자유도가 높지만.. 문제는 미래에 기존의 코드에 새 기능을 얹히거나 과거에 짰던 코드를 이해하려고 할 때 총체적 난국이 되어버립니다. (거의 스파게티 코드가 된다고 해도 뭐...) 특히나 이런 문제는 과거 사이드 프로젝트로 해냈던 캐치딜에서 슬그머니 이 문제가 드러나게 됩니다..
그렇다보니 요즘은 하나의 기능에 모든 로직을 담아내기 보단, 기능 단위로 함수화 해서 개발을 해낸다던지, 변수명 또한 신중하게 짠다던지, if문을 최대한 줄인다던지, 반복문을 없앤다던지 등을 고려하며 코드를 최대한 난잡하지 않으면서도 심플하게 짜보려고 노력합니다.
특히 '로직을 개발함에 있어 기능 단위로 쪼개서 개발'은 객체지향 프로그래밍에서도 많이 활용되는 OOP 방식의 설계 에서도 추구하는 방식이기도 한데, 간단하게 아래와 같은 이점이 있습니다.
1. 코드간 의존성을 줄여준다. : 나중에 기능을 추가하거나 뺄 때 수월하게 할 수 있도록...
2. 코드의 길이를 확 줄여준다. (Fat Model, Skinny Controller)
3. 함수의 이름만으로 어떤 기능을 해낼지 직관적으로 알 수 있다.
4. 코드의 반복을 줄여준다. (Don't repeat Your self)
물론 이를 풀어보면 긴 이야기와 더 많은 공부가 요구되겠지만.. 일단 심플하게 위 4가지를 목표를 삼고 있습니다.
언젠가는 루비 개발자라는 커리어를 버려야 한다.
빠르면서도 쉬운 개발을 할 수 있도록 도와준다는 Ruby on rails의 이점에 이끌려 Ruby on rails 백엔드 개발자로서 일을 하곤 있지만, 국내에서는 Ruby 개발자로서 일한다는건 쉬운게 아닌 것 같습니다.
1. 너무나도 적은 Ruby 채용 Pool
일단 Job Position이 타 언어에 비해 정말 적다는게 너무 슬픈 현실입니다.... 😥
2. 타 언어의 장점을 익혀둘 필요가..
사실 필자는 Ruby/Ruby on rails 외에는 1개월 이상 실개발 목적으로 활용해본 언어/프레임워크는 없습니다.
그렇다보니 타 언어의 장점을 직접 경험을 해본바가 없습니다.
저는 그런 타 언어의 장점을 직접 경험을 함으로서 현재 쓰이는 프레임워크에 타 언어의 장점을 적용함으로서 개발의 효율을 높여보고 싶습니다. 이를테면 Ruby on Rails의 Service Layer은 레일즈에서 공식적으로 지원하는 디자인 패턴 계층은 아니지만, 자바의 DI 개념에서 영향을 받은걸로 압니다.
참고 1 : Java&Spring 개발자가 Ruby on Rails 를 해보고 마주친 생각들
참고 2 : Rails Service Layer for Keeping Models Skinny, too!
3. 'xx개발자'가 아닌 '개발자'가 되어라
몇몇 지인분께 사전에 이 글을 공유를 했었는데, 한 지인분이 아래와 같은 말씀을 하셨습니다.
사실 '개발자' 하면 애초에 특정 언어를 불문하고 코딩을 통해 작업을 하는 사람이라는 연상이 되기 마련인데, 저같은 경우에는 '언젠가는 루비 개발자라는 커리어를 버려야 한다.' 라며 이 특정 언어에 한정지은 개발자라고 언급을 했습니다. 사실 되돌이켜보면, 제가 만나본 시니어개발자 분들을 보면 언어를 불문하고 바로 이해하고 개발을 해내는분들이 많았었습니다.
저도 이분의 말에 따라 언어를 불문한 개발자를, 그러니까 낯선 언어를 보더라도 최소한의 지식을 겸비하여 코드를 읽을 수 있는 정도의 개발자 소양을 겸비를 목표로 세우고자 합니다.
글을 막 적은감도 없지않아 있지만, 마음속에 끙끙 앓았던걸 그대로 글로서 풀어봤습니다. 생각보다 썰이 좀 많으면서도 저게 어떻게보면 필자가 해결해 나가야 할 레거시이기도 합니다..
특히 남의 코드를 이해하기 어려워한다는건 개발자에게 있어 치명적인 사항이기도 한데, 이 부분 때문에 사실 저는 1년차 개발자라고 말하기도 부끄러운 상황입니다. 이건 정말 빨리 해결해야 할 과제라고 봅니다.
제 마음 속 옹알이를 이렇게 밝힘으로서, 이 글을 보는 분들에게 있어선 저와같은 전철을 밟지 않길 빌며 글을 마치겠습니다.
