Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- uitableview
- 리팩토링
- Human interface guide
- RxCocoa
- HIG
- uiscrollview
- Protocol
- swift documentation
- Observable
- rxswift
- Xcode
- 리펙토링
- 애니메이션
- Clean Code
- combine
- UITextView
- 클린 코드
- Refactoring
- tableView
- SWIFT
- MVVM
- map
- UICollectionView
- ios
- collectionview
- swiftUI
- 스위프트
- ribs
- 리펙터링
- clean architecture
Archives
- Today
- Total
김종권의 iOS 앱 개발 알아가기
[iOS - swift] Clean Code(클린 코드) - 11. 창발성 (4가지의 규칙을 따라서 클린 코드 유지방법) 본문
Clean Code (클린 코드)
[iOS - swift] Clean Code(클린 코드) - 11. 창발성 (4가지의 규칙을 따라서 클린 코드 유지방법)
jake-kim 2021. 11. 24. 21:11* 창발성: 불시에 솟아나는 특성
4가지의 규칙을 따라서 창발성을 촉진하는 방법
- 착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지
- 모든 테스트를 실행
- 중복을 제거
- 프로그래머 의도를 표현
- 클래스와 메소드 수를 최소화
1. 모든 테스트를 실행하라
- 설계는 의도한대로 돌아가는 시스템을 내놓아야 하는데, 문서로는 시스템을 완벽하게 설계했지만 시스템이 의도한대로 돌아가는지 간단한 방법이 없다면, 소용없는 설계
- 모든 테스트 케이스를 항상 통과하는 시스템은 검증된 시스템이며, 검증되지 않은 시스템은 절대 출시하면 안되는것을 주의
- 테스트가 가능한 시스템을 만들려고 애쓸 경우, 동시에 설계 품질이 높아지는 효과도 존재
- 테스트가 가능한 시스템 - 크기가 작고 목적 하나만 수행하는 클래스
- 테스트가 가능한 시스템일수록 SRP, DIP를 통해 결합도를 낮추고 설계 품질이 높아지는 효과
- "테스트 케이스를 만들고 계속 돌려라"라는 간단하고 단순한 규칙을 따를 경우, 낮은 결합도와 높은 응집력을 얻는 효과 존재
- 테스트 케이스가 있으면, 나중에 구현부 코드를 변경해도 테스트케이스로 검증이 가능하므로, 변경의 유연성이 높아지는 효과
- 테스트케이스가 있으면, 코드를 리펙토링 할 때 자유롭게 변경하고 테스트케이스만 돌려보면 되므로 리펙토링에도 이점이 존재
- 테스트케이스가 있으면, 클래스 기능이 한눈에 들어오는 장점이 존재
2. 중복을 제거하라
- 중복의 의미
- 하나가 변경되면 다른 곳에도 추가 작업이 필요한 상태
- 불필요한 복잡도가 생겨난다는 의미
- 비슷한 코드는 더 비슷하게, 중복은 제거하도록 수정
3. 프로그래머 의도를 표현
- 자신이 이해하는 코드를 짜기보다는 처음보는 사람이 봐도 이해되도록하는 코드를 짤것
- 클래스 이름이나 함수 이름을 정할 때, 블록 내부의 내용을 포함하는 내용으로 이름을 선정
- 표준 명칭을 사용
- Unit test 케이스를 꼼꼼히 작성 (테스트 케이스는 소위 `예제로 보여주는 문서`, 잘 만든 테스트 케이스를 읽어보면 클래스 기능이 한눈에 들어오는 장점)
4. 클래스와 메소드 수를 최소화
- 테스트 실행, 중복 제거, 의도 표현, SRP를 준수한다는 기본적인 개념도 극단으로 치달으면 득보다 실이 많아지는 현상 존재
- 클래스와 메소드 크기를 줄이고자, 조그만 클래스와 메소드를 수없이 만드는 안좋은 현상이 발생할 수 있으므로, "클래스와 메소드 수를 최소화"하는것도 중요
- 독단적인 견해보다는 실용적인 방식을 택하는것이 필요
- ex) 클래스마다 무조건 인터페이스를 생성하라고 요구하는 구현 표준도 좋은것만이 아니므로, 중요하지 않은 클래스에서는 인터페이스를 생성하지 말것
* 참고: Clean Code (로버트 C. 마틴)
'Clean Code (클린 코드)' 카테고리의 다른 글
[iOS - swift] Clean Code(클린 코드) - 12. 냄새와 휴리스틱 (2) (일반) (0) | 2021.11.28 |
---|---|
[iOS - swift] Clean Code(클린 코드) - 12. 냄새와 휴리스틱 (1) (주석, 환경, 함수, 일반) (0) | 2021.11.26 |
[iOS - swift] Clean Code(클린 코드) - 10. 시스템 (Abstract Factory 패턴, DI) (0) | 2021.11.23 |
[iOS - swift] Clean Code(클린 코드) - 9. 클래스 (SRP, Cohesion) (0) | 2021.11.23 |
[iOS - swift] Clean Code(클린 코드) - 8. Unit Test (단위 테스트) (0) | 2021.11.19 |
Comments