안녕하세요 아즈라엘 입니다.
현재 제가 프로젝트 막바지에 있는데 현 소스를 보면 아주 창피합니다.
여러분들은 리페토링 하십니까?
전 아래와 같이 일한답니다.
1. 여기저기 Activity 클래스 안에 같은 내용의 method 들이 아주 많이 존재한다.
--> 일단 테스트 코드를 만들고 적용해야 했지만 한개의 액티비티안에서 기능을 추가하고 돌려본다음 괜찮다 싶어 다른곳에도
copy & paste 를 하였습니다.
결국 파라미터 하나 고치기 위해서 여러 Activity.java 파일을 돌아다니며 고쳐야 하는 번거로움과
코드라인이 길어져서 폭이 늘어나 스크롤을 자주 해야 하며 한눈에 들어오지도 않아 가독성도 떨어지는 ....
2. 귀찮아서 변수명을 대충 만들었습니다.
--> 일단 temp 로 시작하여 이래 쓰고 저래 쓰고 하다가 그 코드가 그대로 굳어 버렸습니다.
나중에 temp 가 temp 가 아닌 겪이 되었고 이로 인해 코드의 가독성은 더더욱 ....
path1 , path2 는 실제 데이터가 바인딩 되어야 알 수 있는 이름이 되어 버렸습니다.
변수명을 작문하는게 너무 어렵네요.. 영단어 기역이 가물해서 인터넷으로 사전 뒤지다
대충 대충 만든게 한두개가 아닙니다.
3. method 에 넘겨줄 인자값을 귀찮아서 전역변수 처리 하였습니다.
--> method 에서 주고 받고 사용되어야 할 인자값들이 여기저기 써야 한다는 이유로
전역변수로 처리 하였습니다. 처음엔 아주 편했지만 시간이 지날 수록 전역변수를 초기화 해서 사용해야 되고
이로 인해서 다른쪽 메서드(기능)에 문제를 주어 또다른 전역변수가 만들어지는 꼴이 되었습니다.
method가 프로젝트와 디펜던시가 강하게 늘러 붙게 되어 모쥴화 시키는데도 문제가 많습니다.
4. 주석이 하나도 없습니다.
--> 가끔 있습니다. 인터넷에서 복사해 왔을때 기역하기 쉽게 url 정도는 주석으로 한 경우도 있긴합니다.
원래는 참고자료로서 doc폴더를 만들고 프로젝트에 같이 넣어야 하고 코드는 기능으로서만 완벽하게 구현해야 하지만
늘 언급하듯이 귀찮고 시간이 부족하여 일단 코드부터 때려 넣고 어떻게든 굴러게가 만들었기에 ..
나중에 어떻게 만들었는지도 모르고 주석을 달기에 구구절절한 이유가 많아 힘들어 졌습니다.
5. 리펙토링을 해야 합니다.
--> 여러이유로 리펙토링을 해야 합니다. 가독성이 뛰어나게 변수명과 메서드명을 만들어야 하고 , 불필요한 변수는 제거해야 하며
한개의 메서드에서 여러기능을 하고 있다면 쪼개어 한개의 기능을 완벽하게 구현하도록 만들어야 햡니다.
빌드엔 문제가 없지만 논리적으로 어긋난 오류를 찾아야 하고 어플의 라이프 사이클 (타임)에 맞게 알맞은 위치에서
초기화 하고 사용되는지도 체크해야 되고 마지막으로 성능개선이 되도록 유닛테스트도 해야 되겠지요..
하지만... 리펙토링을 안합니다. 왜냐하면
i. 멀쩡히 잘 굴러가는 소스 건들여서 문제를 일으키기 싫다
ii. 리펙토링 하는 시간에 다른 프로젝트를 하는게 더 쉽다 (회사에서 공자왈 맹자왈 할 시간을 안준다)
iii. 지겨운 소스 다시 보고 싶지가 않다
iv. 해봤어야 알쥐.. 리펙토링은 단어만 알고 지적세계수준이 아주 높은 고명하신 사람만이 하는 것이라 생각하여
나와같은 천민은 그딴거 몰라도 된다고 생각한다.
v 귀찮다 (코드 짜는것도 귀찮아서 이따구로 만들었는데 리펙토링을 어케 하냐~)
vi 나만 볼거다.. (자체 난독화 한거다 남들은 보지마라..)
마지막으로
http://blog.daum.net/_blog/BlogTypeView.do?blogid=0Idyj&articleno=2759562&categoryId=368588®dt=20080312112552#ajax_history_home
우선 저희팀은 각 앱별로 담당자가 있는게 아니라 언제나 유동적으로 타 앱에도 투입된다는 걸 명심해 두시고..
그럼 시작하지요
1. 이게 유지보수성이 극히 떨어지는게 팀 내에서 이슈화 되서 최근에는 MVC 모델로 일일이 다 분리작업 하고 있습니다. 네이버 앱들 로그 찍어보시면 얘네들도 MVC 모델로 다 개발되고 있더군요 :)
2. 로컬변수야 그렇다 쳐도 멤버 변수 그렇게 쓰면 저희팀은 개 까여요..ㅠㅠ 변수에도 주석은 필수..
요거때문에 자바 컨벤션 필독했다능...-ㅅ-)
3. MVC 모델로 나뉘니 무조건 참조변수 형태..보통 커맨더는 변수가 5개도 들어가고 모델은 변수 3개 선에서 마무리..ㅎ
4. 주석도 필수..자바 컨벤션 룰에 따라 제작하지요.. 모든 메쏘드는 무조건 /** ...*/ 로 시작..ㄷㄷ 파라미터 모두 지정..누구든 F2 를 누르면 이 함수가 어떤 용도인지 알 수 있게 설명..특히 팀 내 라이브러니는 JavaDoc 과 Doxygen 도 함께 배포..
5. 최근에 Handler 에서 너무 많은 액션을 처리하는 문제때문에 사수랑 얘기 해서 커맨드 패턴으로 변경 중입니다..하악하악..머리 아파요..ㅠ
6. 모든 비지니스 메쏘드는 유닛테스트 반드시 할 것.. Jenkins 연동해서 테스트 리포트 만드는데 요것은 부서장님 지시사항 ㅠ
7. 트렁크 소스는 정상 동작하든 안하든 최소한 정상빌드 상태로 만들것..
매일 저녁7시부터 Jenkins 스케쥴링이 되어 있어서 하루라도 빌드 오류 나면 다음날 머리가 복잡해집니다...- _-;
8. 모든 비지니스 메쏘드는 테스트 가능하게 리턴 타입 있을 것..최소한 true/false 라도..
아무래도 회사에 소속된 팀에서 일하다보니 조금은 귀찮지만
나중에 젠킨스 보면서 N'SIQ 랑 Code Style, Emma Report 보는 재미에 합니다...쿨럭..
근데 오늘 과장님께서 젠킨스 오류 난다고 그거 잡으신다고 강제 야근이 되셨지요 ㅠㅠ
저녁 6시쯤 되면 저도 매일 브랜치 커밋하고 트렁크 머지하고 커밋하고...
커밋 충돌 잡고..Jira 이슈 정리하고 그러느라 정신없네요 -ㅅ-)
평소에 리팩토링이 필요없도록 코딩하면 좋지만... 이건 거의 불가능..
전 꼭 필요한 경우만 리팩토링합니다..
리팩토링에 너무 신경쓰면 리팩토링을 위한 리팩토링을 하고 있는 자신을 발견하더군요.
의사 중에도 전문의(스페셜리스트)가 있는가하면, 모든 과를 조금씩 다 다루는 의사도 있습니다.
프로그래머도 마찬가지라고 생각해요. 양쪽의 장단점이 있기 때문에 호불호를 나눌 수는 없는거고요.
목표를 어디에 두느냐에 따라 작업 방식이나 습관도 달라지게 된다고 봅니다.
리팩토링은 하면 안됩니다!
apk 언팩킹/디컴파일링시 최대한 알아보기 힘들도록 해야하기 때문에, 리팩토링은 하면 안됩니다!
농담이구요.
리팩토링을 하다보면, 패시브 스킬이 증가합니다.
그 효과로 코딩시 무의식중에 효율성 좋은 코드를 유도해 낼 수 있습니다.
이 무의식의 기반에는 리팩토링을 통한 '시행착오' 과정이 리팩토링이라는 노동에 대한 '잠재적 두려움' 이 깔려있습니다.
물론, 무의식이니 걱정은 안하셔도 되며, 순전히 자신의 코딩 실력으로 return 하게 됩니다.
결과적으로 output 이 좋은 개발자가 되는 방법이 아닐까요?
라고 말하면서 리팩토링은 순전히 보여주기용으로만 쓰는 1인 이었습니다.
하나더..
팀내에서 프로젝트가 끝나면 CodeReview 및 회고 라는 것을 진행하는데
패턴을 잘못 사용하거나 소스가 정리가 안되어 있다 싶으면 어김없이 패턴 목적부터 해서 날아오는 화살이...ㅎ_ㅎ;;
PairPrograming 진행하다보면 아무래도 보기 좋은 소스를 만드는데 손이 더 가긴 하더군요
코드의 목적에 따라 다르겠죠.
회사의 자산이 될 코드라면 어느정도의 손해를 감안하고서라도 리팩토링 해야 할 것이고
SI성의 코드라면 뭐 돌아가면 그만.. ㅡㅡ)
리팩토링까진 아니지만
다들 코딩하실때 띄어쓰기 좀 잘해주시면 정말 좋을듯
띄어쓰기 안하고 다닥 다닥 붙어있는 코드 정말 보기 힘들어요.
for(i=0;i<100;i++){count+=i;} 막 이런 코드 미친다능
리팩토링인지는 모르겠지만..
전 제가 짜둔 소스를 봐도 모르기 떄문에 메소드마다 주석은 3줄씩 필수로 적게 되네요..
뭐뭐기 때문에 뭐뭐다..
분기문에서도 이거일때 저거일때 라고 적게됩니다..
변수명은 그냥...메소드안에서 임시로 지역변수 만들때만 temp로 하고 나머지는 길어도 걍 적어버립니다..
Ex) 알고리즘을 통한 비밀번호 생성 리턴값 : createPasswordValue
아 그리고 저도 거의 다 전역으로 박아버린다는..-_-ㅋㅋ
.........리펙토링은 배웠지만..너무나도 거창해서..-0-ㅋㅋ
전 앱 관련 업무 혼자서 다 보지만
리팩토링은 나름 꼼꼼하게 챙기는 편입니다.
위에 댓글에서도 나왔듯이, 그렇게 하지 않으면 결국 불편해 지는건 자신이더군요.
주석까진 달지 않더라도 이 변수가 뭐하는 변수인지,
다른 액티비티와 겹치는 메서드가 없는지, 상속관계는 제대로 설계했는지 등등..
그래서 프로젝트 초기 이틀 정도는 혼자 이런거 정한다고 아예 코딩을 하지 않습니다 ^^;

개인 개발은 제대로된(?!) 설계를 하지 않기 때문이 중복코드가 많아 지는게 아닐까요? 아님 중간중간 내생각대로 변하는 사양?
또한 큰 프로젝트에서도 설계를 하더라도 계속적으로 바뀌는 사양으로 인한 중복 코드 및 나몰라라 실행만 되면 되는 코드 생성....
뭐 여튼... 저역시 리팩토링 할 시간도 여력이 없지만 중요하다고 생각합니다.
아름답고 섹시한 코드가 되기 위해서.... 응?!?! ^^;;;

그리고 사이트 및 카페(?!) 등 또는 분야(앱개발 웹개발 기타 등등)에 따라 댓글이 참으로 방향이 다른것 같네요...
제가 아는 모 웹개발 사이트에 가면 담당자가 중간중간 변하고 대규모 프로젝트가 많다보니
인수인계 받았는데 소스가 !@#%@#% 다... 욕하는 글들이나
리팩토링을 열심히 하자... 이런 코드보면 담배를 피고 온다는 등
흔히들 말하는 어여쁜 코드 누가봐도 이해하기 쉬운 코드... 기타 주석 등을 안달면 안될것 같은 분위기인곳도 있죠 ㅎㅎ
리팩토링의 귀찮은 점 중 하나가 수정 후 계속 동작 확인을 해봐야 한다는 것인데, 테스트 코드를 활용하면 리팩토링이 훨씬 편해집니다.
그럼 테스트 코드를 잘만드는 방법은? 이건 많이 해보는 수밖에 없겠죠..
저도 틈틈히 리팩토링을 하는 편인데, 코드 정리뿐만 아니라 클래스간 의존성을 최대한 없애는 방향으로 합니다.
어느 프로젝트에서 사용한 한 부분의 기능을 다른 프로젝트에서 사용할 일이 있었는데, 다행이도 쉽게 옮겨올 수 있었습니다.
전 제가 만든 모든 게임을 지금 아즈라엘님처럼 짜고 있습니다.
마치 제가 쓴 글처럼 도플갱어를 보는 느낌이네요.
바야바 엔진 만들면서 주석이란걸 한 10년만에 달아본거 같아요.
X파일 책 썼을때 이후로 10년 만인듯