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

테스트 코드가 개발 효율을 높여주는 이유? 테스트 코드는 디버깅하는데 시간을 줄여줌 개발자는 보통 실제로 코드를 작성, 설계하는 시간의 비중은 그리 크지 않고, 대부분의 시간은 디버깅에 소요 버그 자체를 수정하는데는 오랜 시간이 걸리지 않지만, 버그를 찾는데 오랜 시간이 소요 테스트 코드를 짠 경우 > 버그를 찾을려고 일일이 디버깅하지 않아도, 테스트 코드에 걸리게 되어 쉽게 잘못된 곳이 어디인지 파악이 가능 테스트 코드가 시간이 걸린다는 주장의 이유? 테스트 코드를 작성하려면 부가적인 코드를 상당량 작성해야 하는데, 실제로 테스트가 프로그래밍 속도를 높여주는 경험을 하지 않았기 때문에 시간이 걸린다고 느낄 수 있음 테스트 코드의 목적은 디버깅하는 시간을 줄여주는 것이므로, 그 관점에서 생각한다면 테스트..

중복 코드 똑같은 코드 구조가 여러곳에서 반복되는 주는 단점 코드가 중복되면 각각을 볼 때마다 서로 차이점은 없는지 주의 깊게 살펴야하는 부담이 존재 한 클래스에 딸린 두 개의 메소드가 똑같은 표현식 사용? -> 함수 추출하기를 사용 (6절에서 계속) 코드가 비슷한데 완전히 같지 않다면? -> 문장 슬라이드 (8절에서 계속) 긴 함수 오랜 기간 잘 활용되는 프로그램들은 짧은 함수로 구성 짧은 함수로 작성한다는 의미? 코드는 끝없이 위임하는 방식으로 작성되기 때문에 코드를 이해하고, 공유하고, 선택하기 쉬우려면 함수의 이름이 짧은 구성이 많을때 재 역할을 수행 예전 언어는 서브루틴을 호출하는 비용이 컸기 때문에 함수 호출을 없애는 방향이었지만 지금은 별 차이가 없으므로 함수를 적극 이용 장황한 네이밍보다는..

코드에서 나는 악취 리팩터링을 언제 하는게 좋은지? 켄트 벡에 의하면 리팩터링할 시점은 '냄새'란 표현을 사용 오히려 인스턴스 변수가 몇 개가 적당한지, 메섣가 몇 줄을 안넘어가면 좋은지보다는, 사람의 직관이 더욱 정확하다는 의미 `냄새`에 대한 감각을 키우려면, 앞으로 나오는 리팩터링 내용들을 숙지하고 직접 코드로 표현해보며 사용 기이한 이름 코드를 명료하게 표현하는 데 가장 중요한 요소는 `이름`이므로 함수, 모듈, 변수, 클래스등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용하는지 명확히 알 수 있도록 엄청나게 신경써서 이름을 지어야 함 이름만 잘 지어도 나중에 문맥을 파악하느라 헤메는 시간을 크게 절약 가능 ex) 함수 이름 바꾸기, 변수 이름 바꾸기 긴 함수 경험에 비춰보면 오랜 기간 ..

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

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

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

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

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