좋은 코드란 뭘까?

내일배움캠프 16일차 TIL

📌 좋은 C# 코드 작성 기준

좋은 코드는 "잘 돌아가는 코드"가 아니라, "잘 읽히고, 쉽게 변경 가능한 코드" 

기계가 아닌 사람을 위해 짜야 하는 것.
내가 아니라 나중에 유지보수하는 다른 개발자를 위한 글쓰기라고 생각해야 한다!

앞으로의 협업을 위해 다시 한 번 정리하면서 리마인드해보기

 

명확한 네이밍

(이름만 봐도 기능이 떠오르게)

 

• 변수명, 메서드명, 클래스명 모두 명확한 역할을 나타내야 한다.
• 짧게 쓰려고 a, b, c 같은 이름을 쓰지 않는다.

// 나쁜 예시
int a; // 이게 뭘까?

// 좋은 예시
int playerCurrentHp;

 

일관된 스타일

클래스명, 변수명, 중괄호 {} 스타일 등 통일

메서드 단일 책임

한 메서드는 한 가지 일만 처리

• 한 메서드 안에 이동, 공격, 저장 다 들어있으면 안 된다.
• 한 문장으로 자연스럽게 설명 가능해야한다. (예) "이 메서드는 플레이어를 이동시킨다."

// 나쁜 예시
void HandlePlayer()
{
    Move();
    Attack();
    Heal();
    SaveData();
}

// 좋은 예시
void MovePlayer() { }
void AttackPlayer() { }
void HealPlayer() { }
void SavePlayerData() { }

주석은 "왜"

"무엇을"보다 "왜"에 대한 주석을 달기

주석은 '왜 이런 코드를 작성했는지'를 알려줘야 한다.

// 나쁜 예시
// 체력을 0으로 만든다
player.hp = 0;

// 좋은 예시
// 플레이어가 죽었을 때 체력을 강제로 0으로 설정한다
player.hp = 0;

접근 제한자 사용

 

• 필요한 최소한만 공개해야 한다.
• 내부 데이터는 private로 숨기고, 필요한 기능만 public으로 열어준다.

// 나쁜 예시
public int hp; // 아무나 수정 가능

// 좋은 예시
private int hp;
public int GetHp() { return hp; }

 

예외 처리

예상 가능한 오류에 try-catch 처리

 

• 실패할 가능성이 있는 작업(파일 저장, 네트워크 요청 등)은 항상 대비해야 한다.
• 프로그램이 중간에 터지지 않게 하려면 필요하다.

try
{
    SaveFile();
}
catch (IOException e)
{
    Debug.LogError("파일 저장 실패: " + e.Message);
}

 

데이터 캡슐화

상태를 직접 수정하지 말고, 메서드를 통해 변경

LINQ 활용

반복문 대신 선언적(간결한) 표현 사용

 

📌  SOLID 설계 원칙

SOLID는 객체지향 프로그래밍의 다섯 가지 핵심 원칙
좋은 코드 구조를 만들기 위해 필수적이다.

원칙	의미	C# 적용 예시
S: 단일 책임 원칙 (SRP)	클래스는 하나의 책임만 가져야 한다	PlayerManager는 플레이어 관리만 담당
O: 개방-폐쇄 원칙 (OCP)	확장에는 열려 있고, 수정에는 닫혀 있어야 한다	새로운 무기 추가 시 Weapon 클래스 수정 X
L: 리스코프 치환 원칙 (LSP)	하위 타입은 상위 타입을 대체할 수 있어야 한다	class Sword : Weapon은 Weapon처럼 사용 가능해야
I: 인터페이스 분리 원칙 (ISP)	사용하지 않는 메서드는 인터페이스에 넣지 않는다	IDamageable, IHealable 분리해서 필요만 상속
D: 의존성 역전 원칙 (DIP)	구체적인 클래스가 아니라 추상(인터페이스)에 의존	ILogger logger = new ConsoleLogger(); 처럼 사용

💡 느낀 점

• 오늘 정리하면서, "한 번 짠 코드를 다시 보지 않을 거야"라는 생각은 정말 위험하다는 걸 느꼈다. 코드는 결국 계속 고치고, 늘려야 하는 것이다. 그러려면 처음부터 "구조가 튼튼한 코드", "이해하기 쉬운 코드"를 작성해야 한다. 특히 팀 프로젝트에서는 내 코드가 다른 사람에게도 읽혀야 하니까 더욱 그렇다.
• 내일은 메서드를 짤 때마다 "이건 단일 책임을 지키고 있나?"를 꼭 점검해보자!
• 팀원이 이렇게 작성해줬으면 좋겠다고 생각하며 작성해보기!

.

❗ 기억하고 싶은 포인트

• 좋은 코드는 누가 봐도 "어, 이거 무슨 기능이네" 싶어야 한다.
• SOLID 원칙은 코드 건물의 튼튼한 뼈대.
• 코드를 짤 때마다 "내일 아침에 이걸 처음 보는 내가 유지보수할 수 있을까?"를 스스로 질문하자.