강의 개요
수동적으로 강의만 수강한는것이 아닌 총 4~5개의 Step 으로 구성된 과제를 수행하며 수강생은 과제 완료를 알리는 PR 을 리뷰어 에게 요청을 보내며 코드리뷰를 받게 된다. 리뷰어는 Nextstep 의 대표이자 우아한테크코스를 이끌어 나가고 있는 자바지기 박재성 님께서 과정을 모두 수강하였으며 그중 실력이 우수한 수강생을 선별하여 수강생들의 코드를 리뷰하고 있다. (그중 네카라쿠배 현업인의 비중이 상당히 높은거같다)
상세내용
나는 왜 80만원이나 되는 이 강의를 수강했는가?
나는 이전 회사에서 BtoC 대고객 서비스인 KT 채팅상담 서비스 운영RP 업무와 마이현대 카케어 서비스인 카라이프 중계 플랫폼을 운영 및 개발 업무를 담당하였다. 대고객 서비스 특성상 코드 수정과 개발되어있는 기능에 추가되어야 하는 파생되는 기능추가 요구 조건이 자주 들어왔다. 특히나 KT 같은 경우에는 매 달마다 구현해야 하는 기능을 정해놓고 스프린트식 개발방식으로 기능을 구현해 나가야 했다.
문제
- 히스토리 없는 코드수정
필자는 KT 프로젝트를 담당하며 아래와 같은 코드를 정말정말 많이 보았다. 아니 거의 모든 코드가 아래와 같이 작성되어있었다.
if(counselType.equals("L")) {
...
} if else (counselType.equals("K")) {
...
} else {
...
}
위와같은 코드는 정말이지 초기 구축인력이 아니라면 L 과 K 가 무엇을 의미 하는지 인수인계가 없다면 절대로 알 수 없을 뿐더러 인수인계라는것이 저러한 세세한부분까지 이뤄지는 경우가 드물었다. 물론 인수인계가 있다라고 할지라도 위와같은 코드는 객체지향적으로 좋지 못한 설계이다
1주차 강의를 인용하자면
객체에 값을 직접 주입하며 (미리 객체가 갖고 있는 값을 개발자가 알고있는 상태) 특정 결과값을 도출하여선 안된다.
이는 마치 자판기에서 데미소다를 뽑아먹고 싶은데 버튼만 누르면 될일을 직접 데미소다를 타이핑 해야 뽑아먹을 수 있게 설계 했다는 소리랑 같다. 고객이 데미소다 라는 음료 이름을 모른다? 그럼 뽑아먹지 못한다.
위 코드에서 counselType 이 L K 뿐만 아니라 G H 도 온다는걸 우린 저 코드만 보고 절대 알 수 없다.
위와같은 코드는 아래와 같이 수정되어야 옳바르다.
if(counselType.isLeaderRequest()) {
return ...
}
if(counselType.isKakaoRequest()) {
return ...
}
return ...
}위와같이 코드가 작성되어있을경우 인수인계를 안받아도 초기 개발자가 아니더라고 L 이 뭔지 K 가 뭔지 발로 뛰지 않아도 된다.
- 엄청난 양의 레거시 코드
필자는 자꾸 KT 를 언급하고 있지만 KT 에서 관리 하고있는 애플리케이션에 대해 느낀것이 정말 많다. 구축 시간의 부족함과 노련한 개발자 투입 부재에 따라 코드가 작성되다 보니 조건만 마주 치면 if indent 가 하나씩 들어간 코드를 너무나도 많이 봐왔다
ex)
if(msg.contains("상담원이 상담을 종료하기를....blah blah")) {
if(counselQueue < 10) {
msg = "";
msg += "곧 상담이 진행될 예정....blahblah"
if(....) {
msg += "...blah blah";
}
}
}위와같은 코드에서 (실제로 7 ~8 depth 까지 들어간 케이스도 많다) 예시를 들기위해 많이 줄였지만, 이때 위 스스템에 대한 핸들링 기간이 오래 되지 않았을경우 클라이언트 측으로 부터 ~~ 일때는 인사말을 ~~ 로 보내주세요 라는 요구조건이 들어온다면 정말 단순한 개발 요청에도 신속한 개발이 이뤄지기 어렵다.
필자가 추구 하는 위 문제의 해결방안 및 수강 이유
흔히 SI 회사에 만연하게 깔려있는 분위기는 일단 빨리빨리 이다. 위 코드들도 개발자들의 역량을 욕하는것이 절대 아니라 그들도 서비스 구축시 시간이 매우 촉박했을것이라 확신한다. 하여 필자는 촉박한 시간이 주어지더라도 클린코드와 TDD 에 대한 개발 프로토콜을 놓지 않고 개발할 수 있는 역량을 기르려 한다.
흔히 리펙터링과 TDD 클린코드를 적용했을때 성능상의 이점을 가져 오는가? 그런 경우도 있을 수 있겠지만 클린코드로의 리펙터링은 동일하게 동작하는것이 목적이지 성능개선의 목적이 아니다 때로는 메서드 분리원칙으로 인해 반복문이 한번 더 돌 수 도 있다.
하지만 TDD 와 클린코드로 적용했을때 어마어마하게 아껴지는 부분이 존재한다고 믿는다. 그것은 인건비 이다.
- 임의의 String Type "L" 이 뭔지 "K" 가뭔지 찾으러 고액연봉자가 발로 뛰고 있다면
- 결합도 높은 클래스 설계로 인해 하나의 수정이 여러 기능에 영향을 끼치고 있다면
- 배포후 예상치 못한 장애로 인해 야간 긴급배포가 이뤄진다면
위와같은 모든 상황이 전부 인건비 낭비 로 연결되게 된다.
하여 필자는 위와같은 상황을 예방하고자 레거시 코드에 대한 분할로직 작성 역할분리에 따른 테스트 코드 작성
가능상태로의 전환등과 같은 역량을 이번 기회에 확실히 길러 위 문제들을 해결해 나가려 한다.
ps. 해당 과정에 대해 같이 읽으면 하는 추천 도서가 있어 아래 책과 같이 해당 과정을 진행하려고 한다.
