개발을 하다보면 좋은 방법론들이 많이 있다.
그리고 그 방법론들을 많이 알고 잘 알수록 무엇이 현재 상황이 맞는지 판단할 수 있다고 생각한다. (나도 잘 알고싶다)
우리는 항상 기술부채와 싸운다. 나도 현업에서 어마어마한 기술부채와 함께 하고 있다.(물론 나도 생산중이겠지)
개발자가 아닌 회사 팀원들은 기술부채라는 단어에 크게 공감하거나 동의하지 않을 수 있다.
매일 이래도 되나 하면서 움직이는 하울의 성에 방 하나를 올린적이 허다하다
그렇게 점점 커져가는 죄책감과 밀려드는 기술개발 일정사이에서 딜레마에 항상 빠지곤 한다.
이대로 가선 안돼..! 이러다 다 죽어 !
할 것 같지만 용케 무너지지 않고 꾸역꾸역 서버에서 이쁜 옷 입고 숨 쉬고 있는 코드들.
이것들은 기술부채인가? 그럼 기술부채가 없는 프로젝트가 있을까?
그때는 맞고 지금은 틀리다를 시전하는 나를 보면서 꽤나 속이 울렁거렸던적도 많다.
그때는 그때의 개발일정과 구현해내야만 하는 사명감이 있었고
그것들은 소비자와 만나 가치를 생산해내고 있다.
그럼 그것들은 기술부채가 아니라 기술투자가 아니냐는 구절을 책에서 읽었고 머리가 띵했다.
그렇다 그건 부채가 아니라 투자였고 그만큼의 효용이 있었다면 그게 맞는 기술이라는 것이다.
다만 이렇게 만들어낸 결과물들을 확장해 낼 수 없다면
그때부터 부채라고 불리울 것이다.
나는 이러한 간극을 최소화 하고 싶었다.
그 중에서 하나의 방법론을 도입하고 있다.
Adopter Pattern
채팅개발을 하던 중 시안과는 다른 요구사항이 추가로 떨어 졌다.
차트를 넣어주세요 테이블을 넣어주세요
정말 생각지도 못했던 요구고 백엔드 측에서도 테이블을 다시 갈아 엎어야 되는 상황이 왔다
갈아 엎지 않으려면 기존에 있던 필드 아래로 줄줄이 다른 성격의 필드들을 추가하는 방법뿐,, 나중에 되면 다시 리팩토링을 하겠지만 또 영원히 바뀌지 않을 수도 있다
그리고 그 변화에 대응하다보면
내가 짠 코드들은 점점 추가되는 기능들 속에서 처음 의도했던 것과는 다르게 뒤죽박죽 코드가 작성 돼 있을 수 있다.