ios 개발 전업을 선언하고 5개월 가량을 다음 정도의 spec?을 가진 앱을 2개를 유지 보수 작업을 진행하였다.
전혀 다른 성향의 개발자(혹은 복수의 개발자)가 만들어 놓은 2개 앱을 어떠한 가이드 문서 없이 보면서
이런 부분은 배워야지 혹은 이렇게하지 말아야지에 대한 회고를 정리해보려고 한다.
1. 2개 앱 Spec: 서버가 있고 안드로이드를 지원하고 앱의 화면은 크게 2가지로 구성된다.
네이티브로 구성된 화면이 있고 필요에 따라서 웹페이지를 보여주는 화면이 있다.
앱의 주요 설정 및 공지사항 등은 서버에서 내려 받아서 보여준다.
local에는 사용자 설정 정보 이외의 데이터를 저장하지 않는다.
2 카테고리 혹은 키워드 별로 정리해보았다.
- Naming
변수 네이밍은 내용이 명확하게 반영되어야 한다.
예. isNickDuplicate 개발자는 닉네임 중복을 확인한 상태를 저장하는 변수라고 썼지만 이름만 보면 닉네임이 중복인지 아닌지로 읽힌다?
> 나는 이것을 isNickDuplicateCheck 이런 식으로 바꿔 보았다.
- 조건문 처리
early return pattern을 가급적 쓰려고 노력해야 겠다.
- uicomponent
자주 사용하는 component의 경우 base를 선언하고 필요한 스타일이나 프로퍼티를 만들어두는 것이 좋더라.
예. 빨강색 글씨에 파랑색 배경색을 가진 버튼이 기본 버튼, 회색 글씨에 오렌지색 배경을 가진 버튼이 subbutton으로 쓰인다고 하면
UIButton을 extension으로 선언해서 스타일을 미리 정의하던지 아니면 baseButton을 만들고 그걸로 UI를 구성한다면 메인 색 변경 같은 정책 변경시 쉽게 대응이 되고 화면을 새로 구성할 때도 유용하다.
- tableview cell 구성시
index를 가지고 어떤 cell을 그릴지 혹은 어떤 동작을 할지를 정해진 코드가 한 앱에 많았다. 그러니 어떤 cell이 그려지는 것이 맞는지 index 값을 보고 판단하지 못하니 가독성이 떨어지고 순서를 바꾼다고 하더라도 실수의 여지가 생긴다.
그래서 각 cell이 그려지는 바가 나타나도록 string array를 이용하거나 데이터의 특정 값을 이용해서 처리하게 수정하는 것이 좋더라.
이것은 button.tag를 이용해서 처리하는 부분에서도 동일하다. tag 0, 1,2로 처리하면 당사자도 만들 당시에만 명확하게 아는 것이지
가독성이 떨어진다. 이것 역시 처리할 array를 목록을 가지고 동작하게 하는 것이 가독성이 높아진다.
- webview
앱의 특성상 webview base를 잘 만들어 놔야 어디서든 잘 쓸 수 있다.
- 파일 및 폴더 관리, static string 등등
한 앱의 경우 하나의 폴더에 파일이 20개씩 있으니 어떤 의미를 가지는지 알수 없고 찾기도 어렵다.
controller를 구성할 때도, view 폴더를 구성할 때도 의미 없는 하나의 나열로 구성된 것은 찾기가 어렵다.
특히 xcode 11.7에서 빌드해야 한 앱은 xcode가 하나의 폴더를 여는 것 조차가 버벅인다.
이 관리는 assets 관리도 동일하다. 이미지 관리를 위한 폴더를 거의 사용하지 않고
거의 하나의 폴더를 이용하다보니 assets의 미리보기도 제 역할을 할 수가 없다.
그래서 depeth 혹은 폴더수가 늘더라도 하나의 완결된 화면 혹은 분리 가능한 폴더로 나누어서 관리하도록 하는 것이 좋더라.
> context 단위이면 좋겠다는 표현일수 있겠다.
- ui 구성시에
여러 구역으로 나눠진 UI에서 UIView를 단독으로 사용하는 것은 지양해야 하고 작은 단위가 보여서 하나의 구역을 이루는 경우
UIStackView를 적극적으로 사용하자.
UIView 하위에 UIView 한땀한땀 그리면 순서가 바뀌거나 중간에 하나의 요소가 빠지면 수정하는데 시간이 많이 걸린다.
- viewModel은 꼭 쓰자
이상하게 2 앱 모두 viewModel을 쓰지 않는다. 그러다 보니 viewcontroller안에 로직이 있다보니 UI 관련 내용과 데이터 관련 내용이 혼재 되어 있어서 가독성이 떨어지면 비동기 처리 부분이 애매한 곳들이 있다.
- 뜬금없는 snapkit?
하나의 앱은 코드의 일관성이 있어서 한명이 만든 것인지 혹은 하나의 rule을 잘 지킨 것인지 알수 없지만
하나의 앱은 최초 개발자와 최초 개발자의 코드를 따르지만 수준이 조금 떨어지는 개발자, 그리고 앞에 두 사람과 다른 소속의 한사람이 짠 코드로 나눠진다. 3번째 사람이 만든 화면은 모두 snapkit을 짜여 있다. snapkit 쓰는 것 자체가 문제는 아니지만 전반적으로 스토리보드로 짠 앱에서 혼자 아는 snapkit으로 넣는 것...
난 개인 적으로 반대하는 편이다. 정답은 없겠지만.
- Mappable 사용시
서버에서 주는 값이 어떤 타입을 의미해서 그 비교를 하는 값들이 하드코딩된 어떤 string이라면, 다음과 enum으로 정의하고 그 enum으로 비교하는 것이 오타를 줄이는 방법이더라.
nameType을 바로 사용하지 않고 enum을 정의해서 사용하게 mapping에서 구현함.
- appStore.
겪었던 것중에 특이했던 것은 앱의 어떤 화면에서도 안드로이드 혹은 다른 플랫폼에 대한 내용이 나와서는 안된다. 그것이 실제 동작과 무관한 공지사항 내에 이미지여도 마찬가지다. 나오면 무조건 심사 reject이다.
RECENT COMMENT