기본 콘텐츠로 건너뛰기

[리팩토링] 신박한 정리

 유명한 그리고 한때 유명했던 사람들이 출연하여 자신들의 집을 정리하는 프로그램이 있습니다. 집 정리가 끝난 후 입을 쩍 벌리며 놀라워하는 사람들의 모습이 인상적인 프로그램입니다. 코로나 시국이라 이런 포맷의 프로그램도 등장하는 것 같습니다.

정신없이 프로젝트를 수행하다 보면 우리의 코드도 정리가 필요할 때가 옵니다.
우리도 입이 쩍 벌어질 정도의 깔끔한 코드를 짤 수 있습니다.

아래는 제가 코딩을 하면서 지키는 나름의 가이드입니다.

1. 메모리 관리에 신경쓰야 합니다.
.NET Framework에서 가비지 컬렉션으로 메모리 관리를 하지만 프로그램에서 메모리를 과도하게 낭비하다보면 결국에 OutOfMemoryException을 경험하게 될겁니다.

위 코드에서 Map은 생성하자마자 쓰레기통에 쳐박히게 됩니다.

2. 멤버 변수의 노출을 최소화합니다.

멤버 변수를 가지고 외부에서 어떤 일을 할지 몰라 항상 위험이 존재하게 됩니다.
그리고 멤버 변수를 참조하게 되면 해당 멤버 변수를 수정했을때 참조하는 코드도 수정해야 합니다. 즉 결합도가 증가됩니다. 결합도는 줄이고 응집도는 높여야 좋은 코드가 됩니다.
따라서 메서드를 만들어 클래스에게 일을 시키는 방향으로 코드를 작성하는 것이 좋습니다.
데이터를 받아 일을 하는게 아니라 일을 위임하여 서비스를 받는다고 생각하면 될것 같습니다.

3. 오류가 노출되게 합니다.

가끔씩 오류가 발생할 가능성이 있는 부분 혹은 디버깅시 오류가 발생한 곳에 try/catch로 감싸놓은 코드를 볼 수가 있습니다.

이런 부분의 프로그램의 잠재적 위험이 됩니다. 프로그램이 죽지 않을뿐 우리가 원하지 않은 다른 결과를 얻게 됩니다. 그리고 점점더 위험한 프로그램을 만들게 됩니다.

오히려 우리의 예상과 다른 결과를 얻었을때 오류를 발생시키는 것이 좋습니다.

/// <summary>
/// start에서 end로 가는 최소 비용의 경로를 구한다
/// </summary>
/// <param name="start"></param>
/// <param name="oEnds"></param>
/// <returns>첫 번째 요소: 성공 경로, 두 번째 요소: 실패 경로</returns>
private List<Path> FindShortestPath(Node start, List<Node> oEnds)

위 함수는 출발점에서 종료 지점까지 가는 최단 거리를 구합니다.
우리 프로그램에서는 최단 거리는 하나여야 하기 때문에 그렇지 않을 경우에는 오류를 발생시킵니다.

throw new InvalidOperationException("2개 이상의 경로가 목적지에 도착했습니다.");

4. 클래스나 함수에 주석을 답니다.

클래스나 함수가 하는 일을 정의하고 내용을 주석에 달아 놓고 구현을 하는 것이 좋습니다.
그래야 구현 시 앞서 정의한 내용 외의 것들이 추가되는 것을 방지할 수 있습니다.
누가 될지 모르지만 불쌍한 인수인계자에게 조금의 도움이 됩니다.

5. 함수는 하나의 일만 하도록 합니다.

하나의 함수가 여러가지 일을 하는 멀티 플레이어 함수 보다는 하나의 일을 하는 여러 함수들을 사용하는 것이 좋습니다.

6. 메서드의 내용은 한 화면에 다 보일 정도의 양이면 좋습니다.

코드 사이에 왜 빈 줄들을 많이 넣는지 이유를 모르겠습니다.

7. 매직 넘버는 없습니다.

가끔씩 코드를 보면 특별한 숫자들이 존재합니다. 이 숫자들은 대부분 "이 정도 값이면 되지 않을까?" 라는 의미를 가집니다.
위험하고 이러한 코드를 보면 거부감이 들어야 합니다.
옵션 처리가 가능하면 옵션으로 빼야 합니다.


8. 코딩 컨벤션을 지킵니다.
우리의 프로젝트가 현재 .NET 월드에 있기때문에 .NET 코딩 컨벤션을 지키는게 좋습니다.

마킹한 함수 이름은 자바스럽습니다.

Java는 Java 스타일, Python은 Python 스타일을 지키는게 좋습니다.
더 중요한 것은 한 프로젝트에서는 동일한 컨벤션을 가져야 한다는 것입니다.

9. 변수는 사용되는 위치에서 가까운 곳에 선언합니다.
한 눈에 코드 파악이 쉬워집니다.

public static OrientedRangeBox CreateOrientedRangeBoxBySFeature(CablewayStraightFeature oSF)
{
	OrientedRangeBox oReturn = null;
	Position oPosOrigin = null;
	Vector oVecXAxis = null;
	Vector oVecYAxis = null;
	Vector oVecZAxis = null;
	Vector oVecMove = null;
	Vector oVecXAxis_ORB = null;
	Vector oVecYAxis_ORB = null;
	Vector oVecZAxis_ORB = null;
 
	// Get X,Y,Z Axis 
	getXYZVector(oSF, out oVecXAxis, out oVecYAxis, out oVecZAxis, out oVecXAxis, out oVecYAxis, out oVecZAxis);
 
	// Set Origin Position and Move
	oPosOrigin = new Position(oSF.Location);
 
	oVecMove = new Vector(oVecXAxis);
	oVecMove.Length = -(oSF.Width / 2);
	oPosOrigin = oPosOrigin.Offset(oVecMove);
	oVecMove = new Vector(oVecYAxis);
	oVecMove.Length = -(oSF.Length / 2);
	oPosOrigin = oPosOrigin.Offset(oVecMove);
	oVecMove = new Vector(oVecZAxis);
	oVecMove.Length = -(oSF.Depth / 2);
	oPosOrigin = oPosOrigin.Offset(oVecMove);

위 코드보다 아래가 더 보기 쉬운것 같습니다.

public static OrientedRangeBox CreateOrientedRangeBoxBySFeature(CablewayStraightFeature oSF)
{
	OrientedRangeBox oReturn = null;
	Vector oVecXAxis = null;
	Vector oVecYAxis = null;
	Vector oVecZAxis = null;
	Vctor oVecXAxis_ORB = null;
	Vector oVecYAxis_ORB = null;
	Vector oVecZAxis_ORB = null;
 
	// Get X,Y,Z Axis 
	getXYZVector(oSF, out oVecXAxis, out oVecYAxis, out oVecZAxis, out oVecXAxis, out oVecYAxis, out oVecZAxis);
 
	// Set Origin Position and Move
	oPosOrigin = new Position(oSF.Location);
 
	Vector oVecMove = new Vector(oVecXAxis);
	oVecMove.Length = -(oSF.Width / 2);
	Position oPosOrigin = oPosOrigin.Offset(oVecMove);
	oVecMove = new Vector(oVecYAxis);
	oVecMove.Length = -(oSF.Length / 2);
	oPosOrigin = oPosOrigin.Offset(oVecMove);
	oVecMove = new Vector(oVecZAxis);
	oVecMove.Length = -(oSF.Depth / 2);
	oPosOrigin = oPosOrigin.Offset(oVecMove);

10. 멤버 변수와 지역 변수를 구분하기 쉽게 합니다.
this를 붙이면 로컬 변수와 멤버 변수를 쉽게 구별할 수 있습니다.
이건 제 개인적인 취향입니다.


댓글

이 블로그의 인기 게시물

80040154 오류로 인해 CLSID가 {xxxx-...}인 구성 요소의 COM 클래스 팩터리를 검색하지 못했습니다.

원문보기 .NET 으로 만든 응용프로그램에서 com 객체를 호출한 경우 Windows7 64bit 에서 제목과 같은 에러가 발생했다. Win32 COM 과 .NET 프로그램간의 호환성 때문에 생긴 문제였다. 원인은 .NET 실행시 JIT 컴파일러에 의해 최적화된 기계어로 변환되기 때문.. Win32 COM은 컴파일시.. Win32 COM에 맞춰 빌드 속성에서 하위버전으로 맞춰 컴파일을 다시하는 방법도 있지만 메인 프로젝트가 .NET이라면 참조되는 모든 프로젝트를 다 바꿔야할 노릇.. 또 다른 방법은 COM+를 이용하여 독립적으로 만드는 것이다. 분리시키는 방법은 아래 주소해서 확인할 수 있다. http://support.microsoft.com/kb/281335 나의 경우는 Win32 COM DLL을 64비트 .NET 프로그램에서 참조하니 COM 객체를 제대로 호출하지 못하였습니다. 그래서 .NET 프로그램의 Target Machine을 x86으로 설정하니 제대로 COM 객체를 호출하였습니다.

[Pyinstaller] 실행 파일 관리자 권한 획득하기

고객사에서 일부 사용자에게서 프로그램 오류가 발생한다며 아래와 같이 에러 캡처를 보내왔습니다. 프로그램에서 로그를 남기기 위해 로그 파일을 생성하는데 권한의 문제로 로그 파일을 생성하지 못해 프로그램 오류가 발생한 것 같습니다. 처음에는 Python 코드에서 관리자 권한을 요청하는 코드를 넣으려고 했는데, 실제로 Stackoverflow를 찾아보면 이런 내용이 나옵니다. 프로그램이 관리자 권한으로 실행되지 않았다면 관리자 권한으로 다시 프로그램을 실행시키는 코드입니다. import os import sys import win32com.shell.shell as shell ASADMIN = 'asadmin' if sys.argv[-1] != ASADMIN: script = os.path.abspath(sys.argv[0]) params = ' '.join([script] + sys.argv[1:] + [ASADMIN]) shell.ShellExecuteEx(lpVerb='runas', lpFile=sys.executable, lpParameters=params) sys.exit(0) 하지만 개인적으로 이런 방식은 마음에 들지 않았고 조금 더 찾아보니 Pyinstaller로 exe 파일을 만들 때 옵션을 설정하여 관리자 권한을 요청하도록 할 수 있다고 합니다. --uac-admin을 옵션에 추가하면 프로그램 실행 시 관리자 권한을 요청할 수 있습니다. pyinstaller.exe --uac-admin sample.py 하지만 안타깝게도 이 방식은 원하는 대로 동작하지 않았습니다. 마지막으로 manifest 파일을 이용하여 시도해보았습니다. spec 파일을 이용하여 pyinstaller로 빌드하면 <실행 파일 이름>.manifest 라는 파일이 생성됩니다. 파일에서 아랫부분을 찾아볼 수 있습니다. <security> <re

초간단 프로그램 락 걸기

프로그램에 락을 걸 일이 생겨났다. 하드웨어 락을 걸면 쉬울텐데 그 정도는 아니고 프로그램의 실행 날짜를 제한 해 달라고 한다. 그래서 파일(license.lic)을 가지고 락을 걸리고 결정을 했다. 요구 사항은 아래와 같다. 1. license.lic 파일이 없으면 프로그램을 실행 할수 없게 한다. 2. 지정한 날짜를 넘어서는 프로그램을 실행 할수 없게 한다. 3. 사용자가 시스템 날짜를 되돌렸을때 인식하여 프로그램을 실행 할수 없게 한다. 음.... 1.번 문제는 사용자가 프로그램을 실행하기 위해서 license.lic 파일을 받아야만 한다. license.lic 파일에는 최근 실행 날짜/종료날짜 이런식으로 적도록 한다.(물론 내용은 암호화 한다.) 최근 실행날짜는 프로그램이 실행때마다 업데이트 하도록 하고 시스템 날짜와 비교하여 시스템 날짜가 최근 실행 날짜보다 이전의 날짜면 시스템 날짜를 되돌렸다고 인식하도록 한다.(3.번 문제 해결) 시스템 날짜와 종료 날짜를 비교하여 시스템 날짜가 종료 날짜를 넘으면 프로그램을 실행 할수 없도록 한다.(2.번 문제 해결)