U E D R , A S I H C RSS

조현태/잡담 (rev. 1.1)

조현태/잡담

현태/잡담

리펙토링

프로그램을 짜고있는 프로그래머 입장에서, 리펙토링은 안할 수 없다!!
라고는 주장하나, 실제 리펙토링은 거의 하지 않고있다. 소스를 짤때 좀더 변수명을 잘 적어준다던지 하지만,
소스안에서 중복이 훤히 보이나 수정은 안하는 실정..
항상 프로그램 다짜고, 리펙토링이나 해야지.. 라고 말하곤 한다.
'이놈의 숙제만 없어도.'라고 입버릇 처럼 중얼거리나, 숙제가 없어진다고 리펙토링을 할까?

그러고 보니 리펙토링된 소스와 내 소스와의 차이점이 많은것 같았다.
나는 무조건 if(...)적으면 다음에 엔터! { 적고 엔터! 내용적고 엔터! }로 마무리!
if (...)
{
내용
}
이지만, 대부분 if (...) { 로 시작해서 처리하고, if문 이하의 내용이 한줄일때는 if문 바로 아래에 그냥 적어버린다.{없이
또 옆에 적는 경우도 있다. (어떻게 적든 컴파일러는 신경안쓰기 때문에.)
또 나는 함수1개가 반페이지 분량에서 3페이지 분량.. (요즘 짜고있는 게임의 엔진은 예외적으로 14페이지다.;;;;)
인데, 리펙토링 하시는 분들은, 5-6줄짜리 조그마한 함수도 자주 만들어서 사용한다.
함수만들때마다, 작명하는 것도 고민이고 해서, 함수를 많이 만들지 않는데..
특히 함수나 변수명이 전부 영어라 고친다고 해서 그다지 알아보기 좋아지지 않는다.

이렇게 푸념을 하기는 해도.. 언젠가는 리펙토링 해야할 일! 한동안 게임 만드는거 중단하고 리펙토링이나 하고 있을까?
잠시 쉬어가는 것도 좋을 듯 하다! ㅎㅎㅎ

협동


나는 대한민국의 국민이고, 중앙대학교의 학생이며, 컴퓨터 공학부에 속해있다. 또한 고향은 부산이고, 리니지2를 즐긴다.
다시말해 나는 이러한 부류의 사회에 속해있는 것이다.
그래서 이러한 사회와 환경에 매우 익숙해져 있고, 실제로 거의 '녹아'있다.
결과적으로 나는 이러한 나의 모습에 특별한 느낌을 가지지 못하고 있다.

그러나 다른 사람이 이러한 나를 보게되면 자신과는 다른 모습에 무언가 색다른 느낌(!), 차이점을 느끼게 될 것이다.
또한 나역시 그러한 느낌을 가지게 될 것이다.
이러한 점이 서로에게 알려진다면, 자신은 평소에 별로 대수롭지 않게 느꼈던점을 새로이 보게 될 것이고,
문제점은 보완 수정하고 좋은점은 유지, 발전 시킬 수 있을 것이다.

- 오늘 선배님께서 별생각없이 적은 내 생각에다 덧붙여 설명해주신 글을보고 색다른 느낌과 감동을 받아서 적어보았다.^^

리펙토링2

결국 마음먹고 시작한 리펙토링, 하지만 제대로 하고 있는 것인지 알 수 없다. 그게 어떻게 해야 보다 나은 리펙토링인지 알 수 없기때문.

함수를 좀더 기능별로 세분화 하였다. (14페이지나 되던 엔진을 확실히 분할해 주었다.)
결과는.. 소스코드가 더욱 더 길어졌다!!;;

중복된 부분을 고치기 위해서 상수를 도입하고 배열을 도입해서 좀더 줄였다.
결과는.. 배열과 상수로 인해 메모리가 더욱더 사용되었고, if문의 등장으로 연산량이 더욱 늘었다!!
(마치 구구단을 수동으로 쭉 늘여쓴 것을 리펙토링 한다고 for문을 등장시켜 연산량과 변수만 대폭 늘어난 꼴;;)

IF ( )
{
내용
}
이렇던 구문을
IF ( )
내용
이렇게 고쳤다.
결과는.. 소스 2줄 줄이고 더 다닥다닥 붙어서 복잡해 보인다..

정말이지 어떻게 해야 잘된 리펙토링 일까..ㅠ.ㅜ
리펙토링은 영원한 미스테리..쳇..

전역변수


프로그램 짜는데 사용하기 쉬운 전역변수. 부르기도 쉽고 값을 넣기도 쉽고.. 값 전달 안해줘도 함수에서 마구마구 적어줄 수
있다는.. 메리트 만점의 변수랍니다..^^ 그런데 파일을 쪼게서 좀더 보기 쉽게 할려고 했더니.. 문제가 이만저만이 아니더군요..ㅠ.ㅜ
역시 전역변수를 사용하면 함수의 연산결과가 전 함수에 미쳐버려서 디버깅 하기도 어렵거니와, 무엇보다도 파일이 분할되면 나름대로
문제..OTL extern을 사용해 줘도.. 왠지 어디선가 문제가 생기는 듯.. 미쵸..ㅠ.ㅜ 구조체의 문제인가..;;(결국 구조체는 헤더로 날려
버렸다는..ㅎㅎ) 좀더 머리를 싸매 보아야..ㅎㅎㅎ

파일나누기


프로젝트 문제도 있고 해서 여러모로 요즘 나눠진 cpp파일을 한 프로젝트로 묶는 일이 많은데.. 이거 의외로 머리썩힌다는..
정작 게임은 6-7개로 나누는데 성공했는데.. 프로젝트 파일이 합칠때 또 오류가 생긴다. 어디가 문제인거지?
의외로 .NET 개발환경이 이런부분에 취약한 듯 하다.(재정의 구문.) extern을 사용해도 영.. 혹시 문제점을 쉽게 해결할 수 있게되면 올려두겠음..^^

변수명


이번 프로젝트 때문에, 태어나서 처음으로 변수명을 사전을 찾아가며 정해주는 행각을 벌렸다. 평소에는 어짜피 나밖에 안보는 소스니,
대강 스펠링 신경안쓰고 되는데로 적어서 (본인만 알아볼 수 있었음.) 변수명을 정해주었는데..
변수명 길게 적으니 타자치기 힘들어 질 줄 알았는데.. 어시스트가 일일이 띄워줘서 별로 달라진건 없었다.
변수명이 길어져도 소스를 작성하는 본인에게는 그렇게 큰 차이가 없지만, 시간이 상당히 지나서 잊어먹을 정도가 되거나
타인이 소스를 볼 경우에는 차이가 큰 듯하다.
앞으로는 변수명을 좀 신경써서 작성할 것.ㅎ

혹시 이 글을 보는 동기중에 컴퓨터에 어시스트가 안깔려있는 동기분은 한번 깔아보는것도 권장한다.^^


프로그래머란..


이번에 내주신 프로젝트..어쩌다 팀의 리더(?)가 되었다. 팀의 리더란 팀을 이끌어나가는 가이드라인 역활을 하는 사람일 것이다.
그러나, 나는 그렇게 하고 있는가? CC의 데이트 지원을 핑계삼아(사실 이문제도 꽤나 심사숙고 하기는 했다.)부족한 능력으로 하다못해 회의라도 제대로 하지 못하고, 할일을 몇개 주고는 나머지는 혼자 짜버리고 있다.
다른 팀원들의 의견이 분명히 제대로 반영되어야 하는데 말이다. 에휴..

예전에 프로그래머를 구하는 글을 본 적이있다. 오래되고 자세히 보지않아서 기억을 잘 안나지만 대강 이런 내용이었던듯 하다. '우리는 독불장군을 원하지 않습니다. 또한 우리는 기계를 원하지도 않습니다.'
기껏해야 1000줄 내외의 프로그램이야 혼자서도 짤 수 있지만, 실제로 짜야할 프로그램들은 그렇지 않다.
그런데 자신만이 옳다고 모두 주도해 버린다면, 프로그램은 분명 그사람의 생각'만'을 따라갈 것이고, 그 사람이 가진 생각의 허점을 그대로 반영할 것이다. 그래서 나중에는 같은 프로그래머와의 관계가 소원해지는 것은 물런, 정작 제대로 된 프로그램 만드는것 조차 실패하게 된다.
반대로 프로그래머는 기계가 아니다. 주어진 업무를 할당받고 주어진 일'만'그대로 수행한다면 기계와 다름없다. 명령을 내리면 일을 수행하는 것은 컴퓨터와 다름 없지 않은가? 단지 명령을 쉽게 이해할 뿐이다. 프로그래머도 역시 사람이다. 생각이 분명 존재하고, 자신의 개성역시 존재한다. 작가는 글로 자신을 표현한다면, 프로그래머는 자신이 작성하는 알고리즘, 소스 하나하나가 자신의 생각을 대변하는 분신과 다름없다. 그런데 자신이 짜는 프로그램에 자신의 생각을 담아내지 못한다면, 아마 '죽은 프로그래머'가 아닐까?

다시말해, 유능한 프로그래머란 자신의 의견을 내세울 수 있으면서도 타인의 의견을 수렴해서, 프로그램에 프로그램을 짜는 개개인의 생각이 고스란히 남아있을 수 있도록 하는 프로그래머일 것이다.

아직 프로그래밍 능력이외에도, 대화능력이 부족한 나로써는 나를 택해준 현정군,현지양에게 미안할 따름이다.^^
모기때문에 일어나서 새벽에 코딩하다가 문득 떠올라서 적어본다. 애초에 정리를 좀 하고 배분도 좀 해두고, 어떻게 진행할지도 생각 해 뒀어야 하는데 너무 무책임한게 아닌가 생각한다. 매사에 대강대강하는게 문제라니까...
다시한번 현지양, 현정군에게 심심한 사과를 표한다. ()(__)() 분명 심심했을듯...

리펙토링3

리펙토링~리펙토링~ 프로젝트를 짜다말고 리펙토링중.. 역시 리펙토링에는 배열이 '짱'이다. 일단 간단한 연산에 의해 메모리 엑세스가 되니까 검색이 빠르다. 또한 같은 부류를 한곳에 묶을 수 있으니 보는 입장에서 편하다.^^ 또한 연산에 의해서 접근하기 때문에, 변수마다 해줘야 하는 반복된 작업을 반복문에 넣고 간단히 해줄 수 있다.

단점이 있다면 배열의 메모리 번지마다 어떤 의미를 가지는지는 주석으로 달아줘야 한다는점..또 잘못하면 엉뚱한 메모리를 엑세스 해서 치명적 오류를 유발한다는 점..

역시 만능은 없나?

하고싶은말

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
Processing time 0.0404 sec