[생존 매뉴얼] 작동하는 코드보다 더 무서운 건, 작동하는 줄 알고 넘어간 코드다.

오래된 앱을 유지보수 하는 입장에서는 고쳐야 할 곳이 너무 많다.

그 때 그 때 고치고 덧대는 이런 느낌.

 

서드파티 라이브러리는 지원을 하지 않고, View는 아주 오래전에 쓰던 방식이고.

그렇다고 한번에 바꾸는 건 회사에서 허락해주지 않는다. (시간적 비용 등…)

 

결국 조금씩 리팩토링을 해나가는 방법 뿐이지만, 그렇게 되면 사이드 이펙트를 무시할 수 없다.

사소한 로직을 하나 고치고 “에이, 이건 괜찮겠지~” 넘어갔다가 앱을 배포하면

다음 날 엄청난 Crash 지옥을 맛볼 수 있다.

 

코드는 “에러 없이 돌아간다”고 해서 끝난 게 아니다.

“내가 의도한 대로, 모든 케이스에서 정확히 동작한다”는 확신 없이는

결국 폭탄 돌리기일 뿐이다.

---

오류를 줄이는 디테일한 실천 가이드 (생존 매뉴얼)

(1) 작은 수정도 반드시 직접 테스트 한다

사소한 변수명 수정일지라도. 간단한 조건문 변경일지라도.

• 실제 앱 실행 → 해당 기능 사용해보기
• 수정한 조건이 실제로 타는지 로그나 Toast로 확인

(2) 조건 분기문이 있다면, 예외 케이스도 전부 직접 확인한다

코드 수정 후 “정상적인 입력”만 넣어서 테스트하는 것은 ❌

• null
• 빈문자열 “”
• 공백 “ “
• 숫자 0, 음수, 최댓값, 최소값
• 리스트가 비어 있을 때
• API가 실패했을 때

모든 실패의 경우를 생각하여 테스트하고, 예외처리를 강화시켜주어야 한다.

(3) 테스트 코드가 가능하다면 꼭 작성한다

• 함수 단위로 로직 분리해서 테스트 가능한 구조 만들기
• 정상 케이스와 예외 케이스 전부 테스트
• 조건문, 반복문, 분기점 있는 곳은 무조건 테스트 대상

우리 회사 앱들은 다 테스트코드가 없는데… 이게 나의 가장 큰 숙제 😭

(4) 기능 연결된 곳 영향은 없는지 최소한 추적한다

한 줄 바꿨다고 해서 “한 줄짜리 문제” 라고 착각은 금물 !

• 해당 함수/변수가 어디서 호출되는지 Find Usages로 확인
• 관련되는 Composable, ViewModel, API 등 연관된 단위까지 추적
• 기존에 테스트 코드가 있으면 그 테스트도 같이 돌려보기