JUST DO IT PROJECT

re:View 1st Impact meetup 본문

개발

re:View 1st Impact meetup

웨일.K 2017. 3. 23. 00:55
반응형

re:View 1st Impact


  re:View라는 meet up에 다녀왔다. 생활코딩에서 눈에 띄어 즉흥적으로 신청한 행사. 아직 실무에 들어가보지 않은 입장에서 이런 MEETUP에서는 어떤 이야기가 오가는지 궁금했는데 감사하게도 취준생의 자리를 마련해주셨다. 덕분에 오랜만에 삼성 SDS 향군타워에 방문했다. 사실 장소가 익숙한 곳이라 가야겠다고 결정한 것인지도 모른다. 오랜만의 잠실 나들이. 


 전체적으로 행사는 코드의 품질관리에 대한 내용으로 삼성 SDS의 신상재님께서 주최를 하셨다.  그 방법의 일환으로 개발자로서 코드리뷰에 대한 서지연님의 발표가 있었고, 관리자의 측면에서 플랫폼적인 측면으로 접근하신 김헌기님의 발표가 이어졌다. 이 MEETUP은 단순히 코드 뿐만 아니라 개발과 관련된 모든 생산 산출물의 문서 품질 향상에 관한 것으로 앞으로도 이와 비슷한 맥락을 유지할 것 같았다. 




코드리뷰를 시작하려는 그대에게

-서지연(카카오)

코드 리뷰에 들어가기 앞서 가져야 할 마음가짐과 자세에 대한 개괄적인 발표였다. 현업에서 코드리뷰를 하면서 어떤 어려움을 겪는지, 어떻게 진행되는지, 어떻게 시작하면 좋을지를 위트있게 잘 풀어주신 발표였다. 개발자의 내공이 쌓이는 과정을 엿본 기분도 들었다.


1. WHY? 왜 코드리뷰를 해야하는가? 

 - 코드리뷰는 커뮤니케이션이다.

 - 주니어는 시니어에게 질문할 기회와, 실제 코드를 보고 배울 수 있는 기회를 얻고,

 - 시니어는 주니어를 자연스럽게 교육하며 새로운 방법을 발견하는 기회를 얻는다.

 - 부끄러움은 잠시뿐이지만 나의 코드 히스토리를 탄탄히 쌓을 수 있고,

 - 확실히 장애요소가 줄어든다.

 

2. HOW? 코드리뷰를 어떻게 해야 하는가?

1) 어투

 - 친절하되 구체적이고 자세한 질문/피드백

 - 코드 리뷰는 커뮤니케이션. 상처 주지 않도록 유의.

2) 피드백 범위, 유도리(?)

 - 모든 리뷰에 피드백을 해야한다는 강박은 NONO

 - 구조적인 리뷰는 나중으로 미룰 필요도 있다.

3) 내 의견을 가져라

 - 협업을 위한 가이드라인을 가지고 따르는 것은 중요.

 - BUT 리뷰대로 모든 것을 바꿀 필요는 없다. 

 - 결국 내 코드는 내가 가장 잘 안다.

4) 리더

 - 바빠서 자칫 잊혀지기 쉬운 코드리뷰

 - 상기시켜줄 리더가 필요하다.

5) 공감의 중요성

 - 포상제, 강제적인 규칙은 오래가지 못한다.

 - 직접 코드리뷰의 효과를 보고, 진짜로 배웠다고 생각할 때 자발적 참여가 늘어난다.


3. 장단점

1) 장점

 - 신규 개발자에게 베이스코드를 알려주기 용이하다.

 - 내가 휴가 가도 내 코드의 리뷰어들이 남아있다.

 - 내공이 쌓인다.

2) 단점

 - 가끔 억울할 수 있다. (내가 짠 코드 아닌데...)

 - 코드리뷰 부분이 아닌 곳에서 드러나는 문제점을 마주하게 될 때가 있다. 당장 고칠 수 없는 문제, 언젠가는 고쳐야 할 문제를 발견.


4. 마무리

 - 코드 리뷰에서 적절한 도구의 사용은 필수

 - 코드리뷰는 곧 문화이다. 

 - 직접 겪어보고 함께 한 사람들끼리 공감대가 형성되면 문화는 유지될 수 있다.




코드품질개선을 위한 GSSHOP 고군분투기

김헌기(GSSHOP)

현업에서 관리자로서 코드 품질을 높이기 위해 어떤 시도를 했는지 차근차근 알려주셨다. 엔터프라이즈에서 흔히 일어나는 맘모스 코드들의 문제를 해결하고자 한발 한발 나아가는 시도가 인상깊었다. 앞서 서지연님의 발표가 이제 시작하는 사람들을 위한 접근이었다면, 김헌기님의 발표는 이미 고착화된 문제들을 해결하려는 느낌이었다. 


1. 배경

1) 관리자의 역할 변화

 - 과거의 관리자는 관리만 했다.

 - 현재의 관리자는 코드로 이야기해야 한다.

2) 엔터프라이즈의 흔한 legacy코드 문제

 - 4만줄 짜리 java 파일.

 - 인자 20개 method

 - 이는 기술부채이다.


2. 선순환 구조의 필요성

 - 측정가능하고, 투명한 품질활동이 필요하다.

 - 코드품질을 투명하게 확인 가능한 플랫폼의 개발. 


3. 배포 품질 활동 타운

 - 리더, 엔지니어, 테스트 전문가, 보안 전문가로 구성

 - 수평적 문화를 위한 닉네임 도입

 - 프로세스 도입

 - 프로세스와 플랫폼만으로는 부족하다.


4. 코드리뷰 운동 "래프팅"

1) 목적 및 가치 

 - 적은 인원이 모여 코드 다이어트

 - 목적: 유지보수가능한 코드

 - 가치: 코드 리팩토링 가이드

2) Communication

 - 한 달 안에 할 일들을 한 주단위로 가시적으로 나열

 - 한 주가 끝나면 결과보고. 

 - 플랜B가 필요한지 판단 후 반복

3) 안개 속처럼 막막할 땐

 - Design Thinking

 - 생각나는 것들을 모으고, 분류하는 과정.

 - 점에서 선으로 나아갈 방향 제시.



오늘 Meetup에서는 현업에 종사하시는 분들이 가지고 있는 고민을 함께 나누고 있는 기분이 들었다. 곧 내가 하게 될 고민들일 것이다. 개발자로 살아간다는 것은 결국 끝없는 자기계발의 과정일텐데 어떤 문화와 어떤 환경에서 지내는지에 따라 개발자로서 지속적으로 성장할 수도, 정체되어 끙끙 앓을 수 도 있겠다는 생각이 든다. 

연사 두 분 모두 코드리뷰는 문화이고 의사소통이라는 결론을 내리셨다. 과연 이 문화가 정착되기까지 얼마나 많은 시간과 노력과 고민이 있을지 모르겠으나, 이 문화를 잘 정착시킨 곳에서 분명 미래의 장인(!)들이 나오게 되리라 믿어의심치 않는다. 나도 그 중 하나가 되길 바라본다.



+ re:View meetup 블로그 바로가기

반응형