부스트캠프 웹·모바일 8기 멤버십 5주차 회고

디자인 가이드

멤버십 5주차 부터는 실제 현업에서 디자이너가 디자인을 주는것처럼 전체적인 디자인이 나오고

거기에 맞춰서 앱을 개발하게 된다.

처음에는 디자인이 다 되어있으니 나는 구현만하면 된다고 생각해서 좋아했지만 현실은 아니었다.

그동안에는 전부 내가 디자인하고 개발까지 했기 때문에 어떤 UI를 쓸지를 다 정해놓고 디자인을 해서 UI를 구현을 하는 것이 어렵지 않았다.

하지만 이번에는 다른 사람이 디자인해놓은것을 개발하는 것이다보니

앱 디자인을 보고 어떤 UI를 생각하고 디자인 한 것인지 알 수가없기 때문에 구현하는 것이 어려웠다.

내가 디자인을 할때는 TableView를 써서 각기 다른 Cell을 사용하고 TableView에서만 쓸 수 있는 디자인들을 추가해서 앱을 디자인하고 구현했다.

하지만 다른 사람이 디자인 한것을 보면 이 부분이 TableView를 생각하고 디자인한 것인지 아니면

다른 뷰를 생각하고 디자인 한것인지 알 수 가 없었기 때문에

어떤 UI를 선택할지 어려웠고 선택을 하고나면 디자인에 나와있는것과 동일하게 구현하는것이 힘들었다.

개발자, 디자이너, 기획자 셋이서 매번 서로에게 안된다고 하는 인터넷 밈을 봤는데 왜 그러는지 이해하게 되었다.

현업자 멘토분의 리뷰

멤버십 5주차부터 8주차까지는 실제 현업자 분의 리뷰를 받을 수가 있었다.

내 코드를 보고 현업자 분이 보기에 어색하거나 부족한 부분들을 짚어주셨다.

어디어디가 잘못되었다라고 콕 집어주시지 않고

이 부분은 왜 이렇게 짜셨나요 ??

다른 방법은 없었을 까요??

이 방법 대신 다른 방법으로 구현한다면 각각의 장단점은 무엇일까요 ?? 와 같이

내가 한번 더 생각해 볼수 있도록 화두를 던져주는 식으로 질문을 해주셨다.

예전 같았으면 그냥 콕 집어주셔서 현업자분은 어떻게 코드를 작성했을지 말해주면 좋겠다 라고 생각했겠지만

챌린지 과정과 4주간의 멤버십과정을 거쳐가면서 내가 고민하는 시간의 중요성을 깨달았기 때문에

멘토분이 코멘트를 달아주신 부분을 다시한번 생각해보는 시간을 가졌다.

멘토분이 코멘트해주신대로 코드를 다시 읽어보고 충분한 시간을 가지고 생각해보니

어색한 부분이나 수정해야할 부분들을 찾을 수 있어서 정말 좋은 시간이였다.

또 내가 고민하고 있는 부분이나 궁금한 점들을 마음편히 질문할 수 있었던 것이 좋았다.

UI코드는 어디에

나같은 경우는 클로저를 사용하여 UI를 만드는데 이렇다 보니 코드 첫 부분에 UI코드가 방대해졌다

기존에는 class에 UI만 구현하고 private extension을 사용하여 핵심로직들을 추가하고 mark표시로 구분했었다.

class ViewController {
    
		// delegate와 같이 self를 쓸일이 있다면 lazy var를 사용
    private lazy var someUI = {
        
    }()

	  // 없다면 let을 사용했다.
    private let someUI = {
        
    }()
    
}

// 비지니스 로직 구현
// MARK 표시로 구분했다
private extension ViewController {

}

하지만 처음 swift파일을 열면 초기에 300줄 가량이 넘는 부분이 UI 구현 코드이다보니 UI구현 부분을 분리하는 것을 고민하게 되었다.

첫번째는 make함수를 만드는 것이다.

final class ViewController: UIViewController {
    private lazy var label: UILabel = makeLabel()
    private lazy var button: UIButton = makeButton()
}

private extension ViewController {
    func makeLabel() -> UILabel {}
    func makeButton() -> UIButton {}
}

장점으로는 초기에 UI 선언부가 짧아지고 lazy var로 선언하기 때문에 불필요한 성능저하나 공간낭비를 줄일 수 있다.

단점으로는 UI설정을 한번만 하는데 함수를 만들어야하고

함수 호출로 초기화하기 때문에 lazy var로 선언해야하므로 Thread Safe하지 않게된다.

두번째는 configure함수를 만들어 viewDidLoad에서 호출해주는 것이다.

final class ViewController: UIViewController {
    private let label: UILabel = .init()
    private let button: UIButton = .init()
}

private extension ViewController {
    func setupAttribute() {
        labelConfigure()
        buttonConfigure()
    }
    
    func labelConfigure() {}
    func buttonConfigure() {}
}

장점은 첫번째 방법과 동일하게 선언부가 짧아지고 lazy var가 아니라서 thread Safe하다는 것이다.

단점은 함수를 만들어야한다는것과 let이기 때문에 ViewController의 생성과 동시에 모든 UI가 메모리에 올라간다는 것이다.

총 3가지 방법을 고민을 하다가 configure함수를 만들고 viewDidLoad에서 호출하는 방식으로 결정했다.

이 부분에 대해서 현업에선 어떻게 다루고 있는지 멘토님에게 질문했는데 친절히 답변해주셨다.

디자인 가이드

멤버십 5주차 부터는 실제 현업에서 디자이너가 디자인을 주는것처럼 전체적인 디자인이 나오고

거기에 맞춰서 앱을 개발하게 된다.

처음에는 디자인이 다 되어있으니 나는 구현만하면 된다고 생각해서 좋아했지만 현실은 아니었다.

그동안에는 전부 내가 디자인하고 개발까지 했기 때문에 어떤 UI를 쓸지를 다 정해놓고 디자인을 해서 UI를 구현을 하는 것이 어렵지 않았다.

하지만 이번에는 다른 사람이 디자인해놓은것을 개발하는 것이다보니

앱 디자인을 보고 어떤 UI를 생각하고 디자인 한 것인지 알 수가없기 때문에 구현하는 것이 어려웠다.

내가 디자인을 할때는 TableView를 써서 각기 다른 Cell을 사용하고 TableView에서만 쓸 수 있는 디자인들을 추가해서 앱을 디자인하고 구현했다.

하지만 다른 사람이 디자인 한것을 보면 이 부분이 TableView를 생각하고 디자인한 것인지 아니면

다른 뷰를 생각하고 디자인 한것인지 알 수 가 없었기 때문에

어떤 UI를 선택할지 어려웠고 선택을 하고나면 디자인에 나와있는것과 동일하게 구현하는것이 힘들었다.

개발자, 디자이너, 기획자 셋이서 매번 서로에게 안된다고 하는 인터넷 밈을 봤는데 왜 그러는지 이해하게 되었다.

현업자 멘토분의 리뷰

멤버십 5주차부터 8주차까지는 실제 현업자 분의 리뷰를 받을 수가 있었다.

내 코드를 보고 현업자 분이 보기에 어색하거나 부족한 부분들을 짚어주셨다.

어디어디가 잘못되었다라고 콕 집어주시지 않고

이 부분은 왜 이렇게 짜셨나요 ??

다른 방법은 없었을 까요??

이 방법 대신 다른 방법으로 구현한다면 각각의 장단점은 무엇일까요 ?? 와 같이

내가 한번 더 생각해 볼수 있도록 화두를 던져주는 식으로 질문을 해주셨다.

예전 같았으면 그냥 콕 집어주셔서 현업자분은 어떻게 코드를 작성했을지 말해주면 좋겠다 라고 생각했겠지만

챌린지 과정과 4주간의 멤버십과정을 거쳐가면서 내가 고민하는 시간의 중요성을 깨달았기 때문에

멘토분이 코멘트를 달아주신 부분을 다시한번 생각해보는 시간을 가졌다.

멘토분이 코멘트해주신대로 코드를 다시 읽어보고 충분한 시간을 가지고 생각해보니

어색한 부분이나 수정해야할 부분들을 찾을 수 있어서 정말 좋은 시간이였다.

또 내가 고민하고 있는 부분이나 궁금한 점들을 마음편히 질문할 수 있었던 것이 좋았다.

UI코드는 어디에

나같은 경우는 클로저를 사용하여 UI를 만드는데 이렇다 보니 코드 첫 부분에 UI코드가 방대해졌다

기존에는 class에 UI만 구현하고 private extension을 사용하여 핵심로직들을 추가하고 mark표시로 구분했었다.

class ViewController {
    
		// delegate와 같이 self를 쓸일이 있다면 lazy var를 사용
    private lazy var someUI = {
        
    }()

	  // 없다면 let을 사용했다.
    private let someUI = {
        
    }()
    
}

// 비지니스 로직 구현
// MARK 표시로 구분했다
private extension ViewController {

}

하지만 처음 swift파일을 열면 초기에 300줄 가량이 넘는 부분이 UI 구현 코드이다보니 UI구현 부분을 분리하는 것을 고민하게 되었다.

첫번째는 make함수를 만드는 것이다.

final class ViewController: UIViewController {
    private lazy var label: UILabel = makeLabel()
    private lazy var button: UIButton = makeButton()
}

private extension ViewController {
    func makeLabel() -> UILabel {}
    func makeButton() -> UIButton {}
}

장점으로는 초기에 UI 선언부가 짧아지고 lazy var로 선언하기 때문에 불필요한 성능저하나 공간낭비를 줄일 수 있다.

단점으로는 UI설정을 한번만 하는데 함수를 만들어야하고

함수 호출로 초기화하기 때문에 lazy var로 선언해야하므로 Thread Safe하지 않게된다.

두번째는 configure함수를 만들어 viewDidLoad에서 호출해주는 것이다.

final class ViewController: UIViewController {
    private let label: UILabel = .init()
    private let button: UIButton = .init()
}

private extension ViewController {
    func setupAttribute() {
        labelConfigure()
        buttonConfigure()
    }
    
    func labelConfigure() {}
    func buttonConfigure() {}
}

장점은 첫번째 방법과 동일하게 선언부가 짧아지고 lazy var가 아니라서 thread Safe하다는 것이다.

단점은 함수를 만들어야한다는것과 let이기 때문에 ViewController의 생성과 동시에 모든 UI가 메모리에 올라간다는 것이다.

총 3가지 방법을 고민을 하다가 configure함수를 만들고 viewDidLoad에서 호출하는 방식으로 결정했다.

이 부분에 대해서 현업에선 어떻게 다루고 있는지 멘토님에게 질문했는데 친절히 답변해주셨다.