일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Observable
- Koin
- liveData
- node.js
- node
- Kotlin
- PagingLib
- android13
- Reactive
- 동영상
- MediaSession
- SwiftUI Tutorial
- databinding
- junit
- mysql
- Animation
- 테스트 자동화
- MediaPlayer
- RxKotlin
- google play
- Android 13
- paging
- Android
- MotionLayout
- rx
- SWIFTUI
- 인앱결제
- GCP
- list
- mvvm
- Today
- Total
봄날은 갔다. 이제 그 정신으로 공부하자
사용되지 않는 소스 코드 처리 본문
개발을 하다보면 힘들게 개발했는데 기능 변경 또는 시나리오의 변경으로 사용되지 않는 소스 코드가 다수 생기곤 합니다.
이럴때 어떻게 하시나요?
- 1번 과감하게 삭제한다.
- 2번 삭제하는건 쫄리니까 우선 남겨놓고 나중에 기회가 될때 삭제한다. (실제로는 절대 삭제 안함.)
1번을 선택하는 경우도 있겠지만 대부분 2번을 선택할 것으로 생각됩니다.
저같은 경우 1번을 선택해서 과감하게 소스 코드를 삭제했다가 다시 시나리오가 변경되면서 그 삭제했던 코드가 다시 필요해져서 복구하는데 꽤 고생했던 기억이 종종 있습니다.
그렇다보니 사용되지 않는 소스코드라도 삭제하기 보다는 이후 어떻게 될지 모르는 재사용 시점을 기다리면서 일단 내버려두는 편입니다.
이런 코드가 한두개씩 꾸준히 쌓여 점점 프로젝트의 코드 가독성을 떨어뜨리는 문제가 발생합니다.
가비지 코드가 쌓여 코드 가독성을 떨어뜨리는 문제를 별로 심각한 문제라고 생각하지 않을 수 있지만 의외로 심각한 문제 입니다.
가독성이 떨어지는 문제는 코드 유지보수의 효율성을 떨어뜨리고 가비지 코드가 의도치 않은 사이드 이펙트를 발생시키기 때문 입니다.
개발자는 이 코드가 더이상 사용되지 않는다고 판단하지만 실제로는 다른 코드와 연결되어 있는 경우도 있기 때문 입니다.
개발기간이 길어지고 시나리오가 몇번 변경되고 코드가 복잡해지다보면 개발자는 자신이 개발한 코드에 대한 장악력이 점점 떨어지게 됩니다. 이럴때 의도치 않게 코드 가독성이 떨어지면서 더이상 사용되지 않는다고 판단한 코드가 실제로는 사용되고 있었고 그렇게 기억속으로 사라진 코드가 나중에 명치를 쎄게 때리는 경우가 발생합니다.
다시 말씀드리면 저는 사실 사용되지 않는 소스 코드(가비지 코드)는 과감하게 삭제하는 편 입니다.
이유는 코드 장악력 유지 때문 입니다.
또하나의 이유는 실제 사용되는지 안되는지는 코드를 삭제해봐야 확실히 알 수 있기 때문 입니다.
그럼 삭제한 코드가 다시 사용될 때에 대한 대처는 어떻게 하느냐?
형상 관리툴(Git, GitHub, BitBucket, …)을 적극 활용합니다.
git commit 시점을 의미 있는 작업 단위(기능별 완료, …)로 나누어 최소 1주일에 3번 이상 업데이트 하면서 commit message를 정성스럽게 작성해줌으로써 나중에 삭제되는 코드를 쉽게 찾을 수 있도록 합니다. 또한 git flow 전략에 따라 branch를 관리합니다.
코드 재사용이 필요한 경우는 크게 두가지 일 것입니다.
첫번째는 기존 폐기되었던 시나리오가 다시 살아나는 경우이고, 두번째는 폐기 되었던 시나리오와 비슷한 시나리오가 생기는 경우 입니다.
첫번째 경우는 거의 없고 두번째 경우가 대부분일 것 입니다.
그렇다 보니 실제로 남겨두었던 가비지 코드가 더 위험한 경우가 많습니다.
기억에서도 가물가물한 코드를 가지고 뚝딱 뚝딱 수정하고 예전에 테스트 다 했으니 문제 없겠지하고 넘어가면 명치 쎄게 맞습니다.
폐기 되었던 시나리오와 비슷한 시나리오가 생기는 경우,
UI를 포함한 Business logic이 유사한 경우도 있지만(이때는 Git History를 찾아서 이전 코드를 다시 복구 시키는게 더 유리합니다.)
시나리오는 전혀 다르지만 예전에 개발했다 폐기한 custom controller 또는 custom class가 필요한 경우도 있습니다.
솔직히 이 경우 때문에 아까워서 코드를 못 지운 경우가 몇번 있습니다. ㅠ_ㅠ
이런 경우에 저는 프로젝트를 진행하면서 개발된 custom controller 또는 custom class에 대해 최소 샘플로 별도의 앱으로 만들어 보관하는 것을 추천 드립니다.
이때 최소 샘플 앱이 아닌 Git Flow 전략에 따라 프로젝트의 별도의 branch로 관리해도 됩니다.
custom controller 또는 custom class들은 개발자가 개발하면서 습득한 중요한 지식이고 그러한 것 들은 해당 프로젝트에서 뿐만이 아니라 나중에도 유효하기 때문 입니다.
정리
사용되지 않는 가비지 코드는 과감히 삭제하는 것이 좋습니다.
하지만 대책없이 가비지 코드를 삭제하기에 앞서 아래와 같은 대책을 마련해 놓아야 합니다.
- Git Flow 도입, 꾸준 & 성실한 Commit 메시지 작성
- custom controller 또는 custom class는 최소 샘플 앱으로 별도 제작
'잡썰' 카테고리의 다른 글
애자일 방법론에서 개발은 MVVM 구조로 개발하는 것이 적절한가? (0) | 2022.12.20 |
---|---|
NFC vs RFID 차이점 설명 (0) | 2020.12.24 |
낡아버린 박스처럼 이제는 추억이되어 버린 Release빌드 (0) | 2020.11.27 |