출처 : 구글 이미지 검색
그 동안 테스트코드작성, 코드리뷰를 집중적으로 수행했는데요. 아직은 엔지니어 모두가 걸음마 단계여서 실무리듬에 코드리뷰와 TDD를 끼워넣진 않았습니다. 대신 각자 리서치를 수행하고 매주 수요일 SW 세미나에서 lesson&learn 공유하는 식으로 devops를 공부했습니다.
2주를 되돌아보고 느낌점을 한 문장으로 요약하면 다음과 같습니다.
기술부채의 이자율은 고정 값이 아니다. 시간이 흐를수록 점점 더 높아진다.
코드리뷰부터 말씀드리겠습니다. android와 iOS의 경우 앱 개발기간 3개월 동안 커밋한 어떠한 코드도 리뷰하지 않은 상황이었습니다. devops를 계기로 두 프로젝트 간의 코드리뷰를 드디어 시작했는데요. 방대한 코드를 빠르게 이해하기 위해 코드리뷰에 앞서 시각화된 자료를 준비해 아키텍쳐리뷰부터 수행하였습니다. 아니나 다를까 두 클라이언트의 유저스토리가 완벽하게 똑같음에도 불구하고 클래스 설계며 구현상의 코드며 개발 상의 내용이 완전히 갈라져 있음을 목도했습니다.
출처 : 구글 이미지 검색
iOS, android 환경적 차이로인해 어쩔 수 없이 코드의 다름이 나타나는 경우도 있었지만 대다수의 차이는 코드리뷰를 하지 않아서였습니다. 코드리뷰를 진행하면서 조금 신기했던 사실은 아주 간단한 요구사항(기능)도 개발자 개성에따라 구현법이 각양각생이라는 점입니다. 한 가지 문제에도 다양한 해결법이 존재하는만큼 각 구현법 마다 강점과 약점이 존재하기 때문에 코드리뷰의 필요성이 생각보다 더 크다는 점을 깨달았습니다. 앞으로 클라이언트에는 고도화된 유저스토리가 계속 추가될 예정인데 두 클라이언트간 갈라진 구현상의 설계는 분명히 피처 딜리버리에 병목지점으로 작용될 것입니다. 두 갈래로 나뉜 클라이언트를 어떻게 설계적으로 통합시켜 나갈지 지속적으로 고민해봐야 겠습니다. 또한 더 이상 차이가 벌어지지 않도록 지금부터 추가되는 피쳐들이라도 코드리뷰를 수행하는 환경에서 개발되도록 해야할 의무감도 느꼈습니다.
테스트 코드도 마찬가지로 기술부채가 생각보다 많이 쌓였음을 깨달았습니다. 스위처의 클라이언트의 기술적 난이도는 낮은 편입니다. 그런데 그럼에도 불구하고 기존 코드에 테스트코드를 입혀 SUT로 만드는 일은 여간 까다로운 일이 아니었습니다. 기존 코드는 비즈니스로직과 I/O(DB,Network, BLE), UI 코드간의 커플링이 높아서 막상 어느것 하나 테스트코드를 입히기 쉽지 않았습니다. 테스트코드를 작성하기 위해서는 논리단위의 클래스들을 떼어내는 리팩토링이 병행되어야만 했습니다. 테스트코드 없이 작성한 코드는 시간이 지날 수록 테스트코드가 비집고 들어갈 틈 또한 점점 없애는듯 합니다. 그래도 이러한 현상들은 몸소 체험하면서 확신을 갖게된 사실도 있었습니다.
테스트코드가 존재함으로서 SUT의 설계는 옳은방향으로 향한다.
기존 코드에 테스트코드를 입히려고 이리저리 애쓰다보면 무관한 기능들이 뭉쳐있는 비대한 클래스는 발견하게 됩니다. 테스트코드를 입히기 까다로운 이 거대한 클래스를 쪼개야할 필요성을 느끼게 되는데요. 이 시점에서 개발자는 테스트코드가 있기 전에 절대 하지 않던 리팩토링 고민을 하게 됩니다. 치열하게 고민하는 과정에서 리팩토링에 실패하면 제대로된 테스트코드를 작성하기가 불가능해집니다. 즉, 테스트코드를 작성 했다면 분명히 설계상의 리팩토링이 일어 났을 확률이 높습니다.
스위처 어플리케이션의 내 주변의 스위처 목록 페이지를 예를 들어보겠습니다. 해당 스크린에서는 유저가 여러개의 스위처를 확인하기 때문에 몇 가지 비즈니스 룰에 의해 스위처들의 정렬 순서가 결정됩니다. 그래서 유저는 여러개의 스위처가 검색되어도 내가 가장 사용할 확률이 높은 스위처를 최상단에서 만나는데요. 그 정렬 역할을 맡은 클래스가 switcher sorting(이름이 잘 기억안나네요..) 입니다.
저희 안드로이드 개발자는 이 클래스를 첫 SUT로 만들기로 결정했고 일 주일간 테스트코드를 작성하려고 노력했습니다. 그러나, 생각보다 쉽지 않았습니다. SW세미나때 코드를 리뷰하면서 발견한 사실인데 swithcer sorting는 단순히 비즈니스룰에 사용되는 정보 뿐만 아니라 꽤나 무거운 무거운 switcher 클래스도 의존하고 있었습니다. 정작 sorting 우선순위를 결정하는데 필요한 정보는 switcher 클래스가 갖고있는 정보들 중 극히 일부분이었는데 말이죠. 이렇게 큰 클래스 때문에 테스트 코드를 짜려면 안드로이드 라이브러리인 BluetoothDevice와 Context 인스턴스를 공급하는 목업 클래스가 필요한 상황이 벌어질 수도 있었습니다. 더 큰 문제는 비대한 클래스로 인해서 test의 fixture를 구성하는데 수십 줄의 코드가 필요 했다는 사실입니다. 자연스럽게 테스크코드를 작성하면서 리팩토링의 필요성을 느끼게 되었습니다. 가까운 미래에 스위처 개발자가 성공적으로 switcher sorting 클래스를 SUT로 만들었다면 이 클래스의 설계 또한 분명 리팩토링을 거쳐 더 좋은 방향으로 거듭 났을 것 입니다.
어떠한 일이든 균형이 중요하다고 생각합니다. 마냥 기술부채를 털어낸답시고 리서치와 공부만 하고 있을 수는 없습니다. 동아리가 아닌 회사이기 때문에 시장의 니즈에 맞춰서 분명히 다시 피쳐를 개발하는 속도를 높이는 가속 패달을 밟아야 할 시점이 올 것입니다.
출처 : 구글 이미지 검색
너무 이르지도 않게 그렇다고 너무 느리지도 않게 적절한 시점에 고객이 불만을 터뜨리지 않을 정도의 SW 안정성을 보장하는 최소한의 devops 수준을 달성해야합니다. 어느정도까지가 devops를 도입해야 오버엔지니어링이 아닌 기술부채를 탕감하면서 동시에 I/O 초중기 목표를 달성할 수 있는지 치열하게 고민하고 부딪혀보며 기민하게 대응해야 겠습니다.
앞으로의 2주간 할 일은 다음 질문 두 가지에 대한 대답을 하면서 자연스럽게 도출될 것 같습니다.
#스위쳐 #Switcher #개발 #개발팀 #문제해결 #인사이트 #DevOPS #데브옵스
가입하기
