24년 6월 첫째주 회고

이번 주 근황

• 요즘 회사에서는 QA 준비를 하고 있어요! 저번 주까지는 QA 리스트를 만들고 설정을 상세히 정리했는데, 이번 주는 해당 정리한 것을 바탕으로 테스트 앱을 만들었습니다. ㅎㅎ
  • 해당 앱을 만들면서, 테스트 앱이지만 사용성과 개발의 편의성 중 뭘 우선으로 여겨야 할까 대해서 고민하게 되더라구요. 무조건 키보드가 올라올 때 TextField를 올려주는 게 아니라 TextField가 키보드에 가려지는 위치라면 올려줘야 한다든가. tableView에서 키보드를 자동으로 내려주려고 onDrag를 설정하려고? 했다가도 … … 그렇게 되면 처음 작성했던 textField와 키보드 관련 코드와 tableView의 코드가 얽혀 버려서 곤란했어요. 너무 깊게 고민하기 싫어서 그냥 tableView의 onDrag를 없애버렸는데 (테스트 앱이기도 하구요!!!) 나중에 같이 사용해야 할 일이 생긴다면 어떻게 하면 좋을지? 생각해봐야겠어요.

 

Keep

• 간단하게 만들자면 대충 만들 수 있었지만 추후 테스트 추가 시 용이성을 위해서도 있고, 그냥 욕심이 나서(…) 테스트 앱을 열심히! 만들었습니다. 앞으로도 일 열심히 해야지.
• 시간을 완벽하게 지켰습니다! 굿굿굿.

 

Problem

• 고민을 너무 많이 해요!
  • 새삼스러운 문제지만 여전히 둘 중에 뭐가 좋을지 고민을 많이 해요. 이번에 테스트 앱을 만들면서 설정 30~40개 정도를 하드 코딩으로 구현할 일이 있었는데, 이걸 어떻게 하면 조금 더 편하게 할까 내부 데이터 구성에 고민을 많이 했어요. 다만! 달라진 점이 있다면 고민이 되는 리스트를 뽑아놓고, 파일을 여러 개 만들어서 그냥 모두 구현해 봤답니다. 어떤 점이 효율적이고 좋은지는 직접 만들어 봐야 아니까요! 고민을 했던 이유는 각각 데이터를 섹션별로 나누어야 하고, 해당 데이터가 가지는 값이 종류가 달라서 고민을 했어요. 결국 적용한 방법은 아래와 같습니다!
  • 다만, 만족스럽지 않은 부분이 있다면 section을 사용하지 않는 부분에도 section을 통해서 해당 데이터에 접근해야 하는 것과 struct가 아닌 class로 되어 있어 성능적으로 뛰어나지 못하다는 점이 아쉬워요. 이 부분을 어떻게 하지?! 하고 많이 고민하면서 거의 네 번을 다시 짰던 것 같은데, 결국 결과가 썩 마음에 들지는 않는 것 같아요. ㄱ-

  SectionList (class)
  - Section (class)
  - Option (class)
  - SettingOptions (enum)
  

• 자꾸 익숙한 기술을 찾게 돼요.
  • ㅠㅠ snapKit도 쓰고 싶고 combine과 RxSwift 중 하나도 쓰고 싶고 그냥 있으면 편한 라이브러리를 모두모두모두모두모두 적용하고 싶은데 라이브러리 특성상 당연히!! 불가능하고 회사에서 특정 라이브러리를 채택하는 건 버전 관리 시에도 번거롭기 때문에 많은 고민을 해야 하는 것 같아요. 휴님이 왜 해당 라이브러리를 혼자 구현할 수 있을 때 쓰라고 했는지 알 것 같은 기분… …. (거기에 익숙해져 있으면 내가 그걸 만들어야지 모 어쩌겠냐….)

 

Try

• 고민보다 고!
  • 사실 고민을 해서 더 좋은 결과로 이어지는 경우도 있지만, 그렇지 않은 경우도 많은 것 같아요. 일단 생각난대로 러프하게 작성한 후에 추후 너무 복잡하거나 파편화되어 있어 리팩토링이 필요하다고 느껴진다면 그때 바꿔도 괜찮지 않을까? 하는 생각이 들어요. 스스로 고민에 너무 많은 시간과 자원을 쏟는 것 같아서 더욱 그렇네요.
  • 그래도! 했던 고민들이 꼭 필요한 고민이라고 생각해요. 고민했던 시간에 비해서 결과물이 썩 좋다는 느낌은 받지 못했지만… … 성능적으로 뛰어나고 가독성 좋은 코드를 위해 앞으로도 노력하고 싶어요. 쭉!