주로하는 업무가 유지보수다보니, 코드를 작성하기보단 작성된 코드가 작동상의 오류를 일으키면 찾아서 수정을 요청하거나, 테스트하거나 하는 일이 많다. 그래서 코드를 설계하고, 작성하는 일이 없다 싶히 하다.

보통 로직을 수정하는 일은 있어도, 설계에 포함되는 코드 작성은 없으니... 

 

회사에 코딩을 할 줄 아는 사람이 나밖에 없기때문에 무언가 피드백을 받거나, 설계를 하거나 할 때 참 아쉽다는 생각을 많이 했다. 

 

피드백이 없을 때 오는 가장 큰 단점은 훨씬 더 많은 시행착오를 겪어야하고, 그에 따른 시간 소모 또한 배로 들어간다.

스스로에게 피드백을 줄 수 있겠지만, 이 것은 스스로의 잘못된 생각을 고착화 시키는 것에 가까웠고, 해결을 더 어렵게 했던것 같다. 결국 더 고집스러운 형태의 프로그램이 만들어지는 결과를 가져왔다고 생각한다.

 

결과적으로 유연하지 못했으며, 변경점에 매우 취약했다. 또한 변수이름, 클래스이름 등 모두 내가 작성한것임에도 다시보면 한참을 봐야하고 딱 한마디로 읽기 싫은 코드다. 무엇인가 변경을 요청하면 한숨부터나오고, 수정을 하기 위해서는 어디를 봐야하며 그 변경점의 영향이 어디까지 미칠지 감이 1도 오지 않았다.

 

요 며칠간 내가 작성했던 프로그램을 수정하고 있다.

월별로 사원들의 휴가사용을 취합하여, 실 근무일수, 근로시간 등을 계산하여 엑셀로 만들어서 매달 회계사무실로 보낸다.

올해 3월에 처음 만들어서 보름정도를 소요한 것 같다. 

 

데이터 원본소스는 "NaverWorkPlace" 플랫폼의 부재항목을 엑셀데이터로 내려 받을 수 있는데, 이 데이터는 조회를 

해당월 1월부터 ~ 말일 까지하더라도, 해당월에 연차신청을 다음달꺼까지하게되면 다른 월까지 함께 조회되어 재가공이 필요했다. 먼저 만들기 전에 네이버에서 이 부분을 수정해준다면, 만들 필요가 없으므로 확인을 해보았는데, 앞으로도 변경할 계획은 없다고 했다.

 

목적은?

1. 네이버워크플레이스에서 얻을 수 있는 "사원의 연차데이터" 엑셀데이터를 읽음

2. 원하는 달의 데이터만 포함되어 계산 -> 엑셀로 다운로드

 

크게 고민했던 부분은?

1. 공휴일, 대체공휴일 데이터를 얻는 부분에 대해서 고민

2. 엑셀원본데이터를 정규화하여, 파싱하는 부분

3. 네이버측에서 원본데이터의 형태를 변경해버려, 수정해야 했던 부분

4. 월이 다른 데이터를 제외시키는 방법

 

리팩토링을 해보자고 결심한 이유?

1. 코드가 수정에 취약한 것은 네이버측에서 원본데이터 형태를 바꿔버렸을 때 느꼈다.

2. 결정적으로 월별로 "실 근무일수"를 추가해달라는 요청을 받고 코드를 살펴보는데 

필요한 코드와 필요없는 코드, 메서드이름, 클래스이름을 보는데 용도를 알 수 없었고, 흐름을 읽을 수 없었던게 충격이였다. 

3. DTO 들의 Data Source 를 구분할 수 없었음

4. Util 클래스와 Static 메서드가 많이 분산되어 있는데 좀 더 한 곳으로 모아야겠다는 생각을 했다

    -> 구현에 대한 생각이 앞서서였는지, DTO 클래스에도 로직을 작성해놓았다.

5. 아예 안쓰는 클래스를 작성해놓았는데, 지워도 되는지 안되는지 분간을 못하고 고민한 부분도 한 몫했다.