간단한 소프트웨어 책을 읽고 나서 회사에서 했던 일이 생각났습니다.
어느 시점에서 우리는 아키텍처에서 강력한 종속성 오류를 해결하기 위해 많은 노력을 기울였습니다. 그간 했던 프로젝트 중 노티피케이션 프로젝트가 꽤 기억에 남는다. 이 프로젝트는 메시지 채널을 통해 사용자에게 메시지를 전달하는 프로젝트입니다. 일부 구성 요소는 Slack, 이메일, MMS 및 기타 메시지 채널일 수 있으며 프로젝트에서 MMS를 수신할 수 없는 경우 카카오톡으로 메시지를 보내십시오. 카카오톡으로 메시지를 읽지 않으면 이메일로 전송됩니다. 호환성을 생각하고 있습니다.
추가할 수만 있고 업데이트할 수 없는 코드 만들기
“복잡성은 감옥이다”라는 책에서 흥미로운 일화를 들려줍니다. 직장을 그만둔 사람들에게 코드에 대한 질문을 받은 에피소드가 있었는데, 부끄럽게도 저도 그런 경험이 있었습니다. 다른 사람이 작성한 코드를 누군가가 유지 관리하는 경우 복잡한 코드가 작성된 의도를 알 수 있는 방법이 없습니다. 당시 자바는 언어였고 줄 수는 약 760,000줄의 코드였던 것으로 기억합니다.
우리가 만든 소프트웨어가 만들어지면 우리가 만든 코드를 수정하여 기능을 계속 구현합니다. 이때 문제는 기존 코드의 의도와 앞으로 작성할 코드를 모두 이해해야 하므로 복잡도가 증가한다는 점이다. 내 생각을 설명하기 위해 텍스트가 점점 길어짐에 따라 복잡성의 징후가 분명해집니다. 그래서 내가 무엇을해야하니? 프로젝트는 코드를 수정하는 것이 아니라 추가하는 방식으로 진행되어야 합니다. 노티피케이션이 대표적인 사업입니다. 메시지 채널이 추가될 때마다 개발자는 다른 내용을 수정하지 않고 추가할 메시지 채널의 기능 구현에만 집중하면 됩니다. 이때 디자인 패턴과 객체지향 프로그래밍이 필요하다.
간결하고 엄격한
Spring 기반의 Backend를 개발한 사람들은 JPA의 구현 기술을 싫어했습니다. 그 이유는 단순함과 엄격함 때문입니다. JPA라는 도구는 데이터베이스의 개체 및 특정 열을 쉽게 매핑하는 데 도움이 되는 ORM 프레임워크입니다. 내가 JPA를 그토록 싫어하는 이유는 JPA의 느슨함으로 인한 문제를 경험했기 때문이다.
JPA는 다양한 매핑 관계를 유연하게 생성할 수 있습니다. 개발자는 이러한 유연성을 활용하여 특정 부분에 갇혀 JPA를 지원하기 위해 QueryDSL이라는 것을 만들었습니다. 우리는 우발적인 복잡성 속으로 점점 더 깊이 빠져듭니다. 사실 이 시점에서 간단한 Native SQL 쿼리를 작성하는 것이 편리함에도 불구하고 일부 사람들은 JPA에서 막히는 것을 보았습니다. (블로그에서 JPA만 검색해도 튜토리얼이 많이 있습니다.)
단순함이 너무 엄격하다는 것을 이해할 수 있습니다. 코드는 엄격해야 합니다. DATA-JDBC는 앞서 언급한 JPA의 단점을 해결하는 것으로 보이는 ORM 프레임워크입니다. 이 도구는 사용하기가 너무 쉬워서 5세 미만 어린이용 장난감을 연상시킵니다. 단순함의 엄격함은 개발자가 복잡성에 얽매이지 않도록 합니다. 좀 더 복잡한 것을 작성할 때는 Native SQL Query 작성을 유도하세요.
—
개발은 인터넷에서 콘텐츠를 보고 복사하는 데 그쳐서는 안 됩니다. 진지하게, 당신은 그것을 단순하다고 부를 만큼 충분히 코드에 사로잡혀 있어야 합니다. 이 부분은 이 책에서 한숨에 설명되는 것 같다.