앱 서비스에 대해 유저와 관련된 것은 매우 중요하다.
성능, 신뢰성, 안전성 등이 있다.
요런 것들의 중요성에 대해 이야기 할 것이다.
Organize
이런 곳에서 원하는 기구나 재료들을 찾기 쉽지 않다.
이러한 상황은 예상보다 많은 시간을 소비하게 만들고 실수를 범하기 쉽다.
Xcode는 섹션별로 그룹화가 잘되어 있어서 보기 편하고 버그가 났을 때 이를 바로 체크할 수 있어서 버그 수정을 빠르게 할 수 있다.
Xcode project strucure == file project system structure 이므로 보기 편하다!
스토리보드는 보기에도 편하고, reference로 연결되어있어서 하나의 스토리보드로 모든 것을 해결할 필요 없이 여러개를 생성해서 할 수 있다.
그리고 이렇게 독립적으로 되어있으므로 각각 변화에 대해 즉각적으로 알아챌 수 있다.
그래서 이 두개의 장점으로는 파일하나에 모든 것을 담지 않고, 스토리보드 하나에 모든 것을 담고 있지 않다.
Xcode에서 프로젝트 세팅이나 파일들이 최신으로 업데이트되길 원하면 이렇게 한번에 관리해주는 곳에서 해결할 수 있다.
또한 Xcode Build system를 원하는대로 커스텀해줄 수도 있다. 기본으로는 Xcode10으로 되어있다고하는데 이건 지금은 바뀌었을수도 있다!
이렇게 목재가 나열되어있는데 이런식이면 하나의 완성된 것을 만들 수가 없다.
개발자입장에서도 동일하다. 사용하지 않는 코드와 팔일이 존재하면 하나의 완성된 프로젝트를 만드는게 걸림돌이 될 수 있다.
만약 불필요하거나 쓸데없는 코드가 있는데 이를 장기간 방치하고 축적되어 오면 개발자는 보통 이를 건드리는 것을 포기하고 냅두는 경우가 많아진다.
이렇게 워크스페이스를 프로젝트를 깨끗하게 정돈하는 것이 앱이 건강하고 장기적으로 유지하기 좋다.
Track
Source control 관련해서 이야기할 것이다.
- 커밋의 단위를 작게 해라
작은 단위로 브런치를 파서 작업해라. 어떤 문제가 생겼을 때 흔적을 찾기 더 쉬울 것이다.
- 적절한 commit message를 사용하라
미래 자신을 위해 쓰는 것이라고 생각하고 정확하고 이유가 적절하게 사용해라.
Document
어떤 사람은 이렇게 말한다.
이건 적절하지 못하다.
이렇게 스스로 코드자체가 문서화가 잘되어있어서 옳다고 생각하는 사람도 있다.
하지만 이는 전달하는 입장에서 좋지 못하다. 왜?
만약 큰 문맥에서 어떻게 다 파악할 수 있는가? 쓴사람만 보통 알지 않을까?
하지만 보통 문서화를 통해 처음 보는 사람이 어떻게 읽으면 좋을지 가이드라인을 제공하는 것이 미래를 위해 편하다.
이는 특히 주니어 개발자에게 더 많은 도움이 된다.
왜냐하면 보통 경험도 없고 프로젝트도 처음하는 것인데 이런 사람에게 가이드라인과 문서를 제공하면 얼마나 더 쉽게 적응할 수 있을지 알 것이다.
이걸 처음보면 어떤 생각하나?
String, 상수, id값 이런 생각을 할 수 있다. 하지만 어떤 id일까에 대해서는 정보가 없다.
어디에 사용되고 왜 이렇게 하드코딩되었는지 알 수 없다.
이것과 비교해보면 어떤 것이 더 명확하고 이해하기 쉬운지 알 수 있다.
사용처에서도 알 수 있게 더 명확해졌다!
애플 공식문서봐도 어떤 의미인지 어떻게 사용하는지 알 수 있다!!!
Test
보통 코드 구현 -> 유닛테스트 구현 이런식으로 한다.
유닛 테스트를 통해 어떤 문제가 발생한지 바로 알 수 있어서 쓸데없이 디버깅을 할 필요가 없어진다.
Analyze
Sanitization관련해서 설정해줄 수도 있고
런타임에 메인쓰레드인지 여부를 파악하는 것도 해줄 수 있다.
디버그 관련되서 볼 수 있는 것이 이런 것들이 있다.
Evaluate
이러한 공간이 있는데 나 혼자만의 공간이 있다!
이전에는 다른 사람과 같이 공간을 공유했는데 불편하기도 했지만 다른 사람들의 기술이나 정보를 얻을 수 있어서 좋았다.
이는 코드리뷰와 관련있다.
혼자 개발하면 빠르고 쉽게 해결할 수 있다. 하지만 단점으로는 다른 팀원이나 동료로부터 얻을 수 있는게 없다는 것이다.
코드 리뷰를 통해 서로 배워가며 할 수 있다.
특정 버그에 대해서도 넓게 바라보며 해결할 수 있다
만약 회사에서 혼자하게 된다면? 다른 곳에서 찾아서 같이 서로 코드리뷰를 해주자고 제안하는 것도 방법이다.
컨퍼런스, 활동 등에서 찾아볼 수 있다.
이는 코드리뷰를 통해 각자의 차이에 대해 알 수 있다.
또한 스펠링 에러같은 것을 체크하는데 용이하다.
Decouple
우리는 작고 정교한 재사용성있는 코드를 만든다.
이런 것을 통해 다양한 사람과 공유할 수 있다.
Manage
dependencies에 대해 이야기할 것이다!
Swift Package에서 라이브러리, 프레임워크가 있다.
내부가 무엇이 있는지 열어봐야 알 수 있다.
프레임워크는 유저의 정보나 데이터가 필요하지 않다.
그래서 데이터를 기기 밖으로 보내는 것을 절대 하지마라!
디펜던시가 이런식으로 체인처럼 이어져있다.
만약 디펜던시가 사라지거나 안되면?
이런 것을 대응할 줄 알아야한다. 없애거나 교체하거나 그런 작업을 통해 대체해야한다.
