Sign Up 을 마치며

현재 부스트 코스 에이스 2019 1기에 참여 중이며,

현재 2번째 프로젝트 과제 회원가입 화면을 구현하며, 느낀 점을 정리하고자 글을 작성하였습니다.

특정 씬 별로 기능을 구현하고 뒤돌아 봤을 때, 느낀점을 몇 가지로 나누어 적어보려고 한다.

진행한 이후 내 자신에 대해 아쉬웠던 점

• 프로젝트를 진행함에 있어서 계획이 없이, 보이는 기능을 그때 그때 구현하였다.

  하나의 뷰 컨트롤러를 구현하다가 비슷한 기능이 다른 뷰컨트롤러에도 있으니 그부분도 동일하게 구현하고
  다시 이전에 구현하던 뷰 컨트롤러로 돌아와서 구현을 했다.
  이렇게 그때 그때 기능을 구현하다보니 전체적인 구조를 생각하지 못했다.
  개인적으로 끝나고 하는 생각이지만, 3개의 씬 모두, 자신의 서브 뷰(UIControl)들에 대한 검증이 있었다.
  이 컨트롤들을 등록해두고, 검증에 대한 처리를 할 수 있는 별도의 객체를 두었다면,
  여러 뷰 컨트롤러들이 그 코드를 재사용할 수 있었을 것이고, 각각의 뷰 컨트롤러들은 가벼워졌을 것같다는 생각을 해본다. 

• 머리 속으로 떠오르는 코드가 있을 때, 문서보다 내 감각에 의존했던 부분이 있었다.

  UITextField, UITextView가 firstResponder일 때, 키보드가 화면에 나타나있다가,
  화면의 다른 부분을 클릭시 키보드를 다시 감춰는 기능을 구현할 때, 
  두개의 control클래스 모두 UIResponder의 서브클래스라는 것을 알고, 
  각각의 UI인스턴스 프로퍼티들을 [UIResponder] 배열에 저장해둔 뒤, 
  self.view가 클릭 되었을 때, [UIResponder]의 요소 모두가 resignFirstResponder()를 호출하여,
  키보드를 감추게끔 구현하였다.
  
  하지만 self.view.endEditing(true)라는 방법으로도 resignRirstResponder를 해제할 수 있다는 것을 알고 허탈했다.
  
  responder들을 배열로 두면서,나의 뷰 컨트롤러의 메소드와 인스턴스프로퍼티간의 응집도가 낮아졌다고 느꼈고,
  view에 새로운 control들이 추가된다면, 배열에 등록하는 메소드를 수정했어야 해서 OCP를 어기는 코드라고 느꼈다.
  endEditing()을 이용해서 구현을 다시 수정했을 때 오는 희열을 느꼈던 것 같다.

• 이론상으로 알고 있던 부분이지만 정작 코드를 작성하는 상황에서는 그런 부분을 놓쳤다.

  UserInfomation 객체를 디자인 함에 있어서, 
  이 객체는 Model의 역할을 하고 있다고 생각을 했고, Immutable한 값 객체로 사용하기 위해서
  구조체로 선언을 했다. 
  싱글턴이라는 제약이 존재했음에도 불구하고, 구조체를 사용했다. 
  그 결과 Immutable은 지켜질 수 있지만, 싱글턴 객체로 선언했음에도 불구하고 객체가 복사되어 유일성이라는 목적을 
  지키지 못했다. 이런 부분들을 하나하나 고쳐나가야 할 것 같다.

앞으로 고민해야 할 것

• 많은 기능이 있다고 생각하지 않는 데도 불구하고, 뷰 컨트롤러가 커진다고 느껴서 구조를 잘 나누기 위한 고민을 해야할 것 같다.

뷰 컨트롤러가 커지는 걸 막기 위해, 여러 뷰 컨트롤러에서 공통으로 사용하는 로직을 대신 해주는 객체를 만드는 것

뷰 컨트롤러 내에 다른 뷰컨트롤러를 두어 하나의 뷰컨트롤러의 책임을 줄일 수 있는 container view 에 대해서 공부해야 할 것 같다.