리펙토링 Inline Temp : 리팩토링에 방해되는 임시변수 제거 리팩토링

▣ 개요

→ 아주 간단한 연산을 하는 임시변수가 존재하는데 이 임시변수가 다른 리펙토링을 방해한다면 원래 연산으로 바꿔버린다.


▣ Inline Temp의 사용 필요성

→ 보통 메소드 호출의 결과값이 임시변수에 대입되는 경우에 사용된다.

→ 임시변수가 Extract Methods 같은 리펙토링에 방해가 될시에도 사용된다.


▣ 주의사항

→ 지나치게 복잡한 연산의 경우는 좀 더 생각해보고 변경하길 바란다. 특히 연산량이 많고, 많이 사용되는 임시변수는 더더욱 그렇다.


▣ 예시

double basePrice = anOrder.BasePrice();
return (basePrice > 1000);

return (anOrder.BasePrice() > 1000);

→ 불필요한 임시변수를 제거하고 연산을 직접 넣었다.


리팩토링 Inline Method : 지나치게 간단-명확한 메소드의 제거. 리팩토링

▣ 개요

→ 지난 포스팅때의 Extract Methods 와는 반대개념. 이번에는 보기에도 너무나도 명확한 메소드를 삭제하고 코드조각으로 만들어 버린다.


▣ Inline Method의 사용 필요성

1) 메소드의 몸체가 메소드의 이름만큼 명확할때

2) 불필요한 인디렉션 (간접접근)을 줄이고자 할때

3) 메소드가 잘못 나뉘어져 있을때 그것을 합칠시 사용.


▣ 주의사항

→ 다형성을 가지고 있는 메소드 (오버리이딩 메소드)에는 사용해서는 안된다.

→ 코드조각으로 바꾼 다음 잊지 않고 기존 메소드는 제거한다.

재귀가 사용되는 등의 복잡성을 가진 함수는 적용하지 않는 게 좋을 수도 있다.


▣ 예시

int GetRating()
{
return (MoveThanFiveLateDeliveries()) ? 2 : 1;
}

bool MoveThanFiveLateDeliveries()
{
return m_numberOfLateDeliveries > 5;
}

int GetRating()
{
return (m_numberOfLateDeliveries > 5) ? 2 : 1;
}

→ 지나치게 간략하고 동작히 명확한 메소드를 제거하였다.


리팩토링 Extract Methods : 코드조각을 그룹화하여 별도의 메소드로 만들기 리팩토링

▣ Extract Methods 사용 필요성


1) 지나치게 긴 메소드에 대한 쪼개기 용도

2) 메소드를 잘게 쪼갬으로써 다른 메소드에서 사용 가능성 용이

3) 메소드를 나눔으로써 일련의 주석을 읽는것 같은 효과 : 가독성 쉬워짐

4) 메소드 오버라이딩 용이

→ Extract Methods 수행시 메소드의 이름을 잘 지어야 한다. 만약 이해하기 쉬운 이름을 지을 수 없다면 코드를 뽑아내지 않는 것이 나을지도 모른다.



▣ 주의사항


→ 메소드 이름을 정할시 어떻게 하는지를 나타내는 이름을 정하지 말고, 무엇을 하는지를 나타내는 이름을 정하라.

→ 뽑아내고자 하는 코드 조각 내에 원래 사용하던 지역변수가 있을시에는 새로운 메소드의 파라미터 혹은 지역변수로 바꾼다.

→ 뽑아낸 코드 조각에서 지역변수가 있고, 만약 그 변수가 코드 조각에서 수정되고, 코드조각 이후에 쓰이게 될시에는 이 뽑아낸 코드를 질의(query)로 봐야 한다.

: 질의(query) 는 쉽게 말해 하나의 리턴값을 주는 메소드를 의미한다.

→ 만약 위와 같이 값이 수정되는 지역변수가 둘 이상 존재시에는 다른 방법을 써야 한다.

 

▣ 예시


★ 코드조각 내 지역변수가 없을시

void printOwing()
{
Enumeration e = m_orders.elements();
double outstanding = 0.0;

// banner
System.out.println("*************************");
System.out.println("***** Customer Owes *****");
System.out.pringln("*************************");

// outstanding 계산
while (e.hasMoreElements())
{
Order each = (Order)e.nextElement();
outstanding += each.getAmount();
}

// 상세 정보 표시
System.out.println("name:" + m_name);
System.out.println("amount:" + outstanding);
}
void printOwing()
{
Enumeration e = m_orders.elements();
double outstanding = 0.0;

printBanner();

// calculate outstanding
while (e.hasMoreElements())
{
Order each = (Order)e.nextElement();
outstanding += each.getAmount();
}

// print details
System.out.println("name:" + m_name);
System.out.println("amount:" + outstanding);
}

void printBanners()
{
// banner
System.out.println("*************************");
System.out.println("***** Customer Owes *****");
System.out.pringln("*************************");
}
→ 단순하게 필요한 코드조각만 뽑아서 새로운 메소드로 만들면 된다.

★ 코드조각 내 지역변수 있을시 (읽기전용)
void printOwing()
{
Enumeration e = m_orders.elements();
double outstanding = 0.0;

printBanner();

// calculate outstanding
while (e.hasMoreElements())
{
Order each = (Order)e.nextElement();
outstanding += each.getAmount();
}

// print details
System.out.println("name:" + m_name);
System.out.println("amount:" + outstanding);
}
void printOwing()
{
Enumeration e = m_orders.elements();
double outstanding = 0.0;

printBanner();

// calculate outstanding
while (e.hasMoreElements())
{
Order each = (Order)e.nextElement();
outstanding += each.getAmount();
}

printDetails(outstanding);
}

void printDetails(double _outstanding)
{
// print details
System.out.println("name:" + m_name);
System.out.println("amount:" + _outstanding);
}
→ 단순히 코드 조각 내에서 수정하지 않고 읽기만 하는 지역변수일 경우 (수정 전의 outstanding 변수) 에는 새로운 메소드의 매개변수로 줌으로써 해결할 수 있다.

★ 코드조각 내 지역변수 있고, 이후 바깥에서 사용할시
void printOwing()
{
Enumeration e = m_orders.elements();
double outstanding = 0.0;

printBanner();

// calculate outstanding
while (e.hasMoreElements())
{
Order each = (Order)e.nextElement();
outstanding += each.getAmount();
}

printDetails(outstanding);
}
void printOwing()
{
printBanner();

double outstanding = getOutstanding();

printDetails(outstanding);
}

double getOutstanding()
{
Enumeration e = m_orders.elements();

double outstanding = 0.0;

// calculate outstanding
while (e.hasMoreElements())
{
Order each = (Order)e.nextElement();
outstanding += each.getAmount();
}

return outstanding;
}
→ 변수 e 값은 뽑아낸 코드 내에서만 사용되므로 매개변수로 사용하여도 문제가 없다.

→ outstanding의 경우에는 코드 조각 내부에서 계산이 되어 그 이후에서도 사용되기 때문에 내부에서 선언되어 값을 리턴하는 형태로 수정되었다.


DX11 참 좋은데.. 정말 좋은데.. 글로 표현할 방법이 없네~ 뻘글제조공간~ >.<

네 제목 그대로 입니다. 나름 개그스럽게 적었지만 개그 같지 않습니다. ㅋ DX11 튜토리얼에 수많은 주석질을 하고 해보았지만 이것에 대해 문서화해서 블로그에 올리기에는 확실히 빡센감이 있군요.

그래서 생각해 본게 요즘 학교 수업에서 OpenGL를 다루고 있는데 교수님이 워낙에 뛰어나셔셔 이것에 대한 체계적인 엔진(과는 아주 조금 비슷한)을 만들어가고 있습니다. 이제 기초부분이지만 하나하나씩 추가되고 있는 것이죠.

저의 목표는 이 OpenGL로 만들어지고 추가되는 부분들인 "3D 라이브러리 파일 및 응용 프로그램"을 DX11로 포팅하는 것입니다.

여러가지 변수가 있을 듯 하네요.

1. 지금 수업상에서의 제가 아는 바로는 OpenGL 자체적으로 수학 라이브러리를 지원을 하지 않기 때문에 교수님이 직접 만들어 놓으신 수학 라이브러리를 사용하고 있습니다. 결국 이것을 DX11에서 쓰이는 수학 라이브러리인 XNAMath로 사용하게끔 해야 함.

2. 당연한 얘기겠지만 OpenGL 자체의 렌더링 함수들을 전부 DX11에 맞게 바꿔야 함.
<디바이스 초기화부터 월드, 뷰, 프로젝션 변환 매트릭스 등등 이것들의 형태를 전부 변환해야 됨>

3. DX11은 고정 파이프라인은 지원하지 않으므로 셰이더 함수를 만들어야 함.

결론, OpenGL 및 Dx11 렌더링 구조를 둘다 파악해야 포팅 가능.

이것을 하나하나 추가하면서 DX11에 대한 설명을 부가적으로 올릴 예정입니다. 뭐 쉬울지 어려울지는 모르겠지만 할때까지 해볼려고요 ㅎㅎ.

연봉? 이것 하나에 열정마저 포기해야 하는가? 뻘글제조공간~ >.<

게임업계의 연봉은 대체적으로 낮다고 많이 알려져 있고 저 자신도 그것을 명백한 사실로 받아들이고 있습니다.

제가 많은 이들에게 게임 프로그래머가 되겠다고 선뜻 입밖으로 말하지 못하는 이유 중 하나가 바로 "연봉이 낮으니 다른 일을 하는것이 어떻겠냐?" 라는 소리를 듣기 싫어서 일지도 모르죠.

확실히 알고 있습니다. 다른(몇몇을 제외하고) 개발직 보다도 힘들고, 연봉은 낮고.. 그것을 알면서도 이 길을 간다고 하면 한심해 하는 사람들도 많습니다.

고3때 과를 선택할 시에도 막연히 게임 개발을 하고 싶다는 이유로 컴퓨터과학과에 들어왔고, 지금도 게임 개발과 관련된 과목만 상당부분 쫓아가며 듣고 있습니다.

하지만 이 일을 천직으로 생각하며 하고 싶은데도 연봉이란 부분 때문에 그 열정까지 포기하라는 소리를 들으면 정말 힘이 많이 빠집니다.
뭐 실제 우리나라의 현재 게임 개발자들의 현실도 문제이긴 하지만요.

결국 게임 개발을 꿈꾸었던 많은 사람들이 이 보수의 액수라는 벽 앞에서 자신의 꿈을 너무나도 쉽게 포기하고 다른길로 가버립니다.
최소한 자기만 가지 않으면 상관은 없을텐데 그것을 다른사람에게 까지 부추긴다는 게 더 큰 문제일지도 모르겠죠.

네이버에 "게임 프로그래머"만 검색해봐도 지식인에 수많은 학생들이 이 직업을 어떻게 하냐는 질문이 올라옵니다. 확실히 이들은 이것을 해보고 싶다는 막연한 기대감에서 글을 쓴것일지도 모르겠습니다. 하지만 실제 과연 이 학생들의 몇 퍼센트가 목표를 달성할까요? 저 또한 그런 기로에 놓였습니다.

게임 아카데미 다닐때쯤 하더라도 다들 열정이 뛰어난 친구들이 많았습니다. 돈 안 받아도 좋으니 게임 회사에 취직만 시켜달라고 하던 친구들도 있었을 정도였으니까요. 하지만 지금에 여기 오니 확실히 달라졌다는 것을 깨달은 지도 꽤 됬습니다. 보수에 따라 자신의 해야 할 일이 선택되고, 보수에 따라 자신이 원하는 길을 너무나도 쉽게 포기하는 지금의 현실이 슬플 뿐입니다.

요컨데 제가 내린 결론은 이렇습니다.
"꿈만 가지고 취직 하려는 것은 멍청한 짓이다. 초봉이 내 꿈을 결정하여 준다. 이것을 따르지 않는 사람은 확실히 바보 취급을 당해야 마땅하다."
우리나라에서만 이렇게 되었든 뭐가 되었든 제 개인적인 생각의 현실은 이런 것 같습니다. 어쩔 수가 없는 모양입니다.

그리고 전 이런 개 같은 룰을 한번 깨보고 싶습니다.

→ 개인적인 화를 참지 못하고 블로그에 나마 이런글을 한번 적어 봅니다. 다른사람 보라고 적은게 아닌 그냥 넋두리이니 덧글은 사양합니다.
충분히 논란의 여지가 될 수도 있습니다. 하지만 이건 그냥 개인적인 생각일 뿐입니다.

P.S 직업은 어찌보면 한 사람의 꿈이 될 수도 있습니다. 돈이 됬든 뭐가 됬든 자기 기준에 맞지 않는다고 함부로 말하지 맙시다.

1 2 3 4 5 6 7 8 9 10 다음