일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- unity
- 2023 Gaming
- 2023 구글 클라우드
- 언리얼 5
- 1일차
- 스포일러 주의
- 리팩터링 4장
- URP
- 주식단테
- 2023 게이밍
- 전주비빔 라이스 버거
- JavaScript
- 스즈메의 문단속
- 산토리 하이볼
- 리팩터링 3장
- GenAI
- 주식
- 구글 컨퍼런스
- 이득우의 언리얼 프로그래밍 1
- 언리얼5
- 448일선
- 작계훈련
- 224일선
- 2023 게이밍 인 구글 클라우드
- 112일선
- 리팩터링
- 상계9동
- shader
- 공부
- 이득우의 언리얼 프로그래밍1
- Today
- Total
개발 이야기 안하는 개발자
Good Code, Bad Code (9) _ 코드를 재사용하고 일반화할 수 있도록 하라 본문
가정을 주의하라
데이터가 있는지 항상 확인해야 한다.
주석으로 알려줘야 가정이 있는 경우엔 메소드의 명명이나, 기능을 제한해서 명시해야 한다.
또는 호출하는 쪽에서 강제로 알 수 있도록 Assert 같은 에러 메세지를 띄우는 방식을 추가해야한다.
전역 상태를 주의하라
코드를 재사용하기 때문에 데이터가 변질될 가능성이 높다.
재사용될 가능성이 있다면 정적을 지우고 공유 상태에 의존성을 주입해야 한다.
static 을 사용했던 이유는 대부분 해당 인스턴스를 가지고 있지 않았을 가능성이 있다.
그래서 필요한 곳에 인스턴스를 필요로 하는 메소드를 제작하고, 거기에 주입을 하게하는 방식으로 해결하면 된다.
class ShoppingBasket
{
static void AddItem(Item item)
{
items.add(item);
}
static void List<Item> getItem()
{
return items;
}
static List<Item> items;
}
Class Viewitem
{
Item item;
ViewItem(Item Initem)
{
item = InItem;
}
AddItemToBasket()
{
ShoppingBasket::AddItem(item);
}
}
Class ViewBasket
{
void DisplayBasket()
{
ShoppingBasket::getItem(); ...
}
}
ShoppingBasket에 있는 items는 외부의 Viewitem 클래스에 의해 변경이 된다.
외부에서 이걸 사용하려다가 문제가 생길 가능성이 있다.
그래서 의존성을 주입하도록 로직을 수정한다.
class ShoppingBasket
{
void AddItem(Item item)
{
items.add(item);
}
void List<Item> getItem()
{
return items;
}
List<Item> items;
}
Class Viewitem
{
Item item;
ShoppingBasket basket;
ViewItem(Item Initem, ShoppingBasket Inbasket)
{
item = InItem;
basket = Inbasket;
}
AddItemToBasket()
{
basket.AddItem(item);
}
}
Class ViewBasket
{
ShoppingBasket basket;
ViewBasket(ShoppingBasket Inbasket)
{
basket = Inbasket;
}
void DisplayBasket()
{
basket.getItem(); ...
}
}
이렇게 수정하면 해결된다.
이후, 사용할땐 개별 바스켓을 제작하고, 개별 ViewBasket을 제작해서 주입하는 방식으로 제작하면 된다.
기본값 반환을 주의하라
디폴트값을 반환하는건 해당 메소드나 클래스를 사용하는 외부 개발자에게 문제를 일으키기 쉽다.
디폴트값을 사용하게 되는 경우가 생길 수 있기 때문이다.
Enum Class ETest
{
A = 0,
B,
C,
D
}
class Test()
{
TOptional<ETest> testValue;
ETest GetTestValue()
{
if(testValue.IsSet())
{
return testValue;
}
return ETest::A;
}
}
GetTestValue() 를 호출해서 반환값을 받았는데, A를 받았다고 가정해보자.
그럼 외부에서 사용하는 개발자가 A값에 대한 경우까지 고려해서 개발을 진행했다면 문제가 생긴다.
오류 상황으로 값이 정의되기 전인데도 값을 반환했기 때문이다.
위 같은 상황에선 반환값을 Optional (Nullable) 을 추가하던가, 아니면 Enum값에 None같은 예외값을 추가해서 문제인 상황을 명시해줘야 한다.
함수의 매개변수를 주목하라
예를들어 Text의 Color값만 필요하다면, 함수를 정의할때 매개변수로는 Color값만 받도록 해야한다.
Text를 전체 다 요청한다면 해당 메소드는 Text를 알고있는 경우에만 사용할 수 있다.
즉, Color만 따로 바꾸는 기능이 없기때문에 해당 메소드는 사용할 수 없다.
재사용성을 고려할때 필요한 값만 요청하는 것이 옳다.
제네릭(템플릿)의 사용을 고려하라
기능을 확장성을 고려한다면 클래스나 메소드의 기능에 맞춰서 변수 유형을 다양하게 사용가능하도록 제네릭을 사용하는 것이 좋다.
'Book > Good Code, Bad Code' 카테고리의 다른 글
Good Code, Bad Code (8) _ 코드를 모듈화 하라 (0) | 2025.09.27 |
---|---|
Good Code, Bad Code (7) _ 코드를 오용하기 어렵게 만들라 (0) | 2025.09.27 |
Good Code, Bad Code (6) _ 예측 가능한 코드를 작성하라 (0) | 2025.09.24 |
Good Code, Bad Code (5) _ 가독성 높은 코드를 작성하라 (0) | 2025.09.16 |
Good Code, Bad Code (4) _ 오류 (0) | 2025.09.14 |