C# & VB.NET2006. 3. 5. 17:56

C#에서는 try-catch-finally 구조를 사용해서 각 예외처리를 수행한다. 그런데 이 구조에서 예전에 제가 C#을 처음 익힐 때부터 약간 혼란스러웠던 것이 있다.


바로 Return 문이 어디에 위치해야 하는가이다...


MSDN 라이브러리의 try-catch-finally 구조에 대한 설명을 보자.

A common usage of catch and finally together is to obtain and use resources in a try block, deal with exceptional circumstances in a catch block, and release the resources in the finally block.

Catch finally같이 때의 일반적인 사용법은 try 블록에서 리소스를 얻어내서 사용하고, catch 블록에서는 예외적인 상황을 다루며, finally 블록에서리소스를 해제한다.



즉, return을 어디 두어야 하는 지는 어디에도 없다.

샘플도 교묘하게 void를 리턴 하는 함수를 만들어서 피해가고 있다.


두 가지 가설이 있을 수 있다.

첫 번째는 return은 메서드가 최종적으로 결과를 돌려주는 것이므로, finally 아래에 와야 한다.

두 번째는 try-catch-finally의 구조로 볼 때, return 문은 예외 처리 코드도 아니고 리소스 해제 코드도 아니기 때문에 try 내부에 오는 것이 맞다.

그래서 가지 방법으로 코드를 작성해 보았다.


//return문이 가장 마지막에 위치

public int ReturnInLastLine()

{

int i = 0;

PrivateOBJ obj = null;

try

{

obj = new PrivateOBJ();

i = obj.GetINT();

}

catch(Exception ex)

{

throw ex;

}

finally

{

obj = null;

}

return i;

}

//try블록 내부에 return이 위치

public int ReturnInTry()

{

int i = 0;

PrivateOBJ obj = null;

try

{

obj = new PrivateOBJ();

i = obj.GetINT();

           return i;

}

catch(Exception ex)

{

throw ex;

}

finally

{

obj = null;

}

}

그리고, 클래스를 컴파일한다음  .NET Reflector디스어셈블한 코드를 보았다.



결과는놀랍게도,

public int ReturnInLastLine()
{
int num1 = 0;
PrivateOBJ eobj1 = null;
try
{
eobj1 = new PrivateOBJ();
num1 = eobj1.GetINT();
}
catch (Exception exception1)
{
throw exception1;
}
finally
{
eobj1 = null;
}
return num1;
}

public int ReturnInTry()
{
int num2;
int num1 = 0;
PrivateOBJ eobj1 = null;
try
{
eobj1 = new PrivateOBJ();
num1 = eobj1.GetINT();

//여기 주의

//원 소스 코드에는 여기에 return이 있다. 그런데?
num2 = num1;
}
catch (Exception exception1)
{
throw exception1;
}
finally
{
eobj1 = null;
}

//여기에 리턴문이 있다.
return num2;
}


IL 코드도 이와 거의 유사하다고 보면 된다.

즉, return을 어느 위치에 두던지 간에 실제로 IL로 컴파일된 코드에서는 return이 가장 마지막에 위치한다는 것이다.

그래서 두 번째 try 내부에 리턴이 있는 경우를 보면 IL 코드는 내부적으로 (코드에는 없는) 변수를 하나
더 선언해서
거기에 값을 할당하고 그 변수를 최종적으로 리턴을 수행할 때 사용하는 것을 볼 수가 있다.



결론

1. 코드 상에서 return문이 어디에 있더라도, IL 코드 상에서는 가장 마지막 라인에 return문이 있게 된다. 결론적으로 마지막에 두는 것이 맞다는 것이다.

2. 코드에 Try 블록 혹은 catch 블록 혹은 여러 군데에 return을 위치시킬 수 있다. 심지어 if-else 문을 사용해서 각각 return하는 경우도 있다. (절대로 권장하지 않는 코딩방법!!) 그 경우 IL이 내부적으로 최종 리턴을 위해서 변수를 하나씩 더 할당한다. 이 값이 만약 매우 큰 데이터셋이라면? 메모리 누수의 원인이 될 수도 있을 듯 하다. 결과적으로 비효율적인 코드라는 것이고, 피해야 할 코딩이 되는 것이다.

Posted by kkongchi
Software Engineering2006. 3. 5. 00:45

스티브 맥코넬의 SPSG(Software Project Survival Guide)에 나오는

"생존 테스트" 이다.

소프트웨어 개발에 몸담고 계시는 분들은 한번씩 해보고

자신이 속한 프로젝트가 과연 살아남을 수 있을까 고민해보시는 것도 좋을 듯 하다.


1. Requirements

1.1. 프로젝트에 명확한 Vision 혹은 Mission 이 있는가?

1.2. 프로젝트 팀원 모두가 제시된 비전을 현실성있다고 생각하는가?

1.3. 고객이 그 프로젝트의 성공으로 얻게 될 비즈니스적인 이점과 그것에 대한 측정방법이 기술되어 있는 Business Case가 있는가?

1.4. 실제 시스템이 가지는 기능을 명확하게 보여줄 User Interface Prototype이 있는가?

1.5. Software Specification 은 상세하게 문서화되어 있는가?

1.6. 팀원들이 프로젝트 초기에 실제 사용자들과 미팅을 했는가? 또 실제 사용자들이 프로젝트에 지속적으로 참여하는가?

2. Planning

2.1. 소프트웨어 개발 계획이 문서화되어 있는가?

2.2. 작업 리스트에 인스톨러 개발, 이전 버전의 데이터 마이그레이션, 고객과의 회의 등 사소한 일까지 포함되어 있는가?

2.3. 일정과 예산 추정치를 최근에 공식적으로 업데이트했는가?

2.4. 아키텍처와 설계를 상세하게 문서화했는가?

2.5. 시스템 테스트, 코드 리뷰를 포함하는 상세한 품질 보증 계획이 문서화되어 있는가?

2.6. 각 단계별로 어떤 버전이 구현되고 납품되는지 상세히 설명한 단계별 납품 계획이 있는가?

2.7. 프로젝트 일정에 휴일, 휴가, 병가, 교육 등의 기간이 모두 포함되어 있는가? 또 인원 할당은 100퍼센트가 안되도록 버퍼가 잡혀있는가?

2.8. 일정을 포함한 모든 계획은 개발팀, 품질 보증팀 등의 모든 관련된 사람들의 승인을 받았는가?

3. Project Control

3.1. 권한이 있는 임원 한명이 프로젝트를 책임지는가? 그리고 그 임원은 프로젝트를 적극 후원하는가?

3.2. PM이 프로젝트에 몰두할 여건이 되어 있는가?

3.3. 프로젝트의 진척 여부를 파악하기 위한 상세한 마일스톤이 정의되어 있는가?

3.4. 프로젝트 이해 관계자들이 마일스톤의 달성 여부를 쉽게 파악할 수 있는가?

3.5. 팀원들이 무기명으로 상급자들에게 문제를 보고할 수 있고, 그 결과를 피드백 받을 수 있는가?

3.6. Software Specification의 변경을 통제하는 계획이 문서화되어 있는가?

3.7. 변경 요청 사항을 수용하거나 거부할 수 있는 권한을 가진 변경 통제 위원회(Change Control Board)가 구성되어 있는가?

3.8. 작업량, 예상 일정, 업무 분장, 계획 대비 진도 등의 현황을 모든 팀원들이 알 수 있는가?

3.9. 소스 코드의 버전 통제는 자동화되어 있는가?

3.10. 버그 트래킹, 소스 코드 통제, 프로젝트 관리 소프트웨어 등 프로젝트 수행 환경에 대한 기초적인 자동화 도구가 준비되어 있는가?

4. Risk Management

4.1. 프로젝트를 완료하는 데 필요한 모든 기술력을 확보했는가?

4.2. 팀원들은 소프트웨어가 운영될 업무 환경에 대한 전문지식을 보유하고 있는가?

4.3. 프로젝트를 이끌 기술 리더가 있는가?

4.4. 인력 자원은 충분한가?

4.5. 팀워크는 좋은가?

4.6. 팀원들이 프로젝트에 전념하고 있는가?




점수 계산 방법

-- 예비 점수: 각 항목별 점수 합산

-- 규모 가중치: 프로젝트 팀에 개발책임자, 품질 보증팀 리더, 최종 책임자를 포함하는 전담 인원이 3명 혹은 그 이하에는 1.5, 4-6명일 때는 1.25, 그 외에는 1.0

-- 최종 점수: 예비 점수 * 규모 가중치


점수에 따른 해석

90점 이상: 성공이 보장되는 프로젝트

80-89: 평균보다 훨씬 좋다. 일정, 예산, 품질 목표에 근접하게 소프트웨어를 납품할 확률이 매우 높다.

60-79: 평균보다 조금 나은 정도. 일정이나 예산을 충족시킬 확률이 어느 정도 있으나 두 가지를 모두 충족시키기는 어렵다.

40-59: 일반적인 수준. 상당한 수준의 스트레스와 불안한 팀워크를 경험할 확률이 높으며, 결국 비용 초과와 일정 지연으로 기대보다 품질이 떨어지는 소프트웨어를 납품하게 될 것이다.

40미만: 모든 부분이 취약하다. 프로젝트를 끝내는 것이 최대 목표가 된다.

Posted by kkongchi
.NET General2006. 3. 5. 00:42

지난 주와 지지난 주 토요일, 그러니까 2월 18일, 25일에 MCPD Beta Exam에 응시해서, 시험을 치뤘다. MCPD는 Microsoft Certified Professional Developer 의 약자로, 이번에 MS에서 닷넷 프레임워크 2.0의 출시와 함께, 새롭게 만들어진 자격증이다. 저는 MCAD를 갖고 있는데, 어느날 beta exam에 무료로 응시해보라는 메일이 왔다. 나중에 어차피 한번 쳐볼까 하는 시험이라서, 공부도 많이 못 했고, 결정적으로…^^;; 기출문제 덤프도 없어서 많이 불안했지만 뭐 불합격해도 본전이라는 생각으로 쳐봤다.


18일에 친건 MCPD Web Application Developer 였고, 25일에는 MCPD Windows Application Developer였다. (MS 자격증 홈페이지를 보면 이것 말고도 Distributed Application Developer라는 게 하나 더 있는데 그건 이번에는 없었다.) 18일에 첫 시험을 쳤을 땐 상당히 당황했다. 처음에 30문제가 나오길래 문제 수가 줄어든 줄 알고 좋아했었는데, 알고보니 30문제/1시간씩 총 3개의 섹션이 있는 것이었다. 그렇게 3시간. 그리고 처음 섹션의 1시간이 끝나면, 그 섹션의 시험문제는 다시 재검토할 수가 없다. 즉 3과목 시험을 연속으로 치는 거랑 비슷하다고 보면 된다.


1,2번째 섹션은 두 시험 다 기존 MCSD, MCAD 시험과 유사한 형태라고 보시면 된다. 언어와 기술에 대한 기본적인 이해가 필요한 문제들이 나온다. 좀 치사하게 나오기 때문에 주의가 필요하다는 것은 기존 시험 쳐보신 분들은 다들 알 것이다. (이게 바로 덤프가 반드시 필요한 이유이기도 하다) 그리고 좀 특기할 것은 이번에 C#에서 (처음에 시험 start 버튼을 누르면 언어 선택 화면이 나오고 거기서 VB, C#, C++ 중에서 고를 수 있다) 추가된 제네릭 (public class GenericList<T> 이런 형태로 쓰는거) 에 대한 문제가 꽤 나왔다. 그리고 두 시험 다 UI에서 데이터를 비동기 형식으로 가져오는 부분에 대한 문제도 여러 개 나왔던 것으로 기억한다.


그리고, 좀 기존에 비해서 특이했던 것이 마지막 섹션이다. 마지막 섹션 30문제는 말하자면, 디자인에 관한 문제들이다. 애플리케이션, 시스템 배포 등에 대해서 상황을 설명하고 그 중 최적의 솔루션, 혹은 문제를 해결하는 방안에 대해서 질문한다. 예를 들면 분산 시스템 환경에서 firewall에서 어떤 포트를 열어야 클라이언트에서 웹 서버에 접속할 수 있는지, 또는 특정 환경에서 클라이언트 배포 방법으로 Windows Installer 가 나은지 아니면 click once 기술이 나은지 등등의 문제가 출제되었다.


시험 방식도 새롭고, 문제도 새로운 스타일의 문제가 많이 나와서 조금은 개선되었다고 말할 수 있을 것 같다. 특히 좀전에 언급한 마지막 섹션같은 경우는 지식도 중요하지만 경험이 있다면 더 쉽게 풀수 있지 않을까 생각이 된다. 아무래도 진정한 실력 평가는 그런 것이 되어야 한다라고 생각했기 때문에, 올바른 방향으로 시험이 발전되었다고 생각한다. 물론 덤프가 나온다면, 뭐 똑같아 지겠지만 말이다.

* 일단 시험은 봤는데, 결과는 바로 나오지는 않았다. 아마 beta라서 그런 것 같은데, 성적은 메일로 준다고 마지막에 나와서 차라리 다행이라고 생각했다..^^;;

Posted by kkongchi