현재 교내에서 관심있게 듣는 과목 중 하나인 소프트웨어디자인패턴에서는 로버트 C. 마틴의 클린 소프트웨어를 교재로 사용한다. (원래는 원서인 agile software developement로 공부해야 한다..)
1. Agile Menifesto
2000년 경, 많은 소프트웨어 회사가 까다롭고 많은 프로세스 때문에 오히려 방지하려 했던 다양한 문제를 발생 시켰다. 이는 예산 급증과 지연되는 스케쥴 등의 문제를 낳았다. 이에 자극받아 이 분야의 전문가들이 모여 Agile Alliance(애자일 연합)을 이루게 되었고 Agile Menifesto를 선언했다.
- Individuals and interactions over processes and tools
프로세스와 툴보다 개인과 상호작용이 우선이다.
- Working software over comprehensive documentation
포괄적인 문서보다 동작하는 소프트웨어가 우선이다.
- Customer collaboration over contract negotiation
계약 협상보다 고객 협력이 우선이다.
- Responding to change over following a plan
계획을 따르는 것보다 변화에 대한 반응이 우선이다.
애자일 방식에는 여러가지들이 있다. 대표적으로 TDD나 익스트림 프로그래밍과 같이 말이다. 내가 제일 와닿은 말은 "계획을 따르는 것보다 변화에 대한 반응이 우선이다." 였다.
대작 게임을 출시를 생각해보자. 사이즈가 크면 클 수록 게임의 개발기간은 늘어나간다. 그러면 기술 측면이나 트렌드 등이 밀릴 것 같지만 그럼에도 불구하고 출시된 게임의 그래픽이나 트렌드 등이 반영된 모습을 확인할 수 있다.(물론 요즘 안그런 게임도 많은 것 같다...)
이게 가능한 이유는 계획을 따르는 것보다 변화에 대한 반응이 우선시 했기 때문에 가능하다고 생각한다.
물론 이를 이루기 위해서는 앞서 선언된 협력, 상호작용, 동작하는 소프트웨어가 받혀줘야 한다.
2. 객체지향 프로그래밍과 SOLID
객체지향적 설계를 하다보면 위의 사진과 같은 상황을 많이 직면할 수 있다. 프로젝트를 진행하다보면 누구나 코드가 더러워지는 느낌을 지울 수가 없다. 이는 클린 소프트웨어에서 말하는 프로젝트의 악취와 같다. 얼핏 보면 객체지향 프로그래밍은 객체지향 프로그래밍의 장점인 유지보수와 재사용성와는 사뭇 거리가 있어 보인다.
설계에서의 악취
- 경직성: 시스템을 변경하기 어려움
- 취약성: 변경을 하면 시스템에서 그 부분과 개념적으로 아무련 관련 없는 부분이 망가짐
- 부동성: 시스템을 다른 시스템에서 재사용할 수 있는 컴포넌트로 구분하기가 어려움
- 점착성: 옳은 동작을 하는 것이 잘못된 동작을 하는 것보다 더 어려움
- 불필요한 복잡성: 직접적인 효용이 전혀 없는 끼반 구조가 설계에 포함
- 불필요한 반복: 단일 추상 개념으로 통합할 수 있는 반복적인 구조가 설계에 포함
- 불투명성: 읽고 이해하기 어려움
객체지향 프로그래밍이 이러한 잘못된 설계에 대처하기 위해서는 캡슐화, 정보은닉, 상속, 다형성이라는 객체지향 요소를 활용한 SOLID라는 원칙을 지켜야 한다. (SOLID는 아래의 링크를 타면 대충 어떤 것인지 확인 가능하다.)
https://velog.io/@dongwon0103/GDSC-백엔드-스터디-1일차
요약하자면
SRP: 클래스(인터페이스 등등)를 변경하려는 이유는 단 하나 이어야 한다.
OCP: 확장에는 열려있고, 변경에는 닫혀있어야 한다.
LSP: 슈퍼클래스와 파생클래스는 치환될 수 있어야한다.
ISP: 인터페이스는 목적에 맞게 분리되어 있어야 한다.
DIP: 고수준 모듈은 하위 저수준 모듈에 의존하면 안된다.
이러한 SOLID원칙을 잘 지키면 썩은 내가 나는 프로젝트에서 우리를 구원할 수 있을 것이다. (물론 SOLID를 지키는 것조차 힘들다...)
그리고 이를 통해서 객체지향 프로그래밍의 장점인 유지보수성과 재사용성을 높일 수 있다고 생각한다.
3. 그래서 Agile과 객체지향이 무슨 상관?
우리는 고객의 요구사항이 계속 바뀌는 것을 많이 직면했다. 우리의 초기 설계는 어김없이 바뀌기 마련 이다. 책에서는 애자일 개발자는 설계를 가능한 적절하고 명료한 상태로 유지하기 위해 애쓴다고 기재되어있다.
유지보수와 재사용성은 무엇을 뜻하는 것일까? 결국 이는 변화에 대응할 수 있는 기반과도 같다. SOLID에서 OCP도 해당 목적을 달성하기 위한 원칙이다. 또한 OCP를 달성하려면 앞서 살펴본 캡슐화, 상속, 다형성 등의 객체지향 요소들이 적용되어야 하며 다른 원칙들도 준수하려 애써야 한다. 모든 세상의 이치가 그렇겠지만 모두 조금씩 엮여있다.
이러한 객체지향의 원칙을 지키는 행위는 애자일 팀이 프로젝트가 썩지 못하게 하려는 행동과 많이 닮아 있다. 또한 변화에 대응할 수 있는 기반을 마련하는 것도 말이다. 결국 애자일 설계란 과정이지 결과가 아니다. 원칙, 패턴, 그리고 소프트웨어 구조와 가독성을 향상하기 위한 방식의 연속적인 적용이다.
그리고 내 생각에는 함수형 프로그래밍을 하던지, 절차지향 프로그래밍을 하던지 애자일하게 개발할 수 있을 것 같다. 위에 같은 객체지향의 장점 덕분에 애자일 프로세스에 다른 프로그래밍 방식보다 잘 어울리며 실제로도 객체지향 기술 기반으로 진행한다.
4. 실전에서 느낀 점
나는 지금 껏, 자바나 다트 등 객체지향 프로그래밍을 지향해 왔다. 구조화된 객체를 재사용할 수 있는 부분에 큰 매력을 느낀다. 하지만 실제로는 코드를 그냥 내가 생각나는대로 갈기기만 했다. 그러다 보니 처음에는 편할지 몰라도 코드가 점차 경직되어 나중에는 오히려 프로젝트 일정을 저해시키는 큰 독으로 나에게 찾아왔다.
애자일 개발방법론을 처음 들었을 때에는 큰 매력을 느꼈던 것은 내가 객체지향 프로그래밍을 할 때 느끼는 경직함을 어떻게 유연하게 사용하는 것일까라는 궁금즘 때문이였다.(물론 그 때는 SOLID고 나발이고 안지켰다.)
예전에 DDD에서 프로젝트를 진행할 때, 시니어 개발자는 어떻게 일하는지 물어봤더니, 일단 갈기고 나중에 분리나 수정하는 과정을 거친다고 했다. 생각해보니 그 행위는 리팩토링이었다. 나에게도 그러한 리팩토링이 필요함을 느꼈다.
그리고 초기에 설계가 완벽할 수 없다. 책에서도 "한 번 속지, 두 번 속냐"라는 구절이 있다. 한 번의 문제는 그냥 맞고 같은 유형의 문제에 대해서 대비할 수 있어야 한다. 지금까지 나는 해당 문제만 해결하기에 급급했지, 그 다음에도 같은 유형의 문제를 맞이할 수 있다는 점을 간과 했다.
5. 마무리
객체지향 프로그래밍은 정말 좋은 설계방법이다. 하지만 지금까지 나는 객체지향의 장점을 전혀 살리지 못했었다. 이제는 그래도 조금 배웠으니 다른 프로젝트에서는 이를 염두하며 프로그래밍을 해야겠다.
