팀원과 협업 시 좋은 코드를 만들기 위한 기본 원칙들을 돌이켜보며

너는 if문을 왜 그렇게 써?

그리고 중첩된 else if, 

왜 좋지 못한 코드를 쓰는거야?

switch문을 사용할 생각은 없는거야?

 

 

여기에서 아, 내가 급하게 기능 구현만하려했었다라는 반성 연이어,

협업 시 팀원의 분노게이지를 상승시키지않을만한 

좋은 코드란 것에 대해서 돌이키며 유념하고자 정리하는 글이다.

 

소프트웨어에서 기본 원칙이나  클린 코드 등 책들을 읽으며 알았던 좋은 코드에대해서 정리해보면,

 

 

코드를 읽는 사람이 쉽게 이해할 수 있어야하는 “가독성” ⇒ 변수명, 함수명, 들여쓰기, 구조가 직관적이어야한다

Readability  ⇒ 읽기 쉬운가?

 

코드 수정이나 기능 추가 시 다른 부분에 영향을 최소화해야하는 “유지 보수성”

Maintainability ⇒ 고치기 쉬운가?  

 

중복 코드 제거, 모듈화, SRP(단일 책임 원칙) 등을 지키면 좋다.  

 

기능을 추가할 때 기존 코드를 추가하지 않고 확장만으로 가능한 구조, 확장성확장에는 열려있어야하고 수정에는 닫혀있어야한다.

Scalability(확장성) / Extensibility(확장 가능성)

 

Scalability (확장성)쉽게 말해 “사용자가 늘어나도 버틸 수 있냐” 하는 개념

.웹 서비스가 처음엔 100명 접속, 나중엔 10만 명 접속해도 서버 증설이나 아키텍처로 대응 가능해야한다는 것

 

Scalability ⇒ 성능 측면에서의 확장 가능성새로운 기능을 추가하거나 기존 기능을 수정할 때

Extensibility ⇒  새로운 요구사항/기능 추가에 대한 구조적 확장

 

 

소프트웨어 설계의 코딩 원칙

• 솔리드 원칙 SOLID (객체지향 설계의 대표 원칙)
  1. 단일 책임의 원칙 Single Responsibility Principle (SRP)
  2. 개방 폐쇄의 원칙 open/closed Principle (ocp)
  3. 리스코프 치환의 원칙 Liskov Substitution Principle (LSP)
  4. 인터페이스 분리 원칙 Interface Segregation Principle (ISP)
  5. 의존성 역전의 원칙 Dependency Inversion Principle (DIP) 

 

1. 단일 책임의 원칙 ⇒ 하나의 클래스는 하나의 책임만 가져야한다.
2. 개방폐쇄 원칙 ⇒ 확장에는 열려있어야하고 수정에는 닫혀있어야한다.
3. 리스코프 치환 원칙 ⇒ 자식 클래스는 부모 클래스를 대체할 수 있어야 한다. (뭔 말이냐면 상위 타입의 객체를 하위 타입 객체로 바꿔도 프로그램의 정상 동작이 깨지지 않아야 한다.)
4. 인터페이스 분리 원칙 ⇒ 인터페이스는 사용하지 않는 메서드에 의존하지 않아야한다.
5. 의존성 역전의 원칙 ⇒ 고수준 모듈은 저수준 모듈에 의존하지 않아야한다.

 

클린 코드의 핵심 원칙

소프트웨어 개발에서 흔히 말하는 좋은 코드는 clean code나 코딩 원칙 같은 기준에 따라 평가되는데,

1. 중복은 피하라. DRY ⇒ don’t repeat yourself
2. 함수는 작고 하나의 작업만하라
3. 명확한 이름을 사용하라
4. 주석은 최소화하되, 꼭 필요한 경우는 써라.
5. 데이터 구조보다 인터페이스를 드러내라.

 

즉,  좋은 코드는 “사람이 읽기 쉽고 바꾸기 쉬운 코드”다.

 

첫 문장에 말한 것을 다시 가져오면 

if else if 중첩문은

• 가독성: 조건문이 길어짐
• 유지보수성: 역할 하나 추가하려면 코드를 수정해야함
• 확장성: 역할별 로직이 많아지면 난장판

1. 가독성 저하 - 조건이 많아질수록 코드를 따라가기가 힘들고 구조 파악이 어렵다.
2. 유지보수 어려움 - 새 조건을 추가하거나 변경할 때 기존 로직을 깨기 쉽다.
3. 디버깅 어려움 - 어디서 분기 되었는지 추적하기 힘들어진다.
4. 중복된 조건 평가 - 비효율적인 흐름 제어로 이어질 수 있다.

⇒ 개선 방법으로

1. 조건 분기 함수화
2. 객체 매핑 방식 사용

 

 

그리고 많이 사용하는 것들 중,

switch문과 if문의 성능 차이

• 사실 성능 차이는 미세함
• js 엔진이 최적화 해주기 때문에 if-else와 switch는 거의 동일하다.
• 그러나! 문자열 비교 가 많은 경우엔 switch가 조금 더 최적화될 수 있다.
• 핵심은 성능보다 가독성과 구조화에 있다.if문을 사용하는 대신, switch문을 사용하는 것이 더 최적화스럽다라는 것.
• 예를 들면 에러 핸들링 같은 경우에 상태 에러 코드가 뜰 시 클라이언트한테 보여주는 화면에

 

조건이 늘어날수록 if else 나 switch → 객체 매핑이나 함수 분리가 좋다.

로직 분기 없이 핸들러 객체로 묶는 구조는 매우 추천

 

가독성을 위한 개선 방법

• 객체 기반 매핑
• 함수 분리
• enum 패턴 응용 ⇒ 하지만 이건, 최근에 권장되지않는다한다. (트랜스파일 결과 문제, 트리 쉐이킹 불가, 런타임 값 생성)  
• switch 문은 역할 분기, 상수 값 비교 처럼 값 중심의 로직에 적합
• 논리적 우선 순위가 중요한 경우

 

 

그럼 switch문이 아닌, if else if가 더 적합할 때는 각 조건이 독립적인 값이 아니라,

우선순위 를 갖는 경우 else if 가 더 직관적이다.

 

 

항상 좋은 코드를 쓰라는 사수님, 많이 따끔해도 알려주시는 하나하나가 오늘도 더 넓게 생각하게하는 힘을 기를 수 있게해주셔서, 옆에 있어서 감사할 따름이다.