안 좋은 코드 시리즈 2탄

 

 

 

안 좋은 코드 시리즈 2탄

 

1.잘 변하는 데이터 (mutual data)

데이터가 잘 변한다면, 그것은 안 좋은 코드!!

변수가 변화할 때는 항상 프로그래머가 추적가능한 상태여야 한다.

데이터가 생성된 이후 데이터가 변경되는 것에 신중해야한다.

 

변수가 변경되지 않도록 하는 방법들 

- 변수 캡슐화

- 변경 로직을 별도의 메소드로 분리

- 조회 함수와 변경 함수는 항상 분리

- 필요 없다면 setter 함수는 제거하기 (차후 변경되지 않을거라는 확신이 있다면)

- set 보다는 private set으로 설정하기

- 추후 변경될 여지가 있다면 새로운 인스턴스로 설정하기

(귀찮더라도 한 번 만들어놓으면 나중에 동기화할 때 오류가 줄어든다.)

 

 

2. 뒤엉킨 변경 (divergent change)

[메소드 : 기능], [클래스 : 역할] 처럼 1대1 대응을 지키지 못하는 경우 발생한다.

단일책임원칙(SRP)을 지키지 않아서 생기는 문제이다.

한 클래스에 기능이 여러 개 붙어있으면 하나의 변경이 다른 부분에까지 영향을 준다.

cf) shotgun surgery : 변경이 필요할 때 다른 클래스까지 수정해야하는 상황.

 

 

3. 기본형 집착 (primitive obsession)

복잡한 데이터를 단순한 기본형으로 설정하는 것에 집착하는 것.

복잡한 개념은 기본형 대신 클래스나 구조체를 사용해 해결하는 게 낫다.

ex. 게임에서 HP값, 전화번호나 화폐단위 등은 단순한 문자열에서 끝나지 않고 여러 규칙과 로직을 포함할 수 있다.

 

 

4. switch 문의 반복 (+if문)

switch문은 높은 확률로 리팩토링의 대상이 된다!

객체 지향 프로그래밍의 다형성을 활용한다면 switch와 if문을 줄일 수 있다.

=> switch문 안의 case들을 각 조건에 맞는 클래스로 새로 설정하는 것.

 

 

5. 성의 없는 요소 (lazy element)

불필요하게 쪼개진 클래스, 메소드, 인터페이스 등이 없는지 확인하자.

필요한 것과 필요하지 않은 것을 구분할 수 있어야 좋은 개발자!

 

 

개인과제 ZepDungeon UI 제작

 

* 내일 UI 완성할 때 사용할 레퍼런스 모음

 

contents size fitter

package manager - addressables 설치하면 addressables Groups 사용 가능.

 

 

 

---

내일도 파이팅!!