김종권의 iOS 앱 개발 알아가기

* 냄새와 휴리스틱: 파틴 파울러의 "Refactoring"에서 "코드 냄새"를 표현하여 주의해야하는 코드 사항들에 대해 나열한 것에 더하여 저자 로버트 C.마틴의 생각을 더한 것 이름 서술적인 이름을 사용할 것 소프트웨어가 진화할 경우 의미도 변하므로 선택한 이름이 적합한지, 성급하지 않고 신중하게 고를 것 로버트 C마틴에 의하면, 소프트웨어 가독성의 90%는 이름이 결정 주석을 통해 추가 설명을 하려고 하기전에, 먼저 서술적인 이름으로 코드를 구성하는 방향으로 구현하면 다 읽지 않아도 유추하기가 쉬워져서, 코드 생산성에도 긍정적인 영향을 부여 RIGHT - 서술적인 이름으로 인해 함수의 이름만 보고도 내용을 예측할수 있는 형태 private let ballCountToStrike = 10 privat..

* 냄새와 휴리스틱: 파틴 파울러의 "Refactoring"에서 "코드 냄새"를 표현하여 주의해야하는 코드 사항들에 대해 나열한 것에 더하여 저자 로버트 C.마틴의 생각을 더한 것 일반 이름과 기능이 일치하는 함수 이름만으로 분명하지 않은 함수를 사용하면 매번 문서를 뒤적여야 하므로 처음부터 함수 이름과 기능을 확인할 것 WRONG - 5초인지, 5주인지, 5일인지 알 수 없는 상태이므로 더욱 애매한 함수 let newDate = date.add(5) RIGHT - 함수의 이름이 명확한 경우 let newDate1 = date.addDaysTo(5) 역할 분담에 대한 의존성을 제대로 할 것 ex) 임직원들의 report를 만드는데, page가 지정된 크기 pageSize만큼 커지면 페이지를 초기화 시키는..

* 냄새와 휴리스틱: 파틴 파울러의 "Refactoring"에서 "코드 냄새"를 표현하여 주의해야하는 코드 사항들에 대해 나열한 것에 더하여 저자 로버트 C.마틴의 생각을 더한 것 주석 쓸모없는 주석 주석은 빨리 낡으므로 쓸모 없어진 주석은 `의식`하여 재빨리 없애야 코드를 그릇된 방향으로 이끌지 않게하므로 주의 중복된 주석 코드 내용과 중복되는 주석 내용을 피할 것 WRONG - 코드 내용과 중복되는 주석 i += 1 // i 증가 WRONG - 메소드 시그니처만 달랑 기술하는 주석 (parameter의 내용만으로 충분히 의미가 표출되지만, 불필요한 주석) /** (summary 부분) > Description 부분 - Parameters: - sellRequest: Sell을 하기위해 필요한 리퀘스트..

* 창발성: 불시에 솟아나는 특성 4가지의 규칙을 따라서 창발성을 촉진하는 방법 착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지 모든 테스트를 실행 중복을 제거 프로그래머 의도를 표현 클래스와 메소드 수를 최소화 1. 모든 테스트를 실행하라 설계는 의도한대로 돌아가는 시스템을 내놓아야 하는데, 문서로는 시스템을 완벽하게 설계했지만 시스템이 의도한대로 돌아가는지 간단한 방법이 없다면, 소용없는 설계 모든 테스트 케이스를 항상 통과하는 시스템은 검증된 시스템이며, 검증되지 않은 시스템은 절대 출시하면 안되는것을 주의 테스트가 가능한 시스템을 만들려고 애쓸 경우, 동시에 설계 품질이 높아지는 효과도 존재 테스트가 가능한 시스템 - 크기가 작고 목적 하나만 수행하는 클래스 테스트가 가능한 시스..

시스템을 만드는 것 도시를 만드는 것과 동일한 것이며, 도시를 세운다고 했을때 혼자서 도시를 만들기는 불가능하지만 각 수도 관리 팀, 전력 관리 팀, 교통 관리 팀들이 적절한 추상화와 모듈화에 의해서 효율적으로 돌아가는 방식 소프트웨어 팀도 시스템 수준에서도 깨끗함을 유지하는 방법이 중요 시스템 제작과 시스템 사용을 분리할 것 생성(Construction)과 사용(Use)의 차이 시스템 생성: 의존성을 연결하는 준비 과정 시스템 사용: 준비 과정 이후에 이어지는 런타임 로직 시스템 생성과 시스템 사용을 분리하는 대표적인 방법 - DI(Dependency Injection) 시스템 제작과 세스템 사용을 분리해야하는 근본적인 이유: "관심사"를 분리함으로서 SRP원칙을 준수하기 위함 1) 생성과 사용 분리 ..

클린한 클래스 작성하는 방법 * 아래에서 해당 개념 설명 예정 SRP 준수: 클래스의 변경 이유는 한가지가 되도록 설계 Cohesion 준수: 인스턴스 변수를 최소화 클래스는 작게 만들 것 함수에서의 클린 코드 내용과 같이 클래스 역시도 작아야 가독성, 유지보수에 이점이 있는 코드 함수에서는 내용의 길이를 행의 수 20줄도 긴 수치라고 했었지만, 클래스는 맡은 책임의 개수를 보고 판단 클래스의 책임의 개수 판단 메소드의 개수는 5개 이하가 적정 클래스 이름은 해당 클래스 책임을 기술하는 최소의 범위로 작성 (Manaer, Processor가 붙으면 해당 클래스에서 여러 책임을 떠안겼다는 증거) ex) 책임이 많은 클래스 WRONG - 메소드의 개수는 5개 이지만, SuperDashboard이름에서 Sup..

Unit Test 코드가 중요한 이유 테스트 케이스가 있으면, 실제 코드를 변경하는 것이 두렵지 않은 장점이 존재 유연성, 유지보수성, 재사용성을 제공 테스트 케이스가 있으면, 실제 코드를 변경할 때 테스트 케이스를 사용하여 수정한 코드가 잘 돌아가는지 테스트할 수 있기 때문에 결함율이 낮아지는 효과 (= 유연성과 유지보수성) 테스트 케이스를 작성해 놓으면 해당 테스트 케이스는 계속 사용할 수 있으므로 재사용성 제공 아키텍처가 아무리 유연하고 설계를 아무리 잘 나누었더라도, 테스트 케이스가 없다면 변경에 주저할 수 밖에 없는 상황이 발생 쌓인 테스트 케이스, 즉 테스트 슈트는 설계와 아키텍처를 변경하기 쉬워지므로, 이런 것들을 최대한 깨끗하게 보존하는 열쇠 TDD의 개념 Test Driven Develo..

소프트웨어의 경계 모든 소프트웨어를 직접 개발하는 경우는 드물고, 프레임워크를 이용하여 작성하는데 이때 외부 코드를 작성하려는 코드에 깔끔하게 통합이 필수 소프트웨어의 경계를 깔끔하게 처리하여 깔끔하게 통합 소프트웨어의 경계가 무너지기 쉬운 경우 인터페이스 제공자 vs 인터페이스 사용자 제공자: 적용성을 최대한 높이면 더 많은 고객이 구매하니까, 제네릭하게 작성 사용자: 자신의 요구에 집중하는 인터페이스를 원하는 상황 소프트웨어의 경계 모듈 예시 MyArray 모듈 - 제공자 protocol MyArray { func get(key: String) -> Any } class MyArrayImpl: MyArray { ... var datas = [String: Any]() func get(key: Stri..