iOS with BeePeach

프로그래밍을 하면 가장 많이 하는게 이름을 짓는 것이다. 이 장에서는 이름을 잘 짓는 간단한 규칙 소개하고 있다. 의도를 분명하게 밝혀라 이름은 변수, 함수, 클래스의 존재 이유 수행 기능 사용 방법 위 세가지에 모두 답할 수 있어야 한다. public func getThem() -> [[Int]] { var list1: [[Int]] = [] for x in theList { if x[0] == 4 { list1.append(x) } } return list1 } 이 코드는 코드 자체가 어려운 코드는 아니지만 이해하기 힘들다. 그 이유는 아래의 정보를 이미 알고 있다고 가정하고 있기때문이다. theList에는 뭐가 들어가 있는지 theList에 0번째 값이 무엇인지 4는 무슨 의미인지 리턴하는 list..

프로그래밍의 유행이나 스타일은 조금씩 바뀌기 때문에 이 책에서 설명하는 원칙이 지금과 잘 맞지 않는 부분도 있기 마련이다. 따라서 이 책에 나온 내용이 절대적은 아니다. 핵심은 팀에서 서로 동의하는 합리적인 원칙을 세우기 위한 소통이 중요하다! 깨끗한 코드 우리 모두 시간에 쫒겨 일단 돌아가는 코드를 짠다. 그리고 안돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한다. 나중에 다시 정리하겠다고 다짐한다. 하지만 결코 나중은 오지 않는다. 프로그래머라면 누구나 나쁜 코드가 업무 속도를 늦춘다는 것을 알고 있다. 기한을 맞추기 위해서는 나쁜 코드를 작성할 수 밖에 없다고 느낀다. 하지만 나쁜 코드를 양산하면 오히려 기한을 맞추지 못한다. 처음에는 빨라 보이지만 뒤로 갈수록 생산성이 나오지 않고 ..

used to ~ 하곤했다, go go 가, 가 go on 쭉 가 awful: 끔직한 nothing but: 딴게 아니라. I’m a student (저 학생이에요.) I’m nothing but a student. (나 딴게 아니고 학생이에요.) lean on: 기대는건 면에 기대는거니까 on을 쓴다. everlasting: 끊임없는, increase 천천히 증가 , soar 가파르게 치솟는 느낌

이번 챕터에서는 3가지에 대해서 알아본다. 소프트웨어 컴포넌트란? 컴포넌트의 구성요소 컴포넌트를 결합하여 시스템을 구성하는 방법 컴포넌트란? 컴포넌트는 시스템의 구성요소로 배포할 수 있는 가장 작은 단위이다. 루비에서는 gem 닷넷에서 DLL 스위프트는 컴파일 언어이기 때문에 바이너리 파일의 결합체가 하나의 컴포넌트이다. 잘 설계된 컴포넌트라면 독립적으로 배포 가능해야 한다. 100p에서부터는 컴포넌트의 역사에 대해서 설명한다. 컴포넌트 응집도 클래스들을 어떤 컴포넌트에 넣을것인지?에 관한 세 가지 원칙이 있다. REP: Reuse/Release Equivalence Principle CCP: Common Closure Principle CRP: Common Reuse Principle REP: 재사용 ..

좋지 못한 코드를 작성하면 아키텍처가 큰 의미가 없게 된다. 반대로 코드가 좋아도 아키텍처를 엉망으로 만들면 큰 의미가 없다. 좋은 코드로 좋은 아키텍처를 정의하는 원칙이 필요한데 이를 SOLID 원칙이라고 한다. SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하고 이 클래스를 서로 결합하는 방법을 제시한다. 여기서 의미하는 클래스는 함수와 데이터를 결합한 집합이다. SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조를 다음과 같이 만드는 것이다. 변경에 유연하다. 이해하기 쉽다. 많은 시스템에 사용될 수 있는 컴포넌트의 기반이 된다. SOLID의 간단한 설명 SRP(Single Responsibility Principle): 단일 책임 원칙 각 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다..

패러다임이란 프로그래밍을 하는 방법으로 대체적으로 언어에 독립적이다. 패러다임은 어떤 프로그래밍 구조를 사용할지 언제 이 구조를 사용하는지 결정한다. 현재까지는 구조적(Structrued), 객체지향(Object-Oriented), 함수형(Functional) 프로그래밍 이렇게 3가지 패러다임이 존재하고 아마 세 가지 외에 다른 패러다임은 존재하지 않을 것이다.

정리하면서 읽지 않으면 다 까먹어 버리기 때문에... 정리해가면 읽는 Clean Architecture 사실 정리하면서 읽어도 까먹는건 똑같지만 핵심을 다시 보기엔 편하므로 읽으면서 정리합니다. 빨리 가는 유일한 방법은 제대로 가는 것이다. - Robert C. Martin 서문 아키텍처 규칙은 동일하다. 근본적으로 다른 시스템들이 왜 비슷한 아키텍처 규칙을 공유하는 것일까? - 소프트웨어 아키텍처의 규칙은 다른 모든 변수에 독립적이다.

안녕하세요 BeePeach입니다 :) 오늘 공부해볼 내용은 Swift5부터 새롭게 추가된 Error handling 방식인 Result입니다. (작성하다가 다 날아가서 다시 작성하는 ㅠㅠ) Result를 이해하기 위해서는 Enumeration과 Associated Value 그리고 Generic을 정확하게 이해하고 있어야 합니다. 기존에 사용하던 throws는 이 함수, 메서드, 클로저, 생성자가 Error를 던질 수 있다는 것을 나타냈지만 어떤 형식의 Error가 전달될지는 알려주지 않았습니다. 그래서 do-catch문에서 Error를 처리할 때 패턴 매칭을 이용하거나 타입 캐스팅을 하는 방식으로 Error를 특정한 뒤에 처리해야 했습니다. 이 방식이 완전 나쁜 방식은 아니지만 문제는 컴파일 타임에 형..