일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 클린코드
- DesignPattern
- OOP
- 의도
- POP
- 객체지향프로그래밍
- fp
- 네이밍
- 인터페이스
- 의존성
- IOS
- 협업
- iOS프로그래밍
- 개발
- 부스트코스
- 이름
- SWIFT
- interface
- 디자인패턴
- Solid
- 문법
- CleanCode
- 클린소프트웨어
- 개발자
- 함수형패러다임
- 아이폰프로그래밍
- Swfit
- 고차함수
- 함수형프로그래밍
- protocol
- Today
- Total
목록Clean Code (7)
밤에 쓴 코드
클래스 클래스는 데이터와 연산으로 이루어진 코드 블럭이다. 깨끗한 클래스, 응집도높은 클래스에 대한 고민을 해보자 클래스는 작아야한다 클래스를 만들 때 첫번째 규칙은 크기이다. 클래스는 작아야한다. 하지만 얼마나 작아야 하는지가 중요하다. 여기서 말하는 크기는 물리적인 크기보다는 책임의 크기이다. 책임을 적게 가진다는 것을 어떻게 표현할 수 있을까? 클래스의 이름은 클래스의 책임을 표현한다. 이름에 드러나는 책임이 모호하거나, 많은 책임을 내포한다면, 여러 책임을 가진 클래스일 확률이 높다. 책임을 분리하는 것은 클래스가 변경될 수 있는 이유를 분리하는 것이고, 관심사를 분리하는 것이다. 응집도 클래스에는 인스턴스 변수가 많아서는 안된다. 또 메소드는 적어도 하나이상의 인스턴스 변수를 내부에서 사용해야한..
단위테스트 개념 테스트가 가능한 (최소)단위-모듈로 나누어진 소프트웨어 내에서 결함을 찾고 기능을 검증하는 활동 TDD (테스트 주도 개발) 실제 코드를 직성하기 전에 실패하는 테스트 코드를 작성한다. 실패는 하지만 컴파일은 성공할 수 있게끔 작성한다. 테스트를 통과할 정도의 간단한 코드로 실제 코드를 작성한다 위의 3가지 원칙을 차례대로 지키면서 개발을 진행하며, 사이클을 계속적으로 수행한다. 그러면 테스트는 어떻게 작성해야 할까? '테스트 코드는 깨끗하게 작성하라' 라고 책에서 강조를 한다. 더러운 테스트 코드는 어떤 피해를 주는 지 한번 보자. 테스트 코드도 코드이다. 실제 코드가 변하게 되면, 테스트코드도 같이 변해야 한다. 테스트 코드가 더럽다면 또는 복잡하다면, 늘어가는 테스트 ..
객체와 자료구조 객체는 일을 한다 . 자료구조는 자료를 저장한다. 이 둘을 적절한 상황에 사용하기 위해 한번 공부해보자 우리는 객체를 디자인함에 있어서 , 객체의 내부의 변수를 private로 감추어둔다. 외부의 객체가 내 변수에 의존하지 않게 하기 위해서 이다. 변수의 수정에 외부에 영향을 주지 않게 하기 위해서, 외부에서는 내 변수에 대해 아무것도 모르게 하려고 더 좋은 구조를 위해서 변수의 수정에 자유로울 수 있기 위해서이다. 객체는 내부의 구현을 숨기고 *객체가 무슨 일을 하는지 * 만을 공개한다. 자료구조는 내부의 변수(자료)를 공개하고 별다른 동작을 하지 않는다 struct MyPoint { private var x: Int private var y: Int func getX() -> Int ..
형식맞추기 코드형식은 의사소통형식이다. 가독성 수준은 유지보수 용이성과 확장성에 밀접하게 영향을 준다. 코드는 일차적으로 구현을 생각하고 , 기능이 수행되는 것에 만족해왔었다. 그 이유중 하나는 왜 깨끗하게 코드를 짜야할까? 의문을 가져본 적이 없었고, 그 이유를 몰랐었다. 왜냐면 난 학생이었고, 언제나 혼자 소프트웨어를 개발해왔었으며, 한번 완성된 소프트웨어에 기능을 수정하고, 기능을 추가하는 등, 변경되는 요구사항에 대해서 소프트웨어를 지속적으로 수정해 본 적이 없었다. 깨끗한 코드 ? 좋다는 건 알겠다. 깨끗한 코드 그게 기능구현의 중요성에 비해 노력을 투자할 가치가 많이 있는가? 를 항상 의심해왔다. 우리가 사용하는 소프트웨어는 대부분 단 한명의 개발자가 완성하지 않고, 많은 유능한 개발자들이 함..
주석 주석은 기껏해야 필요악이다. - 로버트.C.마틴 책을 읽기전까진 , 주석은 읽기 편하게 설명을 해주고 있다고 느꼈고, 꼭 필요하다고 생각했었다. 코드를 읽는 것보다 주석을 읽으면 빠르게 이해되고, 이해가 안되는 코드도 주석을 읽고 보면 술술 읽혀 나갔던 적이 많았다. 하지만 이 책에서는 주석은 코드의 실패라고 한다. 내가 주석이 유용하다고 느낀 건 주석이 유용해서가 아니라 코드가 의도를 표현하지 못하고 복잡하고 명료하게 작성되서라는 것을 알게 되었다. "주석이 필요한 코드는 잘못 작성된 코드이다" 라고 생각된다. // 이름을 가져오는 메서드 func get() -> String { return self.name } 위와 같이 주석이 메소드의 동작을 설명해주는 주석을 보는 것보다는 func getNa..
함수 함수는 작게 작게 작게 길어지면 읽기힘들다 인덴트가 2단 이상이면 읽기 힘들다 한가지만 해라 큰개념을 하는 메소드는 더 작은 개념을 수행하는 메소드들로 나누어야한다. 내부에서 의미있는 이름의 동작로 분할해 낼 수있다면 , 한가지 일을 하지 않는다는 증거이다. // 안좋은 예 func getCoffee()->Coffee{ let coffeeMenu = readLine() // 커피 메뉴를 입력 받는 의미있는 동작을 내부에 포함하고있다. let coffee = Coffee(menu:coffeeMenu) return coffee } // 사실상 어떤 커피를 만들지 입력을 받고 출력을 하고있다. TO문단으로 확인해보자 메소드명 하기위해서 , 코드 의 동작을 해야한다. func getCoffee(menu:S..
의미있는 이름 의도를 분명히 밝혀라 명확한 이름이 좋다 짐작하기 쉽게 함축성을 가진 코드는 의도를 숨긴 코드이다. 단순성과 함축성은 다르다. // 함축적 -> 무슨 일을 하는지 구체적으로 드러나지 않은 이름 func getList() -> [String] { } // 짐작하기 쉬운 이름 func getNameOfFriendsList()->[String]{ } 올바른 정보 유사한 개념은 유사한 표기법을 사용한다. func add(_ item:Int ){ // 배열에 추가하는 로직 } func append(_ item:Int ){ // 배열에 추가하는 로직 } 같은 기능을 수행하나 표기가 다른 건 잘못된 정보전달의 예 이다. 널리쓰이는 단어를 다른 의미로 사용하는 것도 옳지않다 func getFriendLi..