2022-06

Good

• 음, 생각보다 없다.
• 돈아끼는 방법을 하나 추가적으로 알았다.
• 브런치 글을 꾸준히 쓰고있다.

Bad

• 운동을 못했다.
• 허리가 아프다.
• 약간 무기력증이 도지는 느낌이다. 코드를 많이 안짜서 그런 듯 하다.
• 최근에 잠을 잘 못잤던게 월말에 밀려왔다. 새벽에 일어나는 걸 못했다.

Learns

• ReActive 방식은 다음과 같이 사용한다.
  1. 실제 바깥에서 사용할 Publisher를 internal으로 만든다
     • 이과정에서 protocol을 채택하여 만들 수도 있다.
  2. 실제 내부에서는 private으로 publisher를 하나 만들어서 그녀석으로 지지고 볶는다.
     • 이 과정에서 외부 publisher를 받아 compactmap, flatmap으로 변형하여 바깥에서 사용할 publisher로 만들어버릴 수도 있다.
     • 이 때 보통 computed property를 통해 적용한다.
  3. 바깥에서 사용할 친구의 type은 AnyPublisher로 감춘다.
• method 추출역시 refactoring이다.
• View에서 작업을 처리하고 다시 비즈니스 로직을 처리해야 한다면 completion handler를 활용하자.

 
// In ViewController
func announce(winner: PlayerType?, withCompletionHandler handler: @escaping () -> ()) {
    let alert = UIAlertController(title: winnerString, message: nil, preferredStyle: .alert)
    let closeAction = UIAlertAction(title: "Close Game", style: UIAlertActionStyle.default) { _ in
        handler()
    }
    alert.addAction(closeAction)
    present(alert, animated: true, completion: nil)
}
 
// In ViewModel
viewController.announce(winner: endGame.winner) {
    self.listener?.ticTacToeDidEnd(with: endGame.winner)
}
 

• 뭔가 너무 커서 나중에 수정해야 하는데 기능을 추가해야 하는 경우 protocol을 만들어놓고 extension에 적용하여 구현해놓으면 완전 구분되어서 나중에 분리하기 편함, 가독성도 좋아진다.
• 기술적인 이야기를 공유할 때는 그사람 입장에서 생각하고 말한다.
  • 전반적인 문제에 대해 쉽게 말하고, 핵심적인 문제에 대해서 이해할 수 있도록 말한다.
  • 세부 사항의 경우 질문을 받거나, 후반부에 말하기
  • 그리고 가장 중요한 용어에 대해 정확하게 정의하고 이야기해야 논의가 가능해진다.
• 이슈 수정을 할 때, 당장 문제를 해결하는 방향을 넘어서 조금더 깊이 뜯어보는 습관이 필요할 듯하다.
  • 해당 부분을 볼 때, 다른 사람이 이 부분을 다시 볼 수 없을 수도 있기 때문이다.
  • 그리고 다시 본다고 해도 나만큼의 리소스를 들여 보기 때문에, 장기적 관점에서 보았을 때 해당 이슈를 이해한 시점에 조금이라도 코드를 낫게 만들고 떠나는 것이 좋은 동료가 되는 길이다.
  • 내 판단에 조금더 확신을 갖고, 모르는 경우 질문하는 것을 두려워하지 말자.

Commitment

• 운동은 진짜 해야한다..
• 다시 새벽에 일어나서 운동하고 출근하는 일상을 되찾는다.
• 규칙적인 식습관을 가진다.