336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

regedit 를 실행

HKEY_CURRENT_USER\Software\TortoiseGit 에 OpenRebaseRemoteBranchUnchanged 키를 지우면

다시 자동으로 열것인지를 물어본다


출처 : https://gitlab.com/tortoisegit/tortoisegit/issues/2653

Posted by 역시인생한방
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

_netrc 라는 이름의 파일을 (확장자 없음)


C:\Users\<Your-Username> 폴더에 생성하고


내용으로


machine github.com

login <Username>

password <Password>


입력하고 저장


명령 프롬프트 창을 열고


setx home C:\Users\<Your-Username>


입력하면 끝!


Windows 7 이전버전 사용자라면 아래 출처를 참고


출처 : http://www.munsplace.com/blog/2012/07/27/saving-username-and-password-with-tortoisegit/

Posted by 역시인생한방
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

출처 : http://www.gnu.org/licenses/gpl-howto.html

Posted by 역시인생한방
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

출처 : https://wiki.kldp.org/wiki.php/OpenSourceLicenseGuide

Posted by 역시인생한방
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
MacroDescription

$(RemoteMachine)

Set to the value of the Remote Machine property on the Debug property page. SeeChanging Project Settings for a C/C++ Debug Configuration for more information.

$(References)

A semicolon delimited list of references added to the project.

$(ConfigurationName)

The name of the current project configuration (for example, "Debug").

$(PlatformName)

The name of current project platform (for example, "Win32").

$(Inherit)

Specifies the order in which inherited properties appear in the command line composed by the project build system. By default, inherited properties appear at the end of the current property.1

$(NoInherit)

Causes any properties that would otherwise be inherited, to not be inherited. To also prevent evaluation at the sibling level, use $(StopEvaluating). The use of$(NoInherit) causes any occurrences of $(Inherit) to be ignored for the same property.1

$(StopEvaluating)

Immediately stops the evaluation of a macro in the evaluation chain. Any values that appear after $(StopEvaluating) will not appear in the evaluated value of the macro. If$(StopEvaluating) precedes $(Inherit), the inherited value at the current location in the evaluation chain will not be concatenated to the macro value. $(StopEvaluating)is a superset of the functionality of $(NoInherit).

$(ParentName)

Name of the item containing this project item. This will be the parent folder name, or project name.

$(RootNameSpace)

The namespace, if any, containing the application.

$(IntDir)

Path to the directory specified for intermediate files relative to the project directory. This resolves to the value for the Intermediate Directory property.

$(OutDir)

Path to the output file directory, relative to the project directory. This resolves to the value for the Output Directory property.

$(DevEnvDir)

The installation directory of Visual Studio .NET (defined as drive + path); includes the trailing backslash '\'.

$(InputDir)

The directory of the input file (defined as drive + path); includes the trailing backslash '\'. If the project is the input, then this macro is equivalent to $(ProjectDir).

$(InputPath)

The absolute path name of the input file (defined as drive + path + base name + file extension). If the project is the input, then this macro is equivalent to $(ProjectPath).

$(InputName)

The base name of the input file. If the project is the input, then this macro is equivalent to $(ProjectName).

$(InputFileName)

The file name of the input file (defined as base name + file extension). If the project is the input, then this macro is equivalent to $(ProjectFileName).

$(InputExt)

The file extension of the input file. It includes the '.' before the file extension. If the project is the input, then this macro is equivalent to $(ProjectExt).

$(ProjectDir)

The directory of the project (defined as drive + path); includes the trailing backslash '\'.

$(ProjectPath)

The absolute path name of the project (defined as drive + path + base name + file extension).

$(ProjectName)

The base name of the project.

$(ProjectFileName)

The file name of the project (defined as base name + file extension).

$(ProjectExt)

The file extension of the project. It includes the '.' before the file extension.

$(SolutionDir)

The directory of the solution (defined as drive + path); includes the trailing backslash '\'.

$(SolutionPath)

The absolute path name of the solution (defined as drive + path + base name + file extension).

$(SolutionName)

The base name of the solution.

$(SolutionFileName)

The file name of the solution (defined as base name + file extension).

$(SolutionExt)

The file extension of the solution. It includes the '.' before the file extension.

$(TargetDir)

The directory of the primary output file for the build (defined as drive + path); includes the trailing backslash '\'.

$(TargetPath)

The absolute path name of the primary output file for the build (defined as drive + path + base name + file extension).

$(TargetName)

The base name of the primary output file for the build.

$(TargetFileName)

The file name of the primary output file for the build (defined as base name + file extension).

$(TargetExt)

The file extension of the primary output file for the build. It includes the '.' before the file extension.

$(VSInstallDir)

The directory into which you installed Visual Studio .NET.

$(VCInstallDir)

The directory into which you installed Visual C++ .NET.

$(FrameworkDir)

The directory into which the .NET Framework was installed.

$(FrameworkVersion)

The version of the .NET Framework used by Visual Studio. Combined with $(FrameworkDir), the full path to the version of the .NET Framework use by Visual Studio.

$(FrameworkSDKDir)

The directory into which you installed the .NET Framework SDK. The .NET Framework SDK could have been installed as part of Visual Studio .NET or separately.

$(WebDeployPath)

The relative path from the web deployment root to where the project outputs belong. Returns the same value as RelativePath.

$(WebDeployRoot)

The absolute path to the location of <localhost>. For example, c:\inetpub\wwwroot.

$(SafeParentName)

The name of the immediate parent in valid name format. For example, a form is the parent of a .resx file.

$(SafeInputName)

The name of the file as a valid class name, minus file extension.

$(SafeRootNamespace)

The namespace name in which the project wizards will add code. This namespace name will only contain characters that would be permitted in a valid C++ identifier.

$(FxCopDir)

The path to the fxcop.cmd file. The fxcop.cmd file is not installed with all Visual C++ editions.


출처 : https://msdn.microsoft.com/en-us/library/c02as0cs(v=vs.80).aspx

Posted by 역시인생한방
,

Singleton Pattern

Programming/Etc 2015. 11. 2. 17:01
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

5. 싱글턴 패턴

  • 싱글턴패턴은 인스턴스가 하나 뿐인 특별한 객체를 만들 수 있게 해주는 패턴이다.
  • 어떤 용도로 쓰는 건가?
    • 스레드 풀이라던가, 캐시, 대화상자, 사용자설정, 디바이스드라이버 등등 객체가 전체프로그램에서 오직 하나만 생성되어야 하는 경우에 사용한다.
  • 그럼 전역변수로 static 으로 선언해서 사용하면 되지 않느냐?
    전역 변수로 객체를 생성하면 어플리케이션이 실행 될 때 객체가 생성될 것이다.(P208 맨밑줄)
    그 객체가 자원을 많이 차지 한다면 사용도 되기전에, 괜히 자원만 차지한다. 사용하지 않는다면 아무 쓸 데 없는 객체가 되겠지.

고전적인 싱글턴 패턴 구현법

  • 조심하세요.. 이 코드에 문제가 있다는 것을 알게 될 것입니다.
public class Singleton {
  
  //private으로 Sinleton클래스의 유일한 인스턴스를 저장하기 위한 정적 변수를 선언
  private static Singleton uniqueInstance;

  //생성자를 private로 선언했기 때문에 Singleton에서만 클래스를 만들 수 있다.
  private Singleton() {}

  //클래스의 인스턴스를 만들어서 리턴해 준다.
  public static Singleton getInstance() {
    if(uniqueInstance == null) {
      uniqueInstance = new Singleton();
    }
    return uniqueInstance;
  }

}

싱글턴 패턴의 정의

  • 싱글턴 패턴은 해당 클래스의 인스턴스가 하나만 만들어진다,
  • 어디서든지 그 인스턴스에 접근할 수 있도록 한다.
  • 클래스에서 자신의 단 하나뿐인 인스턴스를 관리하도록 만들면 된다.

멀티스레딩 문제 해결 방법

  • getInstance()를 동기화시키기만 하면 멀티스레딩과 관련된 문제가 간단하게 해결된다.
public class Singleton {
  private static Singleton uniqueInstance;
  // 기타 인스턴스 변수
  private Singleton() {}
  
  //synchronized 키워드만 추가하면 두 스레드가 이 메소드를 동시에 실행시키는 일은 일어나지 않게 된다.
  public static synchronized Singleton getInstance() {
    if (uniqueInstance == null) {
       uniqueInstance = new Singleton();
    }
    return uniqueInstance;
  }
// 기타 메소드
}
  • 이렇게 하면 문제가 해결되긴 하겠지만, 동기화를하면 속도 문제가 생기지 않나?
    동기화는 불필요한 오버헤드만 증가시킬 수 있다.

더 효율적인 방법은 없을까요?

1. getInstance()의 속도가 그리 중요하지 않다면 그냥 내비 둔다.

  • 메소드를 동기화하면 성능이 100배 정도 저하된다는 것은 기억해 두자
  • 만약 getInstance( )가 애플리케이션에서 병목으로 작용한다면 다른 방법을 생각해봐야 한다.

2. 인스턴스를 필요할 때 생성하지 말고, 처음부터 만들어 버린다.

public class Singleton {
  private static Singleton uniqueInstance = new Singleton();

  private Singleton() {}

  public static Singleton getInstance() {
    return uniqueInstance;
  }
}
  • 이런 접근법을 사용하면 클래스가 로딩될 때 JVM에서 Singleton의 유일한 인스턴스를 생성해 준다.

3. DCL(Double-Checking Locking)을 써서 getInstance()에서 동기화되는 부분을 줄인다.

  • DCL(Double-Checking Locking)을 사용하면, 일단 인스턴스가 생성되어 있는지 확인한 다음, 생성되어 있지 않았을 때만 동기화를 할 수 있다.
  • volatile 키워드를 사용하여 멀티스레딩을 쓰더라도 uniqueInstance 변수가 Singleton 인스턴스로 초기화 되는 과정이 올바르게 할 수 있다.
  • DCL은 자바 1.4 이전 버전에서는 쓸 수 없다
public class Singleton {
  private volatile static Singleton uniqueInstance;

  private Singleton() {}

  public static Singleton getInstance() {
    if (uniqueInstance == null) {
      //이렇게 하면 처음에만 동기화 된다
      synchronized (Singleton.class) {
        if (uniqueInstance == null) {
          uniqueInstance = new Singleton();
        }
      }
    }
    return uniqueInstance;
  }
}

핵심 정리

  • 어떤 클래스에 싱글턴 패턴을 적용하면 애플리케이션에 그 클래스의 인스턴스가 최대 한 개 까지만 있도록 할 수 있다.
  • 싱글턴 패턴을 이용하면 유일한 인스턴스를 어디서든지 접근할 수 있도록 할 수 있다.
  • 자바에서 싱글턴 패턴을 구현 할 때는 private 생성자와 정적 메소드, 정적 변수를 사용 한다.
  • 다중 스레드를 사용하는 애플리케이션에서는 속도와 자원 문제를 파악해보고 적절한 구현법을 사용해야 한다.
  • DCL을 사용하는 방법은 자바2 버전 5(자바 1.5)보다 전에 나온 버전에서는 쓸 수 없다는 점에 주의.
  • 클래스 로더가 여러 개 있으면 싱글턴이 제대로 작동하지 않고, 여러 개의 인스턴스가 생길 수 있다.


출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=1507403

Posted by 역시인생한방
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

 확률을 계산하려면 경우의 수를 헤아려야 한다고 했습니다. 전체의 갯수 n개에서 일부의 r개를 

뽑을 때, 뽑는 순서를 고려해야 하는 지와 고려하지 않아도 되는 지를 구별하는 것은 중요합니다. 

(같은 의미로 r개를 뽑는 것과 r개를 뽑아 일렬로 나열하는 것으로 말하기도 합니다.) 그래서,  

이 둘을 순열과 조합으로 구별합니다. 

 예를 들어, A와B의 2개가 선택되는 경우, 순열에서는 A,B와 B,A가 다르지만,  

 조합에서는 A,B와 B,A가 동일한 경우입니다.    

1. 순열(Permutation) 

  서로다른 n개에서 r(r은 n보다 작거나 같습니다.)개를 택하여 일렬로 나열하는 것으로써, 

 n개에서 r개를 택하는 순열이라고 말합니다. 기호로는  

  

 과 같이 나타내고, 이 계산은 

 

즉, n에서 시작하여 1씩 작아지는 수를 차례로 r개 곱한 것입니다. 

    이것은 n개에서 r개를 선택하는 것을 하나씩, 하나씩 선택해 나갈 때,  

맨처음에는 n개에서 한 개를 선택하고 난 후, (n-1)개 남으므로  

그 다음에는 (n-1)개에서 1개를 선택하는 식으로 r번을 반복하는 것과 같습니다. 

 

  순열이 적용되는 예는 일렬로 세우는 경우, 문자열의 나열, 숫자를 선택하여 자연수를 만드는 것 등이 

이에 해당됩니다.  

 

2. 순열의 계산 

     

 

3. 조합(Combination)

    서로다른 n개에서 순서를 생각하지 않고 r(r은 n보다 작거나 같습니다.)개를 택하는 것으로써,

n개에서 r개를 택하는 조합이라고 말합니다. 기호로는 

 

과 같이 나타내고, 이 계산은 

   

  이 식을 보면, 순서를 고려한 순열의 계산값을 중복되는 정도만큼 나누어 주는 것입니다. 예를들어, 

2개를 선택하는 경우 AB, BA가 동일한 것으로써 2로 나누어야 함을 말하는 것이고, 

3개를 선택하는 경우 6가지(ABC,ACB,BAC,BCA,CAB,CBA)가 동일하므로 3!(=6)로 나누어 주는 것입니다. 

4개를 선택하는 경우에는 4!만큼의 동일한 경우가 생기겠지요.  

 

4. 조합의 계산 

   


출처 : http://blog.naver.com/jklee517/150176219823

Posted by 역시인생한방
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

[Server - C#]


using System;

using System.IO;

using System.IO.Pipes;


namespace NamedPipeCs

{

class Program

{

static void Main(string[] args)

{

while (true)

{

using (var server = new NamedPipeServerStream("DavidPipe"))

{

server.WaitForConnection();


using (var reader = new StreamReader(server))

{

string temp;

while ((temp = reader.ReadLine()) != null)

{

Console.WriteLine("{0}", temp);

}

}

}

}

}

}

}


----------------------------------------------------------------------------


[Client - C++]


#include <iostream>

using namespace std;

#include <windows.h>


int main()

{

HANDLE hPipe = CreateFile("\\\\.\\pipe\\DavidPipe", GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

if (hPipe == NULL || hPipe == INVALID_HANDLE_VALUE)

return -1;


LPTSTR lpMessage = TEXT("FUCK THAT SHIT");

DWORD dwNumberOfBytesToWrite = (lstrlen(lpMessage) + 1) * sizeof(TCHAR);

DWORD dwNumberOfBytesWritten;


BOOL bSuccess = WriteFile(hPipe, lpMessage, dwNumberOfBytesToWrite, &dwNumberOfBytesWritten, NULL);

if (bSuccess == FALSE)

return -1;


CloseHandle(hPipe);


return 0;

}

Posted by 역시인생한방
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
이번 기사의 내용은 2014 게임 개발 성과 측정 프로젝트에서 가장 중요한 40가지 발견의 요약입니다. 우리는 상관계수의 값을 기준으로 가장 중요한 요인부터 내림차순으로 정렬하였습니다.

우리의 연구는 273명의 개발자로부터 응답받은 120개 문항의 설문조사에 바탕을 두고 있습니다. 결과자료를 통해 몇몇 놀라운 결론을 도출하게 되었습니다: 우리는 팀들 간에 존재하는 어마어마한 문화적 차이를 발견하였고, 우리가 조사한 대부분의 문화적 요인이 프로젝트 성과에 강한 상관관계를 보인다는 사실을 확인하였습니다. 이 기사에서는 설문조사 데이터를 근거로 가장 성공적인 개발팀과 나머지를 나누는 요인이 무엇인지 설명할 것입니다.

설문조사의 상당 부분은 다음의 책들에 소개된 효율적 팀 모델에 기반을 두고 있습니다. 성공적인 팀의 5가지 조건 (원서), 탁월한 조직이 빠지기 쉬운 5가지 함정 탈출법 (원서), 12 위대한 경영의 요소 (원서). 우리가 발견한 첫 번째 놀라운 사실은 이 모델에 기반을 둔 46개의 설문 항목 중 39개(85%)가 모든 성과 점수와 강한 모델이 예측한 방향대로 강한 상관관계를 나타내었고, 나머지 5개 설문 항목은 한두 개를 제외한 모든 성과점수와 상관관계를 나타냈습니다.


가능하다면 우선 이 책들을 읽어보세요. 현재 당신이 리더의 위치에 있다면 더 큰 도움이 될 것입니다. 

우리가 게임 개발을 하고 있다고 해서 조직의 효율성을 높이는 방법이 다른 산업과 근본적으로 다르거나, 수십 년간에 걸쳐 축적되고 입증된 경영학 연구결과가 게임산업에만 예외로 적용되지 않는 건 아닙니다. 

우리의 해석에 동의하지 않으신다면, 앞선 기사 (123, & 4)를 읽고 스스로 결론을 내려주세요. 우리의 분석을 재확인하고 직접 데이터를 연구해보고 싶다면, 이곳에서 로우데이터를 다운받을 수 있습니다.


위대한 팀의 40가지 특징

1. 위대한 개발팀은 게임 기획과 개발계획에 대한 분명하고, 공유된 비젼을 가지고 그 비젼의 열정은 팀원들 간에 전염됩니다 [123]. 눈에 보이고, 강렬하며, 명확하며 잘 소통되어 공유된 비젼은 우리가 살펴본 모든 요인 중 가장 중요했습니다. 반드시 최종 게임에 대한 비젼이 팀 전원에게 명확하고 확실하게 전달되고, 팀원들은 개발 과정에서도 비슷한 비젼을 공유해야 합니다. 특히나 리더들은 끊임없이 공유된 비젼을 소통하며, 기획이나 개발 계획에 변동이 생기면 면밀하게 전달하고, 비젼에 대한 어떠한 분쟁이라도 발생하면 전문적이고 신속하게 분쟁을 해소해야 합니다.

위대한 개발팀은 게임의 비젼에 대해 많은 관심을 기울입니다[4]. 그들은 전염되는 열정을 가지고 날카로운 집중력을 키웁니다. 열정은 긍정적 성과를 내는 데 매우 중요한 역할을 하는데, 열정이 없다면 프로젝트에 즉각적으로 대응해야 하는 문제가 있다는 분명한 신호입니다. 비젼의 수정이 필요하거나, 사람들 사이에 문제가 있는 것일 수도 있습니다. 함부로 결론을 내서는 안되고 신중하게 조사해서 문제를 파악해야 합니다.

2. 위대한 개발팀은 게임 기획과 비젼, 그리고 개발 계획의 리스크를 세심하게 관리합니다 [1].

그들은 개발 도중에 생기는 변동사항으로 인하여 게임이 원래의 비젼으로부터 너무 많이 벗어나지 않도록 매우 조심스럽습니다. 개발 도중에 근본적인 기획내용을 변경하면 비용과 리스크가 증가하고, 더 큰 문제가 발생할 가능성이 커집니다.

게임 기획에 대한 의견 충돌이 발생하면, 이들은 의견 충돌을 무시하지 않고 빠르게 해소합니다.

핵심적인 기획 요소가 바뀌면, 위대한 게임 개발팀은 팀에 변화된 내용을 명확하게 전달하여 변화의 정당성을 설명합니다.

어떤 사람들은 리더의 일이 "우수한 사람들을 고용해서 옆으로 비켜있기"라고 믿지만, 이는 크게 잘못된 관념입니다. 리더는 쉬지 않고 프로젝트나 팀에 해를 끼칠 수 있는 잠재적인 위협을 감지하여 미리 대비합니다.

3. 위대한 게임 개발팀의 구성원들은 의사 결정 과정에 직접 참여합니다 [1]. 구성원들이 의사 결정 과정에 참여하지 않는다면, 더 큰 문제를 알리는 분명한 징조입니다.

4. 위대한 게임 개발팀은 크런치를 피합니다 [1].

연속된 초과근무는 실제로 게임을 망치는 것으로 보입니다. 적어도 우리의 데이터에서, 크런치는 절대로 게임을 더 낫게 만들지 않았습니다. 우리의 데이터는 어떠한 종류의 초과근무도 어떤 형태로든 도움이 된다는 증거는 눈곱만큼도 찾을 수 없었습니다. 초과근무는 성과와는 음의 상관관계를 나타낸 반면에 부족한 계획, 의사소통 실패, 이직률, 그리고 존중하지 않는 근무 환경과는 양의 상관관계를 나타냈습니다. 특히나 크런치가 자발적이지 않고 의무적일 경우 더 심했습니다.

여러분이 크런치 자체가 게임을 망친다는 우리의 결론을 받아들이지 못하신다면, 크런치가 번-아웃, 직무 몰입 상실, 이직률, 그리고 프로젝트의 불량률을 높인다는 확고한 증거들을 꼼꼼히 살펴보는 게 좋을 것입니다. 크런치가 근로자들의 건강, 생산성(원문), 인간관계, 사기, 직무몰입, 그리고 의사 결정 능력을 망가뜨리는 한편 알콜 남용의 위험성을 증가시킨다는 사실이 대량의 광범위한 경영학 연구를 통해 밝혀져 있습니다.

우리 연구에서 가장 우수한 성과를 나타낸 팀들은 집중력과 응집력이 높고 초과근무는 가장 적게 한 팀들이었습니다.

여러분이 만약 팀의 리더라면, 이런 연습을 해보세요:  팀원들을 3달 동안 주간 40시간 이하로, 생산성과 집중력을 최대한 높일 수 있는 구체적인 목표를 두고서 일하도록 요청해보세요. 정규 근로시간 안에 팀의 생산성을 최대화하기 위해 진정으로 노력해보고 이를 통해 당신이 더 적은 근로시간으로 얼마나 많이 성취할 수 있는지 확인해보세요.

설령 크런치가 효과적이라 하더라도, 당신이 전력을 다하여 40시간 동안의 생산성을 최대화하기 위한 시도도 해보지 않고 팀에게 더 일하라고 하는 것은 볼썽사납습니다.

5. 위대한 게임 개발팀은 해야 할 말을 하기 위해 누구나 위험을 감수하며 나설 수 있는 근무 환경을 만듭니다 [1].

만약 팀의 구성원들이 솔직하게 말하는  불편하거나 위험하다고 느낀다면, 혹은 정치적 후폭풍이 두려워서 솔직하게 자기 생각을 말하는 것을 주저한다면, 여러분은 매우 중요한 것을 놓치고 있는 것입니다. 팀이 타고 있는 보트에 구멍이 뚫려 있더라도 모든 사람이 구멍에 주의하라고 경고하는 것을 두려워한다면, 당신은 구멍을 발견하지 못한 채 보트와 함께 가라앉아 버릴 것입니다.

보트가 가라앉게 두지 마세요. 구멍들이 보수되지 않고 방치되도록 만들지 마세요. 모든 구성원이 정치적인 고려나 두려움 없이 솔직한 의견을 주고받을 수 있고, 서로가 정직한 발언을 하는 것을 존중하는 환경을 만드세요.


6. 위대한 게임 개발팀은 인력 변동과 [1], 필요 때문에 팀원을 늘리는 경우가 아니면 팀 구성원의 변화를 최소화 [2하기 위해 최대로 주의를 기울입니다. 파괴적인 조직 개편도 반드시 피해야 할 대상입니다 [3].

7. 위대한 게임 개발팀은 대인관계에서 발생하는 문제들을 신속하고 전문적으로 해소합니다 [12].
.
내부 갈등을 해결하기 위해 외부 인사의 도움을 받아야 했다면, 문제가 있는 것입니다.

모든 갈등이 나쁘다는 것은 아닙니다. 전문적으로 상호 존중하는 상황에서의 의견 충돌 - 혹은 "창조적 갈등"- 은 포용해 야합니다 [3].

하지만 대립, 사내 정치, 무례한 행동은 [4] 그렇지 않습니다. 생산적인 정치 환경을 조성하고 팀의 집중력이 개인을 괴롭히는 게 아니라, 문제를 해결하는 데 사용되도록 해야 합니다.

8. 위대한 게임 개발팀은 명확하게 정의된 조직의 사명과/이나 가치가 있고, 구성원들은 진심으로 이를 믿고 실현하기 위해 노력합니다 [1]. 사명과 비젼은 여러분이 생각하는 것보다 훨씬 더 중요합니다.

조직의 사명이 아예 없거나, 조직의 사명을 진심으로 믿지 않고 공허한 구호로 생각하고 있다면, 팀원을 모두 불러 모아서 당신의 팀에 맞는 새로운 사명을 정의해 보세요.

9. 위대한 게임 개발팀은 팀원 간 지속적으로 확실한 피드백을 주고받습니다 [1], 작업에 대한 피드백 없이 너무 오랫동안 혼자 일하는 사람이 없도록 주의합니다.

그 일환으로 위대한 팀은 "예측 가능한 관리"방법을 사용합니다 [2]. 즉각적으로 피드백을 주어서 팀 구성원들이 항상 자신이 얼마나 잘하고 있는지 알 수 있도록 합니다. 문제가 있다면 절대로 회의나 성과 평가 따위를 할 때까지 기다리지 않고 발견 즉시 대화합니다.

10. 위대한 게임 개발팀에서는 의도한 목표를 달성하지 못한 경우에도 새로운 아이디어는 칭찬하였습니다 [1].

모든 구성원은 실패할 수 있는 여유가 필요합니다. 특히나 창조적인 실패를 할 수 있어야 합니다.

팀 구성원들은 리더가 뒤를 봐주는 경우 더 적극적으로 새로운 실험을 시도합니다. 실험 정신은 창조력이 발휘되는 토양으로, 배우고 성장하는 팀을 만들기 위해서 필수적인 요소입니다.

최고의 팀은 실수는 기회라는 것을 알고 있습니다.

동시에 조심스럽게 계산된 디자인 리스크사이에서(#1번 항목) 균형을 잡아야 한다는 사실도 알고 있습니다. 창조적 실험이 게임을 완성하거나 게임 플레이의 문제를 해결하기 위한 올바른 영역에서만 수행되도록 유지합니다. 게임 기획의 폐기로 인한 불필요한 낭비를 피합니다.

11. 위대한 게임 개발팀은 각자의 전문 분야에 대해서 높은 기준을 적용합니다.(아트, 기획, 공학, 기타) [1]. 상호 존중하는 협동 작업을 - 코드 리뷰, 기획 리뷰, 아트 리뷰, 기타 등을 포함하여 - 학습할 기회로 생각합니다.

12. 위대한 게임 개발팀은 상호 존중하는 환경을 만듭니다 [1].

일부 주목할만한 경영학 연구에서는 근로자들이 존중받는다고 느낄 경우 직무몰입도가 두드러지게 증가한다는 결론을 나타내었습니다. 직무 몰입도는 프로젝트 성과에 직접적이고 측정 가능한 영향을 끼칩니다.

의견 충돌로 인해 열띤 논쟁이 벌어지는 경우에도 전문적인 대화로 이끌며 상호 존중을 잃지 않도록 합니다.

정중한 자세를 유지하지 않거나, 유지하지 못하는 사람들을 팀원으로 붙잡고 있지 마세요. 팀에 독이 될 뿐입니다.

13. 위대한 게임 개발팀은 팀에 발생하는 개인적 / 인력상의 문제에 즉각적이고 전문적으로 대응하여 올바르게 해결합니다 [1].

14. 위대한 개발팀에서는, 모든 구성원이 위대한 게임을 만들기 위해 헌신합니다 [1].

15. 위대한 게임 개발팀은 구성원들의 의견을 귀담아들어 구성원에게 힘을 실어줍니다[1].

반드시 모든 팀원들의 말을 경청하고 그들의 주장으로 당신의 마음을 바꿀 수 있는 기회를 주세요 - 특히나 당신이 상사일 경우 더 중요합니다.

16. 위대한 게임 개발팀은 철저한 계산으로 최대한 정확한 작업 일정을 추산합니다 [1]. 어려운 작업이지만, 게임 개발 성과에 매우 중요한 영향을 끼칩니다. 또한 정기적으로 일정을 다시 계산하여 일정 예측의 정확성을 높이는 것도 분명하게 긍정적 효과가 있습니다.

17. 위대한 게임 개발팀은 사내 정치를 최소화하고 정치적 속임수 따위는 용납되지 않는 환경을 만들기 위해 분투합니다 [1].

책임감 있는 환경이 상호 비난과 책임 전가가 난무하는 문화로 퇴보하게 만들지 마세요.

팀이 내부 분쟁이나 일삼으며 남의 머리를 밝으려고 해서는 안됩니다. 팀이 위대한 게임을 만드는데 집중할 수 있도록 하세요.

다른 사람의 노력과 성취를 깎아내리는 행동을 하는 사람은 그 어느 누구도 용납하지 마세요 [2].

18. 위대한 게임 개발팀은 실패를 공개적으로 이야기합니다 [1]. 이러한 분위기가 심리적 안정감을 느낄 수 있는 환경을 만드는데 일조합니다.

실패한 아이디어는 성공하는 아이디어의 씨앗이 됩니다. 겉보기에는 나빠 보이는 아이디어가 아주 좋은 아이디어로부터 겨우 몇 보 떨어져 있는 경우도 종종 있습니다.

사람들이 실패한 아이디어를 혼자 짊어지고 간다면, 팀은 새로운 가능성을 잃어버리고 있는 것입니다. 또한 팀이 함정에 빠져있다는 신호일수도 있습니다. 실수는 배우고 공유할 수 있는 기회입니다. 지식을 혼자 감추는 것은 결국 조직에 매우 큰 손실을 초래하게 됩니다. 

19. 위대한 게임 개발팀은 구성원들이 자기 자신만의 목표를 게임 프로젝트 전체의 목표보다 우선시하도록 내버려 두지 않습니다 [1].

팀 구성원들은 절대로 자기 자신의 자아, 경력, 명성이나 소속된 파트 혹은 전문분야를 팀보다 우선시해서는 안됩니다. 팀원들이 팀의 목표보다 이 중 하나라도 우선시하고 있다면, 더 큰 문제가 있다는 징조입니다. 신속하게 해결하고 만약 필요하다면 문제가 되는 팀원을 제거하세요.

위대한 팀은 스스로의 행동에 책임을 지며 동료의 태도나 행동이 팀 전체의 이득에 반할 경우 당당하게 지적합니다 [2].

20. 위대한 게임 개발팀은 모든 구성원의 전문적 기술과 재능의 가치를 인정하며 적극 활용합니다 [12]. 반드시 모든 팀 구성원이 각자 기술과 능력에 적절한 과업과 책임을 맡을 수 있도록 해야 합니다.

21. 위대한 게임 개발팀은 게임 구조나 기획의 핵심을 크게 바꾸는 결정이 필요할 경우, 개발팀에서 관련된 모든 사람이 의사 결정에 참여하도록 합니다 [1].

22. 위대한 게임 개발팀은 충분한 응원을 해줍니다 [1]. 누군가 과업을 잘 수행하면 확실하게 잘했다고 말해주어야 합니다.

23. 위대한 게임 개발팀은 개방적 소통 정책을 사용합니다 [1]. 팀 구성원은 누구나 상급자와 쉽게 대화를 나눌 수 있어야 합니다. 우려되는 사항을 말하고, 피드백을 주고 개인적인 문제에 대해서도 대화를 나눕니다.

24. 위대한 게임 개발팀에서는 모든 구성원들이 자신이 해야 할 일을 명확하게 이해하고 있어야 합니다 [1].

팀 구성원의 과업은 구체적으로 명시되고 분명하게 정의되어있어야 합니다 [2].

각 구성원들이 프로젝트에서 맡고 있는 일과, 해야 할 일이 항상 명백해야 합니다.

25. 위대한 게임 개발팀은 프로젝트의 시작 단계 에서부터 조직 구조와 구성원을 명확하게 정의하고, 그 구조에 변화를 줄 땐 신중하게 의사소통합니다 [1].

26. 위대한 게임 개발팀은 모든 구성원이 스튜디오의 개발 방법론을 잘 훈련하여 따르도록 합니다 [1]. 또한 게임 개발 중에도 지속적으로 수고를 들여 개발 방법을 갈고닦아 개선합니다.

그럼에도 불구하고 우리는 애자일과 애자일-스크럼, 혹은 워터폴 개발 방법 사이에서 통계적으로 유의미한 성과 차이를 발견하지 못 하였습니다 [2]. 개발 방법론 중 성과에 차이를 보인 것은 아무런 개발 방법론이 없는 경우였습니다: 우리의 연구는 팀원이 많던 적던 개발 방법론이 없는 것은 재앙적이라는 사실을 발견하였습니다.

개발 방법론에 보편적인 정답은 없습니다. 스스로 생각하기에 여러분의 팀과 프로젝트에 가장 적절하다고 판단되는 개발 방법론을 선택하세요.

27. 위대한 게임 개발팀은 중요한 사항을 말하지 않고 넘어가지 않습니다 [1]. 방안에 있는 코끼리는 확실하게 지적합니다.

그들은 팀 구성원들이 중대한 문제점을 지적하고 주저 없이 반대 의견을 말할 수 있는 심리적 안정감을 형성합니다.

28. 위대한 게임 개발팀은 팀 구성원들이 배우고, 성장하고, 각자의 기술을 키울 수 있는 기회를 제공합니다 [12]. 위대한 게임 개발팀은 조직 구성원들이 각자의 기술을 성장시키고, 서로 격려할 수 있는 환경을 만듭니다 [3].

이상적인 개발팀에서는 업무를 통해 능력을 키우는 것뿐 아니라 외부 훈련, 강의, 그리고 멘토링도 제공합니다.

29. 위대한 게임 개발팀은 그들이 사용하는 도구가(소프트웨어와 하드웨어 모두) 생산적으로 잘 작동하도록 관리합니다[1]. 사용하는 게임 엔진과 툴체인, 그리고 어셋 파이프라인이 항상 끊김 없이 순조롭게 동작하도록 만듭니다.

30. 위대한 게임 개발팀은 구성원들이 자신의 일일 과업을 스스로 결정할 수 있는 권한을 줍니다 [1]. 또한 과업을 수행하는 담당자가 작업에 필요한 일정을 결정하는 데에도 반드시 참여하도록 합니다 [2]. 

31. 위대한 게임 개발팀은 개발 과정에 발생하는 기술적 변화를 신중하게 관리합니다 [1](특히나 큰 변화일 경우). 새로운 게임 엔진으로 바꾸거나, 사용 중인 게임 엔진의 핵심 기능을 변경하는 것은 큰 리스크를 수반합니다. 위대한 게임 개발팀은 이러한 리스크를 특별히 더 신중하게 관리합니다.

32. 위대한 게임 개발팀은 각각의 마일스톤이나 스플린트의 우선순위를 정할 때 모든 팀원이 참여합니다 [1].

33. 위대한 게임 개발팀은 정기적으로 개인의 관심사를 이야기하고, 서로 질의응답을 하고, 개발 과정에서 발생하는 병목현상에 대해 대화할 수 있는 자리를 만듭니다 [1].

34. 위대한 게임 개발팀의 구성원은 스스로 자신의 일정을 준수하는 책임을 집니다 [1].

하지만 그렇다고 해서 납기일을 죽기 살기로 따지는 건 아닙니다. 일정을 준수하지 못 한 구성원을 십자가에 못 박아 버리지도 않습니다. 때때로 일정 예측이 합리적이지 못 했거나, 기획 요소나 기술적 요소가 계획대로 작동하지 않아서 예상보다 훨씬 많은 시간을 잡아먹는 경우가 있습니다.

납기일 때문에 팀 응집력과 사기를 희생하지 않도록 피하세요. 장기적으로는 팀 응집력과 사기가 일정 엄수보다 훨씬 더 중요합니다. 

35. 위대한 게임 개발팀은 서로 도움을 주는 환경을 조성합니다 [1]. 적극적으로 도움을 주고받는 팀 구성원들에게 보상을 부여합니다. "가라 앉거나 수영하거나"는 철학으로 다그치는 환경에서는 결국 모두가 가라앉아버립니다. 

36. 프로젝트를 시작하는 시점에서 게임의 비젼을 설명하는 일정한 형태의 기획 문서나 명세서를 만드는 건 좋은 생각입니다 [1]. 하지만 결코 이러한 문서가 매일매일 신중하게 만들어나가는 기획을 대체할 수 있는 건 아닙니다. 기획 문서는 프로젝트의 일정 준수와 내부 목표 달성과 양의 상관관계를 나타냈습니다.

37. 위대한 게임 개발팀은 진심으로 서로를 인격체로써 대합니다 [1]. 직원들을 로봇처럼 대하는 행위는 비생산적일 뿐 아니라 실제 ROI를 깎아먹습니다. 

"싸가지 없는 천재"들이 마음대로 하도록 두지 마세요. 아니 "싸가지"들을 내버려 둬서는 안됩니다. 

38. 위대한 게임 개발팀은 개인 실적에 따른 인센티브를 제시합니다 [1]. 

성과에 따른 금전적 인센티브는 놀라울 정도로 적은 효과밖에 없었습니다. 그리고 여러 방식의 인센티브 중에서 유일하게 효과가 있는 방식은 개인 성과 인센티브였습니다. 로열티 수익에 따른 인센티브는 게임 개발 성과에 전혀 영향을 끼치지 않았고, 팀 성과나 메나크리틱 점수에 따른 인센티브도 비슷하게 쓸모없었습니다. 금전적 인센티브를 제시하려면 성과별 지급(PFP) 프로그램이나 비슷한 형태의 개인별 성과에 따른 인센티브를 제시하세요.

39. 위대한 게임 개발팀은 - 특히나 규모가 큰 팀일수록 - 코드 리뷰나 페어 프로그래밍, 코드 상호 평가 체크인 등을 수행합니다 [1]. 이는 프로젝트 일정 준수와 목표 달성과 양의 상관관계를 나타냈습니다. 특히나 규모가 큰 팀에서는 이러한 시스템 도입이 불량률을 낮추고 팀의 프로그래밍 역량을 증진시킨다는 상당한 증거가 있습니다.

40. 위대한 게임 개발팀은 아무리 잘 짜인 계획이라 하더라도 때때로 조정이 필요하다는 사실을 알고 있습니다. 사전에 준비한 계획은 게임 프로젝트가 진화할수록 낡아빠진 계획으로 뒤쳐 져버립니다. 우리의 설문조사에 응답한 최고의 팀들은 마일스톤이나 스프린트 때마다 프로젝트의 진행 상태에 맞추어 새롭게 우선순위를 선정했습니다 [1].

여러분도 알고 있다시피, 경험도 매우 큰 영향을 끼칩니다. 위의 목록의 #36 만큼이나 중요한 영향을 끼칩니다. - 36번 이하의 항목들은 팀의 평균 경력 연수보다 프로젝트 성과와 더 큰 상관관계를 나타내었습니다. 

결론

우리의 연구결과는 게임 개발에 따르는 피할 수 없는 리스크에도 불구하고 우리의 운명을 결정하는 가장 중요한 사항은 스스로의 손에 달려있다는 점을 분명히 보여주었습니다. 의식적으로 신중하게 팀워크를 지원하며 양육하고 키워내는 문화가 그것입니다. 

개발자로서 우리는 코드와 아트 어셋을 최적화하는데 엄청난 시간과 수고를 들입니다. 팀을 최적화하는데 동등한 수준의 수고를 들이지 않을 이유가 없습니다. 저희의 연구가 좋은 팀을 만드는 길을 제시하고, 도움이 되기를 바랍니다.



게임 성과 측정 프로젝트를 위해 설문조사에 참여해주신 수백 명의 전/현직 게임 개발자들에게 감사드립니다. IGDA 프로덕션 SIG 멤버인 Clinton Keith와 Chuck Hoover는 설문 문항 설계에 도움을 주셔서 감사합니다. Kate Edwards, Tristin Hightower, 그리고 IGDA는 설문지 배포에 도움을 주었습니다. Christian Nutt과 가마수트라 편집진 또한 설문지 배포에 도움을 주었습니다. 

추후 게임 개발 성과 프로젝트에 대한 안내를 받고 싶다면 저희 트위터를 팔로우 해주세요 @GameOutcomes


Posted by 역시인생한방
,
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

From Wiktionary:

  1. (computing) In assembly languages, a loop which contains few instructions and iterates many times.
  2. (computing) Such a loop which heavily uses I/O or processing resources, failing to adequately share them with other programs running in the operating system.

For case 1 it is probably like

for (unsigned int i = 0; i < 0xffffffff; ++ i) {}


A tight loop is a loop that loops many times and the loop body has few instructions.

Posted by 역시인생한방
,