로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는 데 있다. 변경에 유연하다. 이해하기 쉽다. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이된다. SRP(Single Responsibility Principle) 단일 책임 원칙 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다. 하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다. 이 원칙을 이해하는 가장 좋은 방법은 이 원칙을 위반하는 징후들을 살펴보는 일일 게다. 징후 1: 우발적 중복 Employee 클래스는 단..
로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 자바 프로그램은 가변 변수 mutable variable를 사용하는데, 가변 변수는 프로그램 실행 중에 상태가 변할 수 있다. 앞의 예제에서 반복문을 제어하는 변수인 i가 가변 변수다. 클로저 프로그램에서는 이러한 가변 변수가 전혀 없다. 클로저에서는 x와 같은 변수가 한 번 초기화되면 절대로 변하지 않는다. 이는 우리에게 놀라운 사실을 알려준다. 함수형 언어에서 변수는 변경되지 않는다. # 불변성과 아키텍처 아키테거를 고려할 때 이러한 내용이 왜 중요한가? 아키텍트는 왜 변수의 가변성을 염려하는가? 경합 race..
로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 좋은 아키텍처를 만드는 일은 객체 지향 Object-Oriented, OO 설계 원칙을 이해하고 응용하는 데서 출발한다. 그렇다면 객체 지향이란 무엇인가? 객체 지향의 본질을 설명하기 위해 캡슐화 encapsulation, 상속 inheritance, 다형성 polymorphism 세 가지 주문에 기대는 부류도 있는데, 이들은 객체 지향이 이 세 가지 개념을 적절하게 조합한 것이거나, 또는 객체 지향 언어는 최소한 세 가지 요소를 반드시 지원해야 한다고 말한다. # 캡슐화 객체 지향을 정의하는 요소 중 하나로 캡슐..
로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 데이크스트라는 진공관 시대에 자신의 경력을 시작했는데, 이 시대는 컴퓨터가 거대하고, 쉽게 손상되며, 느린 데다가 결과마저 믿을 수 없는, 그래서 오늘날의 기준으로 보면 극도로 제한적으로만 사용될 때 였다.이 초창기에는 프로그램을 바이너리 또는 매우 투박한 기계어를 사용해서 작성했고, 입력은 종이테이프나 천공카드와 같은 물리적인 형태를 띠었다. 수정·컴파일테스트를 반복하는 일은 최소 몇 시간에서 며칠이 걸렸다. 데이크스트라는 이처럼 원시적인 환경에서 위대한 발견을 해냈다. # 증명 데이크스트라가 초기에 인식한 문제..
로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. 최초로 적용된 패러다임은 구조적 프로그래밍으로, 1968년 데이크스트라가 발견했다. 데이크스트라는 무분별한 점프(goto 문장)는 프로그램 구조에 해롭다는 사실을 제시했다. 이에 데이크스트라는 이러한 점프들을 if/then/else와 do/while/until과 같은 구조로 대체했다. 객체 지향 프로그래밍은 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. 두 번째로 도입된 패러다임은 구조적 프로그래밍보다 2년 앞선 1966년에 등장했다. 알골 ..
로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. 모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는데, 행위 behavior와 구조structure가 바로 그것이다. 소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다. 불행하게도 개발자는 한가지 가치에만 집중하고 나머지 가치는 배제하곤 한다. 더 안타까운 일은 대체로 개발자가 둘 중 덜 중요한 가치에 집중하여 결국에는 소프트웨어 시스템이 쓸모없게 된다는 사실이다. # 행위 behavior 소프트웨어의 첫 번째 가치는 바로 행위다. 프로그래머를 고용하는 이유는 이해관..
로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다. '아키텍처'는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되는 반면, '설계'는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. 하지만 실제로 이러한 구분은 무의미하다. 모든 고수준의 결정사항에는 그를 지탱하는 세부사항이 존재한다. 저수준의 세부사항과 고수준의 결정사항은 전체 설계의 구성 요소가 된다. 이 둘은 단절 없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의한다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않다. 고수준에서 저수준으로 향..
나는 보통 사용자의 full name을 작성해야 할 때 아래와 같이 string interpolation을 사용했다. struct User { var firstName: String var lastName: String } extension User { var fullName: String { "\(firstName) \(lastName)" } } 그런데 생각해보면 모든 나라에서 full name을 표기할 때 한국처럼 성 + 이름의 표기법을 따르지 않는다. 미국의 경우 일반적으로 이름(first name || given name) + middle name + 성(last name || family name)의 순서에 따라 표기한다. 그럼 여러 국가를 대상으로 서비스하는 앱을 개발중이라면 어떻게 현지화해야..
10월은 엄청나게 바쁜 한달이었다. 10월 13일에는 레츠스위프트가 있었고, 그 다음주 주말이 21일에는 AsyncSwift가 있었다. 그리고 그 다음주인 27일에는 11/11에 예정된 대전의 iOS 커뮤니티인 iDC(iOS Daejeon Club)의 3번째 세미나가 있다. 나는 1회차 iDC 세미나는 참가자로, 2회차에는 스피커로 참여했었다. 작지만 지방에서의 iOS 끈이 잘 이어지기 바라는 마음에 3회차에는 오가나이저로 참여하게 되었다. 그래서 레츠스위프트와 싱크스위프트에 참여하는 의미가 조금 더 컸다. 나는 어느 커뮤니티에 소속된적도, 행사를 간접적으로도 운영해본 적이 없기 때문에 어떻게 해야하는지 보고 배우고 싶다는 마음이 컸기 때문이다. # Let'Swift 2023 짧게 회고하자면 레츠스위프트..
지난 9월 22일(금) ~ 9월 24(일) 2박 3일간 연합 IT 커뮤니티 구성원들이 참가하는 해커톤에 참가했다. 유니톤은 지원서를 작성할 때 소속된 커뮤니티가 있는지 답변하는 칸이 있다. 아무래도 IT 커뮤니티 활동 이력이 있다는 것은 최소한의 개발 능력이 검증되었다고 보는 것 같다. 유니톤에 가보면 실제로는 소속된 커뮤니티가 없는 분들도 많다. 커뮤니티 구성원이 필수 조건은 아니었다. 개인으로만 신청가능하고 지원서에 작성한 관심사를 바탕으로 팀 매칭이 이루어진다. 떨어지지 않을거라고 생각했었는데, 선발 예정 시간 후에도 한참 연락이 없어서 떨어진 줄 알았다.🥶 그냥 연기된 것이었음!! 그리고 원래 네이버메일을 쓰는데 구글폼으로 지원서 쓸 때 구글 계정으로 자동으로 제출된 것 같다. 발표되었다고 문자왔..
