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

리팩터링과 아키텍처, YAGNI(애그니) 리팩터링이 아키텍쳐에 미치는 실질적인 효과는 요구사항 변화에 자연스럽게 대응하도록 코드 베이스를 잘 설계해주는 장점이 존재 점진적 설계 (incremental design), YAGNI(You Aren't Going to Need It) "필요 없을 것이다" 유연성을 위해 현재 필요하지 않고 추후에 사용될 기능까지 구현하는 것보단 리팩터링을 사용할 것 추측하지 않고 그저 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축할 것 아키텍쳐도 그에맞게 리팩터링하여 변경 리팩터링과 소프트웨어 개발 프로세스 최초의 애자일 소프트웨어 방법론 중 하나로 등장한, 익스트림 프로그래밍은 일명 TDD(Test Deiven Development) 리팩터링 하면서 쉽게 오류를 확인..

리팩터링 원칙 리펙터링이란? 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 주의: 리팩터링은 특정한 방식에 따라 코드를 정리하는것이며, 단순히 코드를 정리하는 작업은 리펙터링이 아니고 `재구성(restructuring)`이라고 명칭 목적을 명확히 할 것 기능 추가인지 리펙터링인지 인식하면서 프로그래밍할 것 기능 추가: 기존 코드는 절대 건드리지 않고 새 기능을 추가 (진정성은 테스트를 추가해서 통과하는지 확인하는 방식으로 측정) 리펙토링: 기능 추가는 절대 하지 않기로 다짐한 뒤 오로지 코드 재구성에만 전념 (테스트도 새로 만들지 않을 것) 리팩터링의 목적은 개발 기간을 단축하기 위함 (기능 추가 시간을 줄이고, 버그 수정 시간을 줄이는 것) 리..

* 냄새와 휴리스틱: 파틴 파울러의 "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..