티스토리 뷰

내가 이끌고 있는 팀이 회사 내 다른 팀에 비해 나이가 어린 편이다. 특히 주니어 개발자들이 가장 많은데, 어떻게 하면 팀 구성원들의 개발 실력을 올릴 수 있을까 하다가 나온 방침은 하루에 한번 리뷰를 하는 것이었다.

많은 블로그 포스트와 컨퍼런스를 다니면서 코드 리뷰라는 행위가 '좋다' 라는 이야기는 많이 들어왔기 때문에 혹시나 '개발 활동에 저해되는 행동이지 않을까?'하는 우려는 잠시 접어두고 강행해보왔다. 내가 팀장이기 때문에 강행하는 것도 있지만, 속내는 잘할 수 있을까 하는 불안한 감정이 있었다. 주니어 개발자들을 데리고 첫 리뷰할 때 들었던 생각은, '이걸 하길 잘했다' 였다.

소스를 확인하고 리펙토링 요소를 도출하고, 이것을 왜 리펙토링을 해야하는 것에 대한 당위성 즉 설명과 곁들어 진행하였는데, 이게 참 좋은 교육 요소가 되는 것 같았다. 특히나, 잘못된 방향으로 개발하는 개발자들도 있었다. 로직을 이해못하고 남이 만든 소스 가져와 그냥 복사&붙여넣기를 한다던지, 소스와 전혀 관계 없는 잘못 작성된 주석(이것도 아마 그냥 붙여넣기해서...), 여러 상황을 염두하지 않고 테스트 하여 에러가 날것이라 예상되는 등...

리뷰를 하면서 도출된 이슈나 문제점에 대해 논의하고 지시하고, 교육하고, 서로 공유하니 첫날 진행 치고는 참 좋았었다.

이제 리뷰를 꼬박 시행한지, 1년 가까이 되었다. 아무것도 모르는 주니어 개발자는 아직도 아무것도 모르는 것 같지만, 소스는 제법 깔끔하고 정형화 되어있다. 자신이 어떤 로직을 어떻게 구성했는지도 이제 알고 있는 것 같다. 실제 교육을 어떻게 할지 애매할 때는 리뷰만큼 좋은 것도 없어 보인다. 그 1년 가까이 진행했던 동안 몇가지 계속되는 포인트들이 있는데 그 사례를 적어보려 한다.

  1. if문 쓸 때 조건문 한번 더 확인 합시다.
         // 이렇게 쓰는 건 뭔가 엘레강스 하지 않다.
         if (!(inputData.dateValue === '')) {}
         // 이게 더 나아 보입니다. (실제 로직도 한번만...)
         if (inputData.dateValue !== '') {}
         // 문자열 빈값 여부를 체크한다면 이게 더 좋다.
         if (!inputData.dateValue) {}
  2. 에러 나면 고칩시다. 에러가 난 소스를 소스 저장소(이하 git)에 올립니다. 자신이 만든 문제는 모두 해결하고 올리는 것이 서로 소스를 가지고 확인할 때 좋다.
  3. Vue에서 HTML Template 부분에 Attribute 값을 부여할 경우 v-bind로 넣는 것이 좋다. 바인딩 되는 값을 Type까지 지정할 수 있기 때문이다. value="true":value="true" 완전히 다르다.
         // value에 '1' 문자열이 들어가게 됩니다. (숫자 아닙니다.)
         <input type="radio" value="1" v-model="picked">
         // value에 'One' 문자열이 들어가게 됩니다.
         <input type="radio" value="One" v-model="picked">
         // 위와 같지만 이것은 문자열 형이라 지정하는 겁니다.
         <input type="radio" :value="'One'" v-model="picked">
         // 이건 문자열이 아닌 숫자형 1로 지정하는 겁니다.
         <input type="radio" :value="1" v-model="picked">
  4. IE11과 친해져라. 테스트는 IE11에서 해야 완료이다.. (대부분 서비스는 IE11을 지원해야 한다. 그 이하도 지원해야 할 경우, 많은 고난이 더 추가 됩니다.) 개발하기 편한 크롬에서만 테스트하고 IE11은 Customer들이 주로 사용하는 브라우져인데 여기서는 안하고...
  5. Java에서 빈 문자열 체크에 equal보다는 StringUtils에 있는 StringUtils.isEmpty()를 사용하자. 전자인 equal은 비교 대상이 문제가 있을 경우 Exception 발생 가능성이 농후하다.
  6. 에러 메시지는 개발자 스럽게 하지 말자. ~은 필수값입니다. 보다 ~을 입력해주세요.라고 메시지를 발생시키자. 개발자들이 자주 잊는 것 중 하나가 자신이 만든 서비스를 자신이 쓰는 것이 아니라는 것이다. 개발 간 Customer 지향 개발을 해야한다.
  7. 복사&붙여넣기는 좋지만, 다른 화면과 다른 기능에서 상관없는 이름이나 명칭을 사용하면 차후 소스 리딩 간 혼돈을 주게 된다. 주석이 없는 개발을 지향하다 보니 함수나 변수명을 지정이 중요하다. 서비스나 화면, 기능을 잘 설명할 수 있는 명칭을 부여해서 작성하자.
  8. 주석을 첨가한다면 제발 개발된 내용에 대한 주석을 달아라. 수정한 이후 주석도 수정하자. 기능을 수정한 후 왜 주석을 수정하지 않을까? 복사 & 붙여넣기도 좋은데 주석을 왜 수정하지 않을까? 잘못된 주석은 차후 소스 리딩 간 혼돈을 넘어서 멘붕을 준다.
  9. Call by Reference의 함정을 조심하자. 메모리에 올라간 인스턴스들은 모두 주소값이 들어있다. 값은 들어있지만, 그 값이 주소값이다.
         // --- html
         <button class="..." @click="upload(list)">조회</button>
         ...
         // -- Vue Data
         data () {
             return {
                 list: []
             }
         }
         ...
         // --- Vue method: upload(targetList), res.T_TABLE에 서버 데이터 조회 내역 저장됨
         upload(targetList) {
             ...
             targetList = res.T_TABLE // 함정
         }
         // 실제 위와 같은 경우 vue data 내 list로 값이 들어가지 않는다.
         // 이걸 이해하지 못하는 당신, 공부하자...
댓글
댓글쓰기 폼