프로그램을 잘 설계하는 방법은?
좋은 프로그램을 만들기 위해서는 어떻게 해야 할까. 우선 좋은 프로그램 혹은 좋은 소프트웨어가 무엇인지부터 정의해야 할 것 같다.
프로그램을 사용하는 유저 입장이 아닌 개발하는 개발자 측면에서 좋은 프로그램이란, 오류가 적고 유지보수가 간편한 프로그램이라 할 수 있을 것이다. 왜냐면 그래야만 인풋 비용대비 아웃풋이 높기 때문이다. 아웃풋이 좋더라도 버그를 고치기 위해 수많은 인력과 시간과 돈이 들어간다면 무슨 의미가 있겠는가.
따라서 우리는 개발자가 이해하기 쉽고, 변경이 간편하고, 확장에 유연하도록 소프트웨어를 설계해야 한다. 그렇지 않으면 프로그램을 확장할수록 코드가 엉망이 되어 관리하기 어려워질 것이다. 그리고 이러한 이슈를 해결하기 위한 모든 것들이 비용으로 이어진다.
그렇다면 위에서 언급한 변경이 간편하고, 확장에 유연하고, 이해하기 쉬운 소프트웨어는 어떻게 만들까?
이를 건물에 비유하여 설명하면 다음과 같다.
우리는 빌딩을 지을 때 건물 전체의 큰 구조를 설계해야한다. 예를 들어 방의 크기와 개수, 위치등이다.
그러고 나서는 중간 구조를 설계해야 한다. 목적에 맞는 배치와 가구, 전기 설비, 가스 등이 될 것이다.
마지막으로는 디테일한 세부사항을 설계해야 한다. 방의 벽지는 어떤 것을 사용할지, 콘크리트는 어떤것을 사용할지 등이다.
이러한 모든 과정이 잘 설계되어야 좋은 프로그램이라 할 수 있는 것이다.
그중에서 세부사항부터 중간구조를 잇는 원칙을 정리한 것이 있는데, 그것의 앞글자를 따서 SOLID원칙이라고 한다.
SOLID 원칙이란?
2004년 무렵 마이클 페더스(Michael Feathers)가 깔끔한 코드를 설계하는 방법으로 5가지의 원칙을 정리해 앞글자만 따서 만든 원칙이다. 최초 SOLID원칙은 모든 패러다임에 적용되게끔 만들어졌으나, 현재는 객체지향언어에 주로 사용된다.
원칙을 이해하기 쉽도록 풀어서 한 줄로 요약하면 다음과 같다.
| 단일 책임 원칙 (SRP) |
각 소프트웨어 모듈은 하나의(단일) 목적을 가져야 한다. |
| 개방-폐쇄 원칙 (OCP) |
어떠한 기능을 모듈에 추가하기 위해 기존의 코드를 수정하지 않고 코드가 추가되어야 한다. |
| 리스코프 치환 원칙 (LSP) |
자식 클래스의 인스턴스는 부모 클래스의 인스턴스를 대체할 수 있어야한다. |
| 인터페이스 분리 원칙 (ISP) |
인터페이스는 분리하여 불필요하게 메소드를 제공하는 일이 없어야한다. |
| 의존성 역전 원칙 (DIP) |
구체적 구현보다는 추상에 의존해야한다. |
그렇다면 모듈이란 무엇일까? 모듈은 소스코드를 모아놓은 소스 파일이라고 할 수 있다.
어떠한 기능을 위해 모인 코드들이라 생각하면 된다.
정리
우리는 이 원칙들을 잘 적용하여 프로그램을 설계할 필요가 있다. 물론 이 과정이 많은 창의성을 요구하기 때문에 정답이 없고 따라서 시간이 많이 걸리지만, 전체적인 큰 흐름으로 봤을 때 반드시 필요한 구간임은 분명하다.