[💬] 내 코드가 몇 천 줄 넘어간다면...

[건포도극혐(222.237)]

1. 한 스크립트에서 여러 기능을 담당하고 있다.

예를 들어서 플레이어를 이동시키는 코드를 만들었다면, 플레이어를 이동시키는 로직에서 충돌처리, 체력 관리, 등 여러 일을 담당하고 있다. 그래서 여러 스크립트, 여러 컴포넌트로 나눠서 하는 걸 추천한다. 

예를 들면, PlayerMovement, PlayerHealth, PlayerAnimation, PlayerInteraction 이렇게 나누는 걸 추천한다. PlayerMove, PlayerJump, PlayerGroundCheck 이런 식으로 너무 자세히 나누지 않아도 된다. 

2. public static

다른 스크립트의 변수를 가져오려고 public static을 사용하는 건 매우 안 좋다. GetComponent()를 사용해서, 컴포넌트를 캐싱(변수 저장)를 저장해서 component.MyField 이런 식으로 접근하는 걸 추천한다. 그리고 한 컴포넌트에서 다른 컴포넌트의 변수를 자주 수정하는 것도 좋지 않다. 함수를 사용하거나, 속성을 사용하게 해서 수정할 수 있게 하는 방법이 좋다.

3. switch

switch(WeaponType)

{

    case Weapon.Pistol:

        name = "glock17";

        fireRate = 0.2f;

        damage = 10f;

        break;

    case Weapon.Rifle:

        name = "ak47";

        fireRate = 0.1f;

        damage = 20f;

        break;

    case Weapon.Sniper:

        name = "awp";

        fireRate = 1.5f;

        damage = 70f;

        break;

    ...

}

이러면 새로운 무기를 추가하게 될 때마다, 케이스는 늘어난다. 즉 작성해야 하는 코드는 늘어나게 된다. 무기 시스템에 정확도가 추가 되면 수정하기 너무 빡세다. 객체(클래스)를 만들어서 관리하는 게 더 편하고 깔끔하다. 예를 들면,

class Gun 

{

     public string name;

     public float damage;

     public float fireRate;

     //생성자

} 

이렇게 만들고

public Gun pistol = new Gun("glock17", 10f, 0.2f);

이렇게 만드는 게 훨씬 낫다.

또 아이템으로 예시를 들면, 

public class ItemStack

{

    public Item Item;

    public uint Count;

    public ItemType ItemType;

    

    public IInteractive Interaction;

    

    public ItemStack(Item item, uint count, ItemType type)

    {

        Item = item;

        Count = count;

        ItemType = type;

        

        switch(type)

        {

            case ItemType.Food:

            Interaction = new Food();

            break;

            

            case ItemType.Weapon:

            Interaction = new Weapon();

            break;

            

            

            case ItemType.Item:

            Interaction = new Item();

            break;

        }

    }

}

이렇게 하지 말고

public class ItemStacm

{

    public abstract void Use();

}

public class Wepaon : Item

{

    public int Damage

    

    public override void Use()

    {

        //공격

    }

} 이렇게 상속을 이용해서 하는 걸 추천한다.

코드가 몇 천 줄 안 넘어 가기를.

[동네백수(9jmmxi58m4af)]

저도 한스크립트에서 몇천줄 넘어가는데 왜 안좋은지 알수있을까요 - dc App

[ㅇㅇㅇ(location6483)]

30의 룰이란 법칙이 있어요. 유명한 법칙임.
한 함수가 30줄 이하, 한 클래스는 30개 함수 이하.
그러므로 한 파일&클래스는 900줄이 넘지 않아야 함.
https://dzone.com/articles/rule-30-%E2%80%93-when-method-class-or
- dc App

[ㅇㅇㅇ(location6483)]

좀 더 설명해보면, 크기 코드에 따라 어느정도면 서브시스템으로 둘지에 대한 것도 파악할 수 있음요. 30개의 코드라인, 30개의 클래스, 30개의 패키징이라면 시스템의 총 코드라인은 81만줄이 됩니다. 유지보수성이 잘 짜여진 어떤 코드도 81만줄이 되면 시스템 분리가 필요하다는 근거 확보도 가능해요. 미시적으로 보면 하나의 함수가 30라인을 초과하면 리팩토링해야하고, 하나의 파일에 1천 라인이 넘어가면 고려해봄직해요. 이유는 유지보수때문입니다. - dc App

[익명(comb2001)]

코드는 작동하면 그만이긴 한데 한 스크립트에 코드가 너무 많아지면 수정해야 할 부분이 생겼을 때 찾기 번거로워짐 스크립트 내 코드 결합도가 치솟을 가능성도 높아지고, 결합도가 높으면 소위 말하는 '한 군데 고쳤는데 열 군데에서 버그가 터지는' 사태가 자주 일어남

[레알팜(lottohelp)]

[익명(116.127)]

그넘의 룰이고 법칙이고 다 지키는 흥겜 하나라도 가져와바라. 좆망겜에선 찾기 쉬울듯

[ㅇㅇㅇ(location6483)]

그렇게 말하면 대화가 안됨요 - dc App

[Indie 1(39.113)]

프갤에서 오셨군요~

[퍅셔미(wvvwvwwvw)]

수단과 목적을 혼동하면 오버엔지니어링에 빠지기 쉬운것이야

[Indie 2(222.232)]

상남자는 그런고 모른다. 코딩은 흐름대로

[Indie 3(218.151)]

내 플레이어 스크립트는 1500줄이 넘어가는데 어쩌냐...

[211214(tomatoss)]

[Indie 4(1.239)]

상속이 뭐야?

[Indie 5(121.65)]

배고프다