좋은 프로그래밍의 원칙

 

현업에 치여 '구현'에 집중하다 보면 어느새 작업 쳐내기에 몰두하고 있는 나 자신을 발견하게 된다.

이러한 와중에 잊지 말아야 할 몇 가지 좋은 프로그래밍 원칙에 대해 복기 겸 작성해보았다.

 

DRY (Don’t repeat yourself) - 중복을 피하라

동일한 코드를 반복하지 말라는 원칙. 중복은 유지보수를 어렵게 하고 버그를 발생시킬 확률을 높인다.

반복되는 코드는 함수, 모듈, 클래스 등으로 추상화한다.

 

KISS (Keep It Simple, Stupid!) – 단순하게 만들어라

코드는 최대한 단순하고 명확하게 작성해야 한다는 원칙.

복잡한 코드는 이해하기 어렵고, 버그가 발생하기 쉽다. 불필요한 최적화나 과도한 설계는 지양하고 가독성 있는 코드를 작성한다.

 

YAGNI (You Aren’t Gonna Need It) – 필요할 때까지 만들지 마라

지금 당장 필요하지 않는 건 구태여 미리 구현할 필요없다는 원칙.

미래를 너무 대비해 코드를 추가하면 복잡성만 늘어나고 실제로 쓸 일이 없을 수 있다. 즉, 현재 필요한 기능에 집중해야 한다.

 

단일 책임 원칙 (Single Responsibility Principle, SRP)
하나의 클래스나 함수는 오직 하나의 책임만 가져야 한다는 원칙.

하나가 여러 역할을 가지고 있으면 변경에 취약하고 유지보수도 힘들어진다. 책임(역할)별로 코드를 분리한다.

개방-폐쇄 원칙 (Open/Closed Principle, OCP)
코드는 확장(개방)에는 열려 있고, 변경에는 닫혀 있어야 한다는 원칙.

상속, 인터페이스, 추상화 등을 활용해 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있도록 설계해야 한다. 

최소 결합, 최대 응집 (Low Coupling, High Cohesion)

각 모듈이나 클래스를 서로 의존성(결합도)을 최소화하고 관련된 기능끼리 응집도를 높게 설계해야 한다는 원칙.

코드가 단단해지고 변경에도 용이해진다.

구현 세부사항 감추기 (Information Hiding)

외부에는 필요한 정보만 공개하고 내부 구현은 감춰야 한다는 원칙. 이렇게 하면 내부를 변경해도 외부에 미치는 영향을 줄일 수 있다.

 

데메테르 법칙 (Law of Demeter)
객체는 자기 자신과 직접적으로 연관된 객체와만 상호작용해야 한다는 원칙.

애매한 관계끼리 연결지어 복잡한 관계성을 만들지 말고 직접적인 관계에서만 통신하도록 해야 한다. 그래야 변경에서 발생하는 연쇄 효과를 줄일 수 있다.

유지보수자를 위한 코드 작성
코드는 항상 다른 사람이 읽고, 고칠 수 있다는 점을 염두에 두어야 한다는 원칙. 구체적인 예로는 주석, 명확한 네이밍, 일관된 스타일(컨벤션) 등이 있다.

 

최소 놀람의 원칙 (Principle of Least Astonishment)
코드는 예상대로 동작해야 하며, 읽는 사람을 놀라게 해서는 안 된다는 원칙. 표준 명명 규칙과 관습을 따르고, 기대 밖의 부작용은 피해야 한다.

조기 최적화 금지 (Avoid Premature Optimization)
코드가 제대로 동작하는지 먼저 확인하고, 정말 느릴 때만 데이터를 근거로 최적화하라는 원칙. 무턱대고 성능 개선에 집착하면 코드가 복잡해질 수 있다.

코드 재사용 (Code Reuse)
이미 검증된 코드를 재사용하면 개발 속도와 신뢰성을 높일 수 있다는 원칙. 코드를 재사용하면 불필요한 중복을 줄이고, 유지보수가 쉬워진다.

관심사의 분리 (Separation of Concerns)
각각의 기능(예: UI, 데이터, 비즈니스 로직 등)은 서로 분리하라는 원칙. 각 부분을 독립적으로 관리하면 개발, 테스트, 수정에 용이해진다.

변화 수용 (Embrace Change)
요구사항은 언제든 바뀔 수 있다는 원칙. 변화에 유연하게 대응할 수 있도록 설계하고, 위의 원칙들을 지키면 변화에 강한 코드를 만들 수 있다.

 

 

참고 자료
https://www.artima.com/weblogs/viewpost.jsp?thread=331531

The Principles of Good Programming