https://www.youtube.com/watch?v=dJ5C4qRqAgA&t=1589s
개발자의 숙명은 무엇일까?
적은 비용을 드려 요구사항을 지속적으로 반영하는 것 아닐까?
그러기 위해 무엇이 필요할까?
당장 빠르게 개발할 수 있는 능력과 이를 지속적으로 유지할 수 있도록 시스템을 관리할 수 있는 능력이 필요할 것 같다.
일반적으로 당장 빠르게 개발하는 것은 상대적으로 쉽지만 이를 지속적으로 하는 것은 어렵다. 시스템은 기능이 추가될수록 더욱 복잡해지고 시간이 지날수록 기술은 노후화되기 때문이다.
그렇다면 개발자가 주력으로 집중해야할 부분은 당장 빠르게 개발하는 것보단 이러한 상태를 지속적으로 유지할 수 있도록 시스템을 관리하는 것이다. 그렇다면 지속적으로 유지보수하기 좋은 시스템을 만드려면 어떻게 해야 할까?
결국 변경이 쉬워야 한다. 결론적으로 개발자에 숙명은 변경이 쉬운 코드를 작성하는 것.
어떻게 하면 변경이 쉬운 코드를 작성할 수 있을까? 객체지향, DDD, 의존성관리 등등 개념들은 결국 위 질문을 해결하기 위해 나온 것들 아닐까.
조영호 님 강의도 결국 변경을 잘 관리하는 방법에 대해 다루고 있는 것이라는 생각이 들었다.
변경을 잘 관리하기 위해 객체 설계 시 협력 기반으로 설계를 해야 하고, 적절한 협력이란 적절한 의존성과도 밀접하게 연관되어 있다. 그리고 변경이 쉬운 구조를 만들기 위해선 결국 요구사항에 대한 이해가 필요하다. 요구사항에 대한 이해를 바탕으로 객체지향 방법론을 통해 구현해야 한다.
그렇다면 내가 작성한 코드가 변경이 쉬운 코드라는 것을 어떻게 진단할 수 있을까?
위 강의에선 이 질문에 대한 힌트로써 의존성을 보라고 한다. 너무 많은 연관관계가 연결되어 있거나, 페키지간 순환의존이 보이면 뭔가 이상하다는 것을 눈치 채라는 것이다. 이상한 것을 눈치 채었다면, 개선을 위해 추상화된 클래스를 설계하거나, 인터페이스를 통한 의존성 역전을 구현하거나, 새로운 개념으로 분리하라고 말한다. 이 방법들은 항상 어느한쪽이 정답이 될 수 없고 트레이드오프 해야한다. 트레이드오프에 대한 기준은 단연 "변경이 쉬운가?" 로 잡아야하고 이를위해 도메인에대한 이해가 필수적일 것이다.
댓글