협업하기 힘든 사람

  • 자신의 의견을 잘 전달하지 못하는 사람
  • 의견충돌이 있을 시 호전적으로 대화를 하는사람
  • 주위에 부정적인 감정을 유발시키는 사람
  • 일정관리를 못하는 사람
  • 오만한 사람

의견충돌의 원인

  • 설계
  • 코드리뷰
  • 미래 예측

의견충돌의 대처

  • 원칙과 철학에 관한 내용이라면 결론을 내려하지말자
  • 다양한 의견을 수렴하는 자세를 갖자
  • 철학과 정의가 타당하다고해서 무조건 옳지 않을 때도 있다. 현실의 한계점을 생각해보자
  • 겸손한 태도로 대처하자

글을 쓰게된 이유

이미 사용되고 있는 변수명이 바뀌거나 함수가 변경되었을 때 많은 오류가 발생하게되고 하나하나 수정해야 한다. 그럴때 사용하면 좋을 단축키를 찾아보았다. 커서가 자동으로 오류가 발생한 지역으로 이동하게 된다. (물론 컴파일 에러만 해당한다)

상속의 교과서 유닛에 대해 구현해보려고 한다.

 

일단 구체적인 사양이 정해지지 않아 내 상상을 좀 가미해야 하는데 만약 사양이 다르게 된다면 그때 수정하는 것으로 하고 일반적인 상황을 상상하여 구현해보도록 하자.

 

상속에 필요한 키워드(예약어)는 abstract, virtual, override, static 등 하나하나 알아보자.

 

1. abstract(추상적인)

메소드앞에 사용할 수 있으며 이 키워드를 사용할 경우 클래스도 abstract키워드를 붙여야한다.
이 예약어를 붙일 경우 뜻 그대로 추상적인 클래스가 되며 이 클래스로는 선언을 하지 못하게된다.

이 클래스를 상속받게 되면 무엇을 구현해야 하는지 알 수 있는 인터페이스 역할을 한다.

(참고로 클래스와 인터페이스의 다른 점은 단 하나의 클래스만 상속받을 수 있으며, 여러개의 인터페이스를 상속 받을 수 있다)

추상 함수는 추상 클래스 내에서 구현할 수 없으며 자식 클래스에서 그 내용을 반드시 구현(override)해야 한다.

당연히 그 내용을 자식 클래스에서 접근해야 하므로 접근자를 private으로 선언할 수 없다. (public과 protected만 가능)

2. virtual (가상의)

abstract와 비교해보자.
비슷한점은 상속받은 클래스 역시 이 함수를 재구현(override) 할수있다.
다른점은 이 함수자체를 해당 클래스에서 반드시 구현을 해야한다. 그리고 해당 클래스에 추상함수가 없이 가상함수만 있다면 클래스앞에 abstract나 virtual키워드를 붙일 필요가없다. 일반적인 클래스에서 가상함수를 선언 할수 있다. 
이 클래스를 상속받은 클래스는 이 가상함수가 이미 부모 클래스에서 구현되어 있으므로 추상함수와 다르게 구현하지 않아도되고 물론 구현해도된다!
만약 자식 클래스에서 이 함수를 구현할때 부모클래스의 함수도 이용하고싶다면 base키워드를 사용하면된다.

마찬가지로 그 내용을 자식 클래스에서 접근해야하므로 접근자를 private으로 선언 할수 없다. (public과 protected만 가능)

3. override (덮어 씌우다)

위의 예약어로 생성한 추상함수나 가상함수를 실제로 구현하는 키워드이다. 부모가 선언한 추상함수를 구현하지 않으면 에러가 나므로 깜빡하고 구현을 안하고 넘어갈 일은 없다. 그러니 특정 클래스를 상속 받는 클래스라면 해당하는 함수들은 구현이 되어있다고 상정후 코딩을 해도된다. 
가상함수를 오버라이딩한다면 부모가 구현한 함수는 사라지고 해당 클래스의 함수만 작동하게되는데 여기서 base키워드를 사용해 부모가 구현한 가상함수를 호출 할 수있게된다.

4. static (정적인)

조금 뜬금 없긴 하지만 클래스간의 상속관계에서 자주보여서 넣어봤다.
이 키워드는 변수앞에 사용하면 단 메모리상에서 사라지지 않는 단 하나의 변수가 만들어진다.
일반적인 변수는 상속을 받으면 변수가 갖는 공간만큼을 해당클래스에서 다시 확보하게 된다.
Unit 클래스의 hp를 상속받은 휴먼과 플랜트는 각각 각자의 hp를 갖게 되는 것이다.
하지만 static으로 선언한 변수는 해당 변수를 가지고있는 클래스들이 모두 한곳의 변수를 바라보게된다.
어떤 한 클래스가 static변수를 수정하게 된다면 모든 클래스의 변수들이 영향을 받게된다.
꽤 위험해보이고 객체지향성을 무너뜨린다. 멀티 스레드 환경에서 락이나 세마포어를 열심히 공부했던 것도 떠오른다. 심지어 메모리상에서 사라지지도 않아 권장 하지 않는다. 
하지만 이게 또 꽤 편리할 때가 있다. 지금당장 떠오르진 않지만 어쨋든 알아 두는걸로!
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public abstract class Unit
{
    protected static int playerIndex = 0;
    protected int hp;
    protected abstract void InitUnit();
    protected virtual void Attack() { }
}
 
public class Human : Unit
{
    // 반드시 구현해야함
    protected override void InitUnit()
    {
         hp = 10;
    }
 
    // 선택적 구현
    protected override void Attack()
    {
        // 부모클래스의 함수 실행
        base.Attack();
    }
}
 
public class Plant : Unit {
    protected override void InitUnit()
    {
        hp = 5;
    }
}
cs

 

맨땅에서 게임 개발을 하기위해 가장 힘든 점은 아마 같이 작업할 팀원을 구하는 것이 아닐까 싶다...

그래도 언제 공중분해 될지 모르지만 성격좋은 사람들과 함께 게임을 제작하기로 했다. 

그것도 일본인 디자이너와 홍콩인 기획자 이렇게 셋이서 말이다. 완전 글로벌...

모두 돈없는 젊은이들이라 최대한 돈이 안드는 방향으로 구축하기로했다.


공동 작업 공간

일단 서버로 이용 할 수있는 컴퓨터가 없다. 하지만 모두의 작업을 공유할 수 있는 공간이 필요하므로 이것저것 알아보았다. 

기본적인 자료공유(회의록이나 참고자료등)는 프로그래머가 아니더라도 쉬운 작업환경에 무료 공간도 넉넉한 구글 드라이브 (무료 15GB)를 사용하기로 했다. 

그리고 가장 중요한 버전관리는 두말할 것 없는 강력한 git을 사용하기로 하고 레포지토리에 대해 고민해봤다.

 

1. GitHub

github은 뭐 워낙 유명하니 제일먼저 찾아보았다. 대학생때도 써보았고 지금도 github의 많은 오픈소스들을 이용하고있으니!

그런데 큰 문제점이있었다. 무료 저장소 공간이 1기가밖에 안된다... 소스파일만 관리하면 문제없겠지만 디자인도 데이터도 버전관리한다면 확실히 부족하겠지... 라고 생각하며 일단 킵해놓고 다른 방법을 찾아보았다.


2. 구글 드라이브 위에 레포지토리를 올려 사용

구글 드라이브의 설치형 어플리케이션을 이용해 드라이브 폴더를 원격 저장소 처럼 이용하는 방법이다. 이미 구글 드라이브는 확보했고 더이상의 서버가 필요하지 않기에 잠깐 생각해 보았지만 왠지이거 꺼림칙했다. 혼자 이용한다면 문제는 없을 것 같은데 원격 저장소(로컬에 있는 구글 드라이브 이지만)에 push를 한 후 바로 적용 되는 것이 아닌 구글 드라이브에서 한번더 동기화를 하기 때문이다... 충돌 처리를 어떻게 해주는지 까지는 찾아 보지 않았지만 일반적이지 않은 방법 같기에 다른 방법을 알아보았다.

3. AWS + 설치형git

만약에 nas가 있었다면 서버위에 설치형 git을 사용 하는 방법도 있었을 것이다. 하지만 서버를 빌려 설치형git을 운용해보는건 어떨까? 마침 설치형git은 리눅스상에서 밖에 돌아가지 않는듯 하기도 하고. 그리고 처음엔 좀 번거로워도 나중에 어디가서 어필도 할 수 있을 것 같다. (자랑용) 하지만 조금 복잡한 요금때문에 일단 킵!


4. GitLab

엄청 괜찮은 저장소를 찾았다! 무료 용량도 무려 10GB에 private으로 프로젝트를 진행하는것도 가능하다.리소스를 전부 버전관리하는것은 힘들어보이지만 큰 이미지라던가는 따로 구글드라이브로 공유하면 어찌어찌 될것같은 느낌이 들었다. 조금 서버가 불안정하다는 이야기도 있었지만 지금 그런거 가릴때가 아니기 때문에 이걸로 결정.


+ Recent posts