진퇴양난 - 지저분한 코드 정리 어찌들 하시나요?

M.W.Park의 이미지

지저분한 코드를 어찌 정리하는 것이 좋을까요?
얼마전 퇴사한 사람의 코드를 잠시 살펴보았는데 개념은 안드로메다에 보낸 후 발가락으로 코딩한 듯합니다.

(참고: 자바이며, 파일 한 개(!) 분석했습니다.)
1. InputStream을 열고 절대 안 닫음.
2. 무조건 null을 반환하는 factory method.
3. @SuppressWarnings를 남발하여 모든 경고 메시지를 제대로 볼 수도 없음.
4. 테스트 코드 없음.
5. 소스 repository를 갈아엎었는지 원래 소스 파일의  history가 사라졌음.

이정도면 거의 테러를 하고 나간 것같은데... 한숨밖에 안 나오는군요. Orz.

ktd2004의 이미지

꼭 정리해야만 하나요? :)

현재 정상적으로 동작하고 있는 코드이면 저는 정리하지 않습니다. :)

정확하게는 정리할 수가 없습니다.

그 이유는 정리했다가 그 부분은 더 깔끔해졌고 동작은 하지만
다른 부분에서 어떤 문제가 발생할지 모르기 때문에

무서워서 정리를 못하겠더군요.. :)

M.W.Park의 이미지

정상적으로 동작하면 제가 왜 소스를 열어봤겠습니까? ㅠ.ㅠ
(게으르기로 따지면, 제가 사내에선 No.1일 겁니다.)

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

rhheo의 이미지

남 일 같지 않아서 안타까울 따름입니다.

전 예전에 이런 일도 있었습니다.

상황:
unit테스트 완료 후 담당 개발자가 한국에 잠시 갔다 온다고 하고 잠적...
핀치맨으로 현장에 투입됬습니다.
신입사원 한명 데리고...

C소스를 내려 받자...
안에는 javascript소스가 들어 있었습니다. T.T

다행히 batch처리였기 때문에
내부 변경이 다른 쪽에 영향을 안끼치는 상황.

일단 회사 이미지를 지키기 위해서 현장 윗 회사에는 비밀로하고...
3일 밤낮 꼴딱 셋었던 기억이 나네요.
이후로 계속해서 발생하는 결합테스트 버그들을 고쳐가면서
완료했었습니다.

인생에서 절대 잊을 수 없는 기억중에 하나였습니다.

현재 하고 있는 작업은 java로 만들어진 업무 로직의 보수 쪽입니다만,
1999년도에 만들어진 코드를 가지고
현재까지 보수해 가면서 쓰여지고 있는 것입니다.
당연히 기이한 형태로 만들어져 있습니다. -.-;;

예로... throw한 Exception을 잡아서 무시하고 넘어갑니다. -.-;; (실제로는 throwable를 잡고 있음...)
상위 클래서에서 정의한 implement할 메소드에 Exception를 못 던지게 선언 되어 있습니다. -.-;;

여튼...
큰 프로젝트에서는 첨에 프레임을 제대로 준비 안하면 관리도 안하면...
그 이후 보수한 결과도 품질이 떨어진 다는 것도 실제로 느껴 보고 있습니다.
손 좀 대볼려고 해도 다른 팀에서 만들고 있는 로직에도 영향이 발생하니깐요.
버젼 업 결정은 윗 회사가 할 일이죠.
1999년도 작품이니깐 어쩔 수 없다라고 위로 하면서 저두 그대로 맞출 수 밖에 없더군요.

일부러 품질을 떨어 뜨렸거나... 못해서 품질이 안 좋거나...
여러사람이 함께 만드는 프로젝트의 경우,
모두가 잘 만들 수는 없기 때문에
직접 만드는 사람의 문제도 있지만...
관리가 제대로 안되고 있다는 가능성도 배제할 수 없습니다.

M.W.Park의 이미지

경험담 감사합니다.

지금 생각은 일단 모듈별로 구분 후에 간단한 독립적인 것들은 아름다운 lisp 쪽으로 빼 버리고(재구현),
뺄 수 없는 것들은 테스트를 붙여서 잘근잘근 씹어 버릴 요량입니다(리팩토링).

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

Darkcircle의 이미지

처리 단위별로 코드를 다닥다닥 붙여서 모읍니다.
가령 문자열을 전부 뒤져서 의미 없는 문자를 소거하고
숫자들만 모아서 다닥다닥 붙이는 동작을 수행한다고 가정할때
단위코드 뭉치 위에 주석을 적당하게 달고
주석표시로 이쁘게 -_- ... 감싸버립니다.

그리고 나서는 그 후에 그 부분이 어떻게 됐건간에
버그가 있는 경우를 제외하고 절대로 건드리지도 거들떠보지도 않습니다.

p.s. 남이 짠 코드라면... 들여쓰기라든지 이런게 제대로 안되어 있거나
의미불분명 혹은 알수 없는 부분에 대해 적어놓지 않았을 경우에는
그 부분에 대해 간략하게 적으라고 시킵(!!)니다.
만약 그 만든 사람 조차도 파악을 못하면 제대로 돌아간다 해도
나중에 소스수정시 파악을 못하기 때문에 그냥 지워버립니다.

---------------------------------------------------------------
실수하지 말아야 하는데 . . . Orz

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

d3m3vilurr의 이미지

객체로 분리가 돼있고 메서드의 반환 결과를 알 수 있다면, 해당 객체를 서브클래싱해서 서브 클래스를 단위테스트를 하시면,
결과적으로 기존 객체를 리팩토링 할 수 있습니다.
........물론 새로 구현하는것에 진배없습니다만(....)

ddoman의 이미지

피곤하게 고치지 마세요.
전 작업자가 해놓은 것 처럼, 뜬 구름 잡기 식으로 어처구니 디버깅을 통해
어케든 겉으로는 돌아가게 만드세요( 급한불만 어케든 끄라는...근본적인 불은 못 잡더라도 )

그리고 코드가 너무 오래되서 유지보수에 어려움이 많고, 기능개선도 힘들다고
새롭게 디자인해서 다시 만들어야한다고..
어케든 설득해서

새로 만드는게 훨 낫습니다.

izeye의 이미지

저도 재개발 요청했다가 리젝당하고

코드 클리닝하다가

다시 재개발 빡빡 우겨서

겨우 재개발하고 있는데

역시나 새로 짜는 게 훨씬 빠릅니다.

유지보수 잘 되어오던 코드면 모르겠는데,

아닌 경우엔 정말 캐난감하더군요.

ssif의 이미지

저랑 비슷한 상황이군요.
한 예로 class 파일은 있는데 java 파일은 없는 경우도 지금 보고 있습니다.
그럭저럭 돌아는 가는게 신기하군요.-_-;

봄들판에서다

봄들판에서다

HotPotato의 이미지

맞아요, 제가 FA일을 하고 있는데, 회사가 자체 패키지 솔루션을 가지고 있어서 그걸 뜯어고쳐서 작업합니다.
몇 년 전의 일이지만 분명히 소스는 없는데 class를 참조해서 돌아가는 게 정말 신기했습니다.
당시는 신입시절이라 파일이 없다고 얘기해줘도 신경안써주는 상사가 원망스러웠습니다.
--
자바가 주로 클래스 단위로 돌다 보니 기능을 세분화 할 수록 계층도 많아지고 파일 관리하기 힘든 것은 사실입니다.
--
내게로~ 와줘~ 와줘!!

--
즐 Tux~

xyhan의 이미지


무능해서라면.. 어쩔수 없다 같이 두번 일하지 말자 라구 생각하세요..

무능과 무책임은 별반 다른 의미를 가지지 않으니... 어찌합니까..

예전 프로젝트에서 5일짜리를 3일 7일짜리를 4일..
이런식으로 일을 시키길래..상호간 협의하에.. 소스 구조는 무시하겠습니다..
이러고 짠적이 있는데.. 저도 남 소스 볼때 마다 욕하지만..
누가 내소스 봐도.. 이해해 달라는 변명밖에는...

저도 일한지 얼마 안됐지만.. 이바닥 사람들 너무 코딩 못해요..

============================================================

선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-

============================================================

============================================================

선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-

============================================================

HotPotato의 이미지

저희는 원 개발자가 이직하면 다른 개발자가 그걸 물려받아서 유지보수하는 입장이기 때문에
당장 돌아가는 것도 중요하지만 타 개발자가 이해할 수 있도록 원래 패턴을 맞춰서 작성해야 합니다.

제가 처음 들어와서 그렇게 배워왔기 때문에 타 사에서 이직해온 개발자가 자기 맘대로 짜 놓은 코드를 보면
울화통이 치밀더군요. 경력자한테 반드시 이렇게 해야 한다라고 강요할 수도 없는 입장이고..

그런 개발자들은 결국은 자기 스타일과 안맞아서 나가더군요.
--
여기에 글을 다른 분들은 어떨까 모르겠는데, 저희는 완전 날코딩입니다. 때로는 RAD 툴을 쏘고 싶지만
그렇게 했다간 쓰레기 코드 때문에 소스관리가 힘들어서 안씁니다. 에디터도 오래된 kawa를 사용합니다.
--
내게로~ 와줘~ 와줘!!

--
즐 Tux~

moonend의 이미지

빌드 파일이 없어서 어디가 어디인지 알 수가 없더군요.
문서따위는 존재하지도 않고...
2달만에 GG쳤습니다.

M.W.Park의 이미지

답변들 모두 감사합니다.

코드 품질을 진즉에 신경 썼어야하는데, 다른 일이 바빠 몇몇 정적 검사 도구 쓰라고 이야기한거 말고는 직접적인 압박(?)을 가하지 않았던 저의 잘못도 있겠지요.
(급하다고 대충 뽑은 사장님의 잘못은 제 잘못의 두배쯤 될거같고요.)

설마 정적 검사 도구가 알려주는 경고 메시지를 @SuppressWarnings로 깔끔하게(?) 없애버렸을 줄은 꿈에도 몰랐습니다. Orz.

일단은 정책적으로 협의할 부분들을 협의 후에, 개발쪽에서는 재개발할 부분과 리팩토링할 부분을 결정해서 지저분하고 또 위험한 코드들을 없애는 방향으로 진행할까합니다.

소중한 경험담들 및 조언들 감사합니다.

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

송지석의 이미지

랩 친구가 subversion 쓰다가 다른 서버에서 잘 안된다고, 새로 커밋하더군요.
그런데 16기가짜리 더미 로그 파일을 커밋 하는 바람에 저장소 업데이트도 안되고..
전 그걸 모르고 있다가, 매일 새벽에 도는 백업 스크립트가 한낮까지 99%점유로 돌고 있더라는.. ㄷㄷㄷ
,,,
깔끔히 저장소를 날려버려야 했습니다. 중요한 저장소가 아니었기에 다행이죠

사전에 교육을 하는게 중요하긴한데
그게 누구 책임이냐도 분명치 않고, 별로 관심도 없어하는 이에게 습득을 기대하기가 힘든 것 같습니다.
예전 회사에서도 버전관리와 subversion 사용법에 대해 세미나 하고 정리한 문서를 날려줘도, 보지 않는 사람이 태반이고 자기 맘대로 쓰다가 저를 부르기 일쑤더라구요. 로그 없이 커밋하는 건 기본이죠. 항상 제가 커밋한 것만 로그가 있어서 그걸 토대로 그 당시의 기억을 더듬으며 그림 맞추듯 추적했습니다.
저도 고수분들 만나면 한없이 작아지지만요 제가 만났던 많은 개발자들, 학력에 상관 없이.. 심지어 컴퓨터공학 전공자들조차도 일정 수준급 이상이 드물었습니다. 성격이 코딩에는 맞지 않을 사람들..
학교에서 코드 같이 짜다보면 indentation 엉망으로 짜고 엉뚱한 설계로 미치게 하는 경우가.. 많다곤 못해도 꽤 있습니다.

"소프트웨어 장인정신"이라는 도서에 보면 소프트웨어 작업은 사람을 때려부어야 소용 없고 소수의 뛰어난 개발자들로 구성된 장인-도제 팀이 훨씬 좋은 품질의 코드를 빠른 시간에 내놓을 수 있다고 하던데. 기계가 짜기 전까진 아마 저런 일들이 비일비재할겁니다.

With lots of love..
Daniel Jiseok Song

BSK의 이미지

유지보수중 소스분석이라고 생각하고 글 씁니다.

1. 일단 소스가 정상적으로 돌아가는지 확인한다. -> 어떻게든 돌아간다. 정신건강상 건드리지 않는다. :)
2. 정상적이지 않다. -> 일단 파급효과를 알아본다(다른 업무와 관련이 있다면)
3. 파급효과가 다른 업무나 팀에게 미치지 않는다
-> 기존 소스를 디버깅작업 하면서 버그를 이 잡듯이 잡아낸다. 그리고 나만의 코딩 기술로 정상(하나하나 구현)으로 만들어낸다.
4. 파급효과가 다른 업무나 팀에게 미친다.
-> 이빨(커뮤니케이션)을 잘 까야 된다.
최대한 문제가 엮여져 있는 부분을 논리적으로 설명하고 같이 해결해야 된다.
5. 도저히 문제를 잡을수 없다. -> 배째라 하고 돌아가는 상황에 스트레스 받지 않고 즐기면 된다.
===================================================
....맑은 정신, 건강한 육체, 넓은 가슴으로 세상과 타협하자.
===================================================

/* ....맑은 정신, 건강한 육체, 넓은 가슴으로 세상과 타협하자. */

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.