전체 글

[Refactoring] Chapter 6: 기본적인 리팩터링

드디어 리팩토링 기법들이 소개됩니다. 기본적인 리팩토링 챕터는 생각보다 길어서 다 읽는데 시간이 꽤 들었습니다. 글이 아니라 영상으로 마틴 파울러의 리팩토링 과정을 볼 수 있었다면 보다 흥미롭게 배울 수 있었을 것 같습니다. (반대로 생각해보면 내가 이 과정을 영상으로 재구성해보는 것도 재밌겠다...) 이번에는 요약보다 궁금증, 기억할 부분 위주로 기록해보겠습니다. 6.1 함수 추출하기 함수 추출하기는 내가 가장 만힝 사용하는 리팩터링 중 하나다 (여기서 '함수function'라고 표현했는데 객체 지향 언어의 메서드method나 절차형 언어의 프로시저procedure/서브루틴subroutine에도 똑같이 적용된다.) p.159 솔직히 function/method 개념 정의를 못하겠습니다... 그래서 개념..

Swift 객체 외부에서 객체가 해제되는 것 감지하기

깃헙 블로그 내용 옮겨왔습니다. cozzin.github.io/2021/03/30/DeallocWatcher.html iOS 앱 개발하면서 NotificationCenter를 많이 사용하게 되는데요. 특정 객체의 행동을 추척할 때 유용하게 쓸 수 있습니다. addObserver(_:selector:name:object:)를 사용해서 옵저버를 등록해 둔 경우에는, 해당 객체가 메모리에서 해제될 때 옵저버도 자동으로 함께 삭제됩니다. removeObserver(_:)를 호출할 필요가 없는 것이죠. 이슈 여기에 예외가 있습니다. addObserver(forName:object:queue:using:)를 사용하는 경우에는 직접 removeObserver(_:)를 호출해줘야 합니다. 클로저를 넘겨주기 때문에 OS..

RIBs 스터디 2: 공식 레포 Wiki 살펴보기

이번에는 RIBs/wiki 보면서 RIBs에 대해 배워보겠습니다. RIBs 개념 정리 RIBs는 크로스 플랫폼 아키텍처 프레임워크 프레임워크는 정해진 틀에 코드를 넣으면 시스템이 약속된 기능을 작동시켜주는건데, 이 개념에 맞는지는 좀 더 살펴봐야겠습니다. RIB을 작성하는 템플릿이 있지만 프로그래머가 직접 관계를 지정해줘야하는 면에서 라이브러리라고 볼 수 있는건 아닐까? 하는 생각은 들었습니다. 우버를 위해 이 프레임워크를 디자인 했을때, 다음 원칙을 고수함: 크로스 플랫폼 협력을 독려함 iOS와 Android 앱에서 대부분의 복잡한 부분은 비슷함 RIB는 iOS와 Android에 비슷한 개발 패턴을 제공함 의문점 아키텍처가 통일된다고 해서 서로의 코드를 공유하는 일이 있을까? 하는 의문이 들기는 합니다..

RIBs 스터디 1: Let'Swift 발표들로 RIBs 맛보기

깃헙 블로그에 써뒀던 내용 옮겨왔습니다. 많은 팀에서 도입하고 있는 RIBs 아키텍처에 대해 스터디 해보겠습니다. RIBs 레포의 설명도 좋지만, 먼저 안정민님이 정리해주신 자료들로 필기해보며 공부를 시작해보겠습니다. MVC, MVVM, ReactorKit, Viper를 거쳐 RIB 정착기 (1) https://www.youtube.com/watch?v=3XS6xLzKRjc 세미나 내용 정리 입니다. 기존 아키텍처에 왜 만족 못했는가? 화면 단위가 아닌 프로세스 단위로 유연한 개발 필요 자체 제작 아키텍처의 유지 보수 어려움 더 확실한 안정화 필요 테스트 코드 템플릿 또는 가이드가 있는 아키텍처가 거의 없음 체계화된 테스트 코드 작성이 필요 아키텍처 여정 MV(C) 장점: 기존에 익숙한 구조. 단순환 화..

[Refactoring] Chapter 3, 4 과제

과제가 지겨운 감이 있는데... 다음주 부터는 실습을 통한 과제가 나온다고 하니 일단 참고 해보겠습니다ㅜ 1. 함수의 이름을 짓는 방법과 관련하여 책에 서술된 조언을 쓰시오 (500자 이상) 함수의 이름만 보고도 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경써서 이름을 지어야 한다고 저자는 말합니다. 이름은 코드를 명료하게 표현하는데 가장 중요한 요소 입니다. 이름을 짓는데 마땅한 것이 떠오르지 않는다면 설계에 더 근본적인 문제가 있을 수 있다고 합니다. 그래서 혼란스러운 이름을 잘 정리하면 코드가 훨씬 간결해질 때가 많습니다. 단순히 이름을 짓는 행위 뿐 아니라 설계를 다시 돌아볼 필요가 있습니다. 기이한 이름을 만나면 함수 선언 바꾸기, 변수 이름 바꾸기, 필드 이름 바꾸..

[Refactoring] Chapter4를 Swift로 따라해보기

안녕하세요 코찐입니다. 패스트캠퍼스에서 진행하는 리팩토링 완독반 수강하고 있습니다. 매주 가이드 영상이 올라오는데 내용이 마음에 들지 않아서 책 내용을 swift로 포팅하면서 직접 해보기로 했습니다. github.com/cozzin/Refactoring cozzin/Refactoring Contribute to cozzin/Refactoring development by creating an account on GitHub. github.com 자바스크립트는 동적 타입을 사용하고 있어서 클래스를 json으로 생성하기 편하게 되어있습니다. Swift에서는 조금 불편하게 되어 있습니다. JSON을 Decodable 통해서 객체로 변환시키는 작업을 했습니다. final class Producer: Decoda..

@testable import로 연결한 모듈에서 Undefined symbol이 발생하는 이슈 대응

안녕하세요 코찐입니다. 최근에 리팩토링 책을 읽기 시작헀는데 챕터 4 테스트 구축하기 편을 스위프트로 포팅해보고 싶어서 작업 중 입니다. 그런데 테스트를 위해서 @testable import 로 모듈을 가져오는데 빌드가 되지 않았습니다... 다시 보니 Host Application을 None으로 설정해둔 것도 이슈가 되고 있었습니다. Host Application을 다시 지정해줍니다ㅜㅜ 중요한 건 저 아래에 Allow testing Host Application APIs 가 체크 되어 있어야 합니다. 그래야 testable 기능을 정상적으로 사용할 수 있는 것 같습니다.

[Refactoring] Chapter 4. 테스트 구축하기

오늘은 리팩토링 챕터 4 테스트 구축하기를 읽어보겠습니다. 책을 지금까지만 읽어도 테스트 코드가 리팩토링에 중요한 요소인 것을 알 수 있습니다. 리팩토링을 하는 것은 겉보기 동작은 그대로 유지한 채 내부의 구현을 개선하는 작업입니다. 동작이 동일하다는 것을 검증할 수 있다면 훨씬 더 자신있게 내부 구현을 수정할 수 있습니다. 리팩토링에 대한 열망은 항상 있으나, 자신있게 진행했던 적은 많지 않았습니다. 항상 변경에 대한 두려움을 가지고 있었고 잘 작동하는 코드를 굳이 개선할 필요는 없다는 의견에 꽤나 마음이 쏠려 있었습니다. 이번 챕터를 읽으면서 두려움을 지루함으로 바꾸는 계기가 되면 좋겠습니다. 1. 자가 테스트 코드의 가치 실제로 코드를 설계하는 시간 보다 디버깅 하는 시간이 훨씬 더 많이 소요됩니다..