어플리케이션 아키텍처 2) 유지보수성(Maintainability)

소프트웨어 개발 이론에서 유지보수성을 고려해서 개발해야한다고 전통적으로 종종 언급된다.
유지보수를 고려하지 않는다면 어떻게 될까?

기능개발에 있어서 단순 동작만을 생각한다면 오히려 유지보수를 고려한 코드보다 더 개발하기 쉽고 빠르다.
어느정도 개발을 경험하다보면 대부분 느끼게 될것이다.
글쓰기에 비유하자면, 당연히 편집이나 교정할 필요가 없이 글을 일단 말이 되는대로 표현하고자 하면 금방 책을 쓸수 있듯이 말이다.


그렇다면 유지보수성을 높이고 싶다면 이론적으로 어떻게 정리 할 수 있을까?

대표적으로 언급되는 것이 낮은 결합(loose coupling)과 높은 응집(high cohesion)이다.

응집도는 모듈이나 클래스 등의 요소간에 서로 속하는 정도를 말한다. 관련 코드는 서로 가까이 있도록 높은 응집력을 위해 노력하고 모든 관련 코드를 가능한 한 가깝게 묶어야한다.

결합도는 서로 다른 모듈이나 클래스등이 서로 의존하는 정도를 나타내며, 모든 모듈이 가능한 한 독립적으로 한다면 결합도가 낮다고 할 수 있다.


앞서 언급한 응집도와 결합도는 객체지향 원칙 (SOLID)와 연결지을 수 있다.

[S] SRP
단일 책임 원칙 (Single responsibility principle)
모든 클래스는 각각 하나의 책임만 가져야 한다. 클래스는 그 책임을 완전히 캡슐화해야 함을 말한다.
[O] OCP
개방-폐쇄 원칙 (Open/closed principle)
확장에는 열려있고 수정에는 닫혀있는. 기존의 코드를 변경하지 않으면서( Closed), 기능을 추가할 수 있도록(Open) 설계가 되어야 한다는 원칙을 말한다.
[L] LSP
리스코프 치환 원칙 (Liskov substitution principle)
“프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라.
자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있다는 원칙이다. 즉 부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 계획대로 잘 작동해야 한다.
자식클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야 LSP를 만족한다.
[I] ISP
인터페이스 분리 원칙 (Interface segregation principle)
한 클래스는 자신이 사용하지않는 인터페이스는 구현하지 말아야 한다. 하나의 일반적인 인터페이스보다 여러개의 구체적인 인터페이스가 낫다.
[D] DIP
의존관계 역전 원칙 (Dependency inversion principle)
의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 것이다. 한마디로 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺으라는 것이다.


객체지향 원칙들을 지킨다고 무조건 좋은 코드라고 보는것은 어렵다.
하지만 좋은 코드는 객체지향적일 코드일 가능성이 높다.
하나하나 원칙을 따라가다보면 결국 좋은 품질의 소프트웨어가 될 수 있다.

항상 정답이라는것은 없지만 이러한부분을 하나씩 지켜나간다면 좋은 설계와 유지보수성이 높은 코드에 가까워지는것은 부정 할 수 없다.

오늘도 다시 새기면서 좋은 코드를 위해 달려가보자.