클린아키텍쳐 1부 1~2장

클린아키텍쳐 1부 1장

설계(design)와 아키텍쳐(architecture)과의 차이

아키텍처: 저수준의 세부사항과는 분리된 고수준의 무언가
설계: 저수준의 구조 또는 결정사항
설계와 아키텍처는 모두 소프트웨어 전체 설계의 구성요소임
이 둘은 단절없이 이어지며, 이를 통해 대상 시스템의 구조를 정의함
개별로 존재할 수 없으며 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있음

==> 설계와 아키텍쳐의 차이는 없다.

좋은 소프트웨어 설계의 목표

필요한 시스템을 만들고 유지보수의 인력을 최소화 하는 것 새로운 기능을 출시할 때마다 비용이 증가한다면 잘못된 설계이다.

무엇이 잘못됐을까?

개발자들은 클린 코드의 중요성을 잊고 있음.

새로 출시할 기능이 계속 생기기 때문에 기존에 있던 코드들은 리팩토링되지 않아 결국 생산성이 0으로 가게 됨
소프트웨어 개발의 단순한 진리 => 올바른 방향으로 제대로 가는 것이 가장 빠른 길이다.
처음부터 재설계하는 것이 해답이라고 생각하겠지만, 자신을 과신한다면 재설계하더라고 똑같이 엉망이 됨.

결론

우리는 아키텍쳐의 품질을 고민해야한다.
아키텍쳐를 고민하기 위해서는 무엇이 좋은 아키텍쳐인지를 알아야한다.
비용을 최소화하고 생산성은 최대화할 수 있는 아키텍쳐를 만들기 위해서는 아키텍쳐의 본질과 속성을 알아야 한다.

클린아키텍쳐 1부 2장

소프트웨어 개발자는 행위와 아키텍쳐라는 2가지 가치를 제공한다.
개발자는 두 가지 모두를 반드시 높게 유지하는 책임을 갖는데, 행위에만 집중하고 아키텍쳐는 배제한다.

행위

프로그래머는 이해관계자를 위해 수익을 창출하거나 비용을 절약하도록 함.
이를 위해 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 도움
그리고 이러한 코드를 작성하고, 요구사항을 위반하면 디버거를 열고 문제를 고침

아키텍쳐

소프트웨어의 목적을 추구하려면 변경이 쉬워야 함.

즉, 이해관계자(기획자)가 기능에 대한 생각을 바꾸면, 변경사항을 간단하고 쉽게 적용할 수 있어야 함.
이때 드는 어려움은 변경의 범위에 비례해야 하며, 형태와는 관련이 없어야 함.
새로운 요청사항이 발생할 때마다 변경이 힘든 이유는 시스템의 형태와 요구사항의 형태가 맞지 않기 때문.

문제는 아키텍쳐다. 아키텍쳐가 특정 형태를 다른 형태보다 선호할수록, 새로운 기능을 이 구조에 맞추는 게 힘듬.
따라서 아키텍쳐는 독립적이어야 한다.

아키텍쳐를 위해 투쟁하라.

소프트웨어 개발자는 소프트웨어를 안전하게 보호해야할 책임이 있다.
개발팀, 관리팀, 마케팅팀, 운영팀...등등 모든 팀들은 회사에서 가장 중요하다고 믿는 스스로의 가치를 위해 투쟁함.
똑똑한 개발팀은 뻔뻔함을 무릅쓰고 다른 이해관계자들과 동등하게 논쟁하며 이러한 투쟁에서 정면으로 맞서 싸움
아키텍쳐가 후순위가 되면, 결국 시스템 개발 비용과 시간이 많이 듬.
만약 위와 같이 아키텍쳐가 후순위가 됐다면, 개발팀은 스스로의 가치(아키텍쳐)를 위해 충분히 투쟁하지 않았다는 뜻임.

느낀 점

현업에서 인턴을 하면서 느낀 것은 각자 팀마다 고충이 있다는 것이다. 예로, 기획팀은 프로덕트의 개선과 발전을 위해 신기능을 기획하거나 기존의 있는 기능을 변경하는 것에 가치를 두고 투쟁한다면, 개발팀은 신기능 개발을 하는 것도 좋지만 신기능 개발보다 기존에 있는 기능이나 코드의 품질을 개선하는 리팩토링을 우선 순위에 두는 것이 필요하다. 실제로 인턴생활을 하면서 신기능 개발 일정에 쫓겨 리팩토링을 후순위로 한 적이 정말 많았다. 그래서 책에서 말한 것처럼 새로운 기능을 추가하는 시간이 더욱 더 오래 걸렸고, 결론적으로 나쁜 아키텍쳐를 만든 것이다. 앞으로 리팩토링도 개발팀의 가치로 생각하며 투쟁해야겠다는 생각이 들었다.