예전분이 짜둔 코드 바꾸는데 고민있어요.

Question

SI 온지 2달된 신입입니다. APIM쪽을 맡아서 하고 있는데요. 예전에 계시던 고급개발자분께서 인코딩 디코딩 메서드를 만들어놔서 그걸 쓰고 있었는데요. 가시고 나서 코드를 뜯어보는데 문제가 있어보여서 바꾸고 싶은데 고민이 있습니다.1번째는 인디코딩 메서드가 파라미터가 다 String입니다.public static String convert(String colNm, String value, String convertType, String convertTargetEnum)convertType이 E면 인코딩, D면 디코딩이고, 인디코딩 대상이 되는 enum을 찾는것도 String으로 찾고, enum안에 대상이 되는 column이름도 String으로 찾습니다. 제가 보기엔 colNm과 convertTargetEnum은 String으로 하면 변경사항이 있을때 유지보수도 어렵고 파라미터값이 오타가 나도 찾기 어려울수도 있어보여요.2번째 이 인디코딩메서드가 전역으로 많이 쓰이고 있습니다.이미 4개의 프로젝트에서 이 메서드가 들어있는 클래스가 있고, 많이 사용되고 있습니다. 그래서 이걸 바꾸면 API쪽은 싹 다 바꾸는거라 힘들어서, 기존에 내부구조만 리팩토링하고 기존 메서드는 오버로딩시켜놓고, 새로 메서드를 만들었는데요. 앞으로 이거 쓰라고 하면 괜찮을까요? 아니면 다른사람들한테 혼선을 주니까 내버려둘까요? 3번째 인디코딩 후처리 방법이 서로 다릅니다.문서에 데이터샘플 넣을때 한글이 디코딩이 제대로 안됐었던 문제가 있었는데요. 그 분 가고나서 보니까 이것도 문제가 있더라구요. 그동안 APIM문서 작업할때 oracle에서 base64인디코딩을 하고 후처리로 ksc5601로 변환시켜서 샘플을 넣었었어요. 근데 자바 메서드 보니까 인코딩후처리는 UTF-8로 하고, 디코딩은 그냥 base64디코딩만 시키고 더 없더라구요. 디코딩은 어차피 스프링 내에서만 쓰니까 후처리만 추가해주면 되는데, 인코딩을 고치면 리턴값이 달라져서(API가 인코딩된 값을 return해서) 그동안 작성했던 문서들에 있는 데이터샘플들을 다 바꿔야되더라구요. 근데 그 문서가 양이 100개가 넘어가서 바꿔야 될게 너무 많습니다. 이걸 놔두면 서비스할때 다른 팀에서는 인풋값을 ksc5601로 인코딩시킨걸 주고, 리턴을 utf-8방식으로 받으니까 당연히 문제 생길것 같은데 어떻게 해야될까요.

개발정복 · Accepted Answer

내부적으로 바꾸는걸 추천합니다.아니면 전역메서드는 deprecated 시키시고 새 함수 만든걸 쓰라고 하시던가요내부적으로는 전역메서드 안에를 새 함수로 보내주시면 좋을거 같구요3번은 사양 확인이 우선일거 같네요 구현자체가 잘못된거면 그걸 알리고 고쳐야죠눈에 뻔히 보이는 작업에 대해서 개선 가능한건 우선적으로 해야죠

yeori · Answer

근데 왜 고치시나요?

하루히즘 · Answer

기능변경 영향이 크다면 저는 v2 api 같은걸 만들어서 점진적으로 바꿔나가는 편입니다

정현맨 · Answer

첫번째 - 파라미터 스트링으로 다 때려박는것은 좀 많이 아찔하네요 ㅎㅎ;

엡실론 · Answer

1번은 고치는 게 좋아 보입니다. 특히 enum 부분은요.3번은 무슨 상황인지 정확하게 이해가 안되네요. 무엇을 무엇으로 인코딩하고, 후처리는 누가 무슨 후처리를 한다는 건지.팀에 제안 해 보세요. 저럴 수 밖에 없던 이유가 있을 수도 있고, 바꾸고 싶었는데 시간이 없어서 못 했을 수도 있고요. 그게 아니더라도 공통 함수이고, 함수 시그니처와 동작에 변화가 생길텐데, 다른 사람들도 다들 알아야죠.뭐가 됐든 설령 신입의 눈에라도 뭔가 이상해 보인다면, 어딘가 고칠 부분이 있다는 뜻입니다. 코드를 고치든, 코드를 못 고친다면 왜 그런지 문서라도 남기든, 어딘가 개선할 부분이 있다는 거죠. 아마 비슷한 의문을 가진 사람이 글쓴분이 처음도 아니고 마지막도 아닐겁니다.

천사와악마 · Answer

몇가지 전제와 제약이 생길것 같아요모든 변경은 상급자 컨펌 및 이력을 관리하세요 - 꼰대같아도 신입이 공통단 건든다고 하면 보수적으로 접근할겁니다 영향도 파악 안됐는데 손대면 큰일나유누군가의 지시가 아닌 리팩토링 용도로 개발은 내가 책임진단 생각하셔야해요 총대맨다고 합니다 잘돌고 있는데 수정하시려면 신중하게 접근하셔야 합니다 잘되야 본전 못되면 욕만 먹어요

vollfeed · Answer

1은 문제가 안됩니다. 정 걱정되면 함수내부에서 예외를 발생시켜서 방어하면됩니다. 우아한 해법은 아니지만 튼튼한 해법입니다2 내부 리팩토링만 했다면, 쓰라고 할 이유도 없는거죠. 일단 인터페이스가 변경되면 새로운 함수지 내부 리팩토링이 아닙니다. 당연히 혼선은 불을 보듯 뻔한데, 그럴 가치가 있나를 따져보면 됩니다. (개인적 의견으로는 1은 이유가 안되고, 3은 됩니다) 3 이건 코딩 문제가 아닌데요?설계 및 데이터에 대한 사양 변경인데요?이거 오피셜한 작업 맞는거죠?그럼 혼자 결정할 이유가 없을 텐데요?

장독깨기 · Answer

두 달 된 신입이 뭐 하러 나서려고 합니까. ㅎㅎㅎ문제 있어 보이면 앞으로 저런 걸 잘 고려해서 프로그래밍 하면 될 일 입니다.3번은 잘 이해는 안되지만, 어쨌든 문제가 발생하면 다른 분하고 협의해서 하면 될 일 이구요.제가 볼 때 크게 중요한 일 아닙니다. 다른 일 찾아 열심히 하는 게 좋겠습니다. :)

mirheeoj · Answer

불합리한 코드, 문제있는 코드는 고치는게 궁극적으론 맞습니다. 하지만 일은 결국 중요도와 우선순위에 따라 해야 합니다. 해당 코드가 중대한 기능제한을 낳는다든지 보안위협 등을 만들어내지 않는 한에는 저라면 리포팅만 하고 우선순위 조절은 프로젝트 관리자에게 맡길 것 같네요. 팀 동의없이 임의로 나섰다가 일정에 차질을 빚거나 기존 기능에 문제라도 생기면 꽤 귀찮아질 겁니다. 본인이 불편한 부분은 본인 코드에서 고치면 문제없겠죠. 헬퍼 클래스를 만들든지 해서요. C#이면 익스텐션도 가능할 것이고.

개발새발 · Answer

일단 테스트를 붙이세요.

예전분이 짜둔 코드 바꾸는데 고민있어요.

10개의 답변

기타 목록