현재 장비 업계에 종사하고 있는 개발자입니다.
장비 업계에 있다가 웹에서 챗봇 개발하고 다시 장비 업계로 돌아오게 됬습니다.
회사에서 스테디 셀러로 출하하고 잇는 장비가 잇는데 너무 스파게티 코드입니다…
대충 줄을 환산해보니 10만줄에 가까운 코드들인데,
결합성 및 의존성 개나줘버리고 그떄그떄 때우기 바쁘게 만든 코드들이
파악을 어렵게 하고 난해하기 그지 없네요.
리펙토링이 필요한건 보여서 장비를 직접 구동해보면서 먼저 코드를 파악하고 있습니다. 출장과 지원 업무가 오지 않는 한 고쳐보고 싶은데 다른 분들은 어떻게 이런 문제를 해결하셨나요?
먼저 웹에서 썻던 windsurf 랑 coursor 총 동원해서 흐름도 파악하고 코드하나하나 돌려보고 어떻게 수정할지 AI 랑 논의해보고, 글들을 찾아보는데 직접적인 경험담을 들어본적이 없네요.
리펙토링 경험은 챗봇 프로그램에서 간단히만 진행해봐서 궁금합니다…
말씀해주신 상황으로 볼 때, AI 만으로는 커버가 어렵습니다. 전통적인 리팩토링 기법과 역량이 뒷받침이 되고, AI가 보조하는 형태가 가장 바람직하다고 생각하는데요,
기존에 코드가 어떻게 구성되어있는지 알 수 없는 상황에서 추정으로 답변을 드려보자면, 아래 상황들이 예상됩니다.
기존 코드가 어떻게 생겼고 어떻게 돌아가는지를 최대한 분석해본 다음, 어느 정도 윤곽이 그려지신다면 그 후부터는 본격적으로 단일 책임 원칙 (SRP)에 입각해서 여러 역할이 병합된 함수, 모듈, 클래스 등을 분리하는 것을 시작으로 점진적으로 기존 코드를 리팩토링하고, 외부와 통신하는 지점에서는 파라미터, 실행 호출 선후 조건 등의 호환성을 유지하면서 점진적으로 내부 코드 구조를 개선하는 형태로 리팩토링을 조금씩 진행하는 과정을 거치셔야 할 것으로 보입니다.
부족하게 썻던 내용이지만 핵심을 잘 짚어주셨습니다!
읽고 댓글을 쓰면서도 놀라네요…
LLM 으로 코드 분석은 많이 해봤는데, 시각화하면서 본다는 구상은 못해봤습니다.
이번에 머메이드 그래프도 써본적이 있었는데 생각을 못했네요. 바로 해봐야 겠습니다.
사실 SRP로 제대로 해봤다는 적이 없어서 일단 반복 구문 및 난잡한 변수명 수정, 안쓰거나 무의미한 플래그 수정부터 차근차근 다이어트 시도해볼려고 합니다.
좋은 말씀 감사합니다!
이론은 그러할 진데, 실제로는 건드리지 않는 것이 현명합니다. 어느 정도 규모의 장비인지는 모르나 10만줄이면 많이도 욹궈먹은 것 같은데, 그 중에는 버그 때문에 정상동작하는 것도 있을 정도로 보입니다.
정확한 전후 사정을 모르는 상황에서의 수정으로 인해 피해가 발생할 경우 혼자 감당할 수 있는 것인지 부터 생각해보시고 접근하는 것이 좋습니다.
회사 차원에서 잡이 주어진 것이면 문서화를 잘 해 놓으시면 되고요.
@디노티아 님께서 잘 이야기해주신 것처럼, 단순히 리팩토링을 하는 것과는 별개로 기존에 배포했던 펌웨어들을 어떻게 순차적으로 업그레이드하여 배포할 것인지, 기존 펌웨어들의 지원 중단 주기를 어떻게 설정하고 관리할 것인지 등을 세심하게 살펴야 해서 혼자서 하실 일의 범위는 크게 벗어날 수 있습니다.
저도 리팩토링 환자 중에 한 명인데…
10만 줄 이면… 저는 안 건드릴 거 같슴다… -ㅁ-;;
리팩토링은 코드를 건드리는 작업이지만
건드린 코드가 기존 동작(기획에 정의된)과 온전히 동일하게 동작해야하므로
대부분의 리팩토링이 완성 혹은 성공하려면 반드시 전체 테스트를 통과해야하죠.
하지만…
고치는 코드가 10만줄 어디에 영향을 줄지 확신할 수 없다면 결국 테스트를 통해 보장받아야하는데
그거는 그거 나름대로… 어휴… =ㅅ=;;
만약 부분부분 모듈화 할 수 있고 관련 기능에 대한 기획서가 명확하고 테스트 루틴을 포함한 QA/QC 가 보장된다면
저 같으면 기존 코드 안 건드리고 그 모듈만 새로 만드는 방식으로 하나씩 고쳐 나갈거 같네요.
실제로 그렇게 한 적도 몇 번 있구요…(하지만 결국 퇴사 엔딩ㅋ)