Let's Git it!(v 2.1)

기술부채

앱을 제작하면서 시간이 없다는 이유로 하지않았던 기술부채들을 하나 둘 해결하는 중이다. 역시나 부채는 쌓이는 속도가 상당히 빠르다.

가장 크게 다루고 있고 중요하다 생각하는 부채들을 총 세가지.

1. Code Convention
2. Continuous Integration
3. 기술 스택(Combine의 적용)

1. Code Convention

42서울에서 c언어를 학습하며 norminette 규정에 맞춰 코드를 짜는 것은 규정들도 거의 대부분 외울 정도로 통달하였다.

TMI. 42서울 과제에서 c언어 Code Convention인 norminette을 무시하고 과제를 제출한다면 신세계를 경험할 수 있다.

과제를 진행할때는 왜 이렇게 까다롭게 코드 컨벤션을 지켜야 하는지를 이해하기가 쉽지 않았지만 시간이 지남에 따라 코드의 간결성, 목적성, 가독성의 차이를 느끼게 되고 노미넷이 적용되지 않는 후반 과제일지라도 노미넷과 유사하게 기준을 세우고 코딩을 하는 것에 익숙하다.

42과제를 할때까지만 해도 잘 지켰었는데...
swift를 사용하고 앱을 개발하면서 앱 출시에만 급급하다보니 많은것을 놓친것 같다. 그래서 되짚어보는 시간을 갖는다.

현재 개발중인 앱인 Let's Git it!은 github repository를 Public으로 관리하고 있다.
학습용이 목적인 앱이다보니 내가 다른 레포지토리들에 있는 코드들을 참고하듯이 누군가 필요하다면 참고할 수 있도록 하기 위함이다.

다른 레포지토리들을 보다보면 README.md 파일이 예쁘게들 꾸며져있는데, 다들 코드컨벤션, 브랜치 컨벤션 등 여러가지등이 있다. 나도 언젠가 만들겠지, 적겠지 했던 것들을 앱 개발 v2.1까지 한 현 시점에서 작성하였다. (기술부채해결?)

사실 별 내용은 없다. 대부분이 Swift API Design Guidelines를 참고하여 작성되고 공식 가이드를 기반으로 조금 수정된 여러 기업들에서 만든 가이드라인들을 사용하곤 한다. 이름 있는 기업들은 대부분 가이드라인을 갖고 있다.
우리가 적용한 것은 StyleShare - Swift Style guide이다. 역시나 공식 가이드를 기반으로 약간의 내용이 추가되었다. 그리고 한글로 작성되어 있어서 조금은 보기가 편하다.
그리고 코드컨벤션을 적용해야겠다 했던 가장 큰 이유인 야곰멘토님과의 멘토링으로 알게된 객체지향 생활체조 원칙 9가지를 추가하였다.

객체지향 생활체조 원칙 9가지

1. 한 메서드에 오직 한 단계의 들여쓰기만 합니다
2. else 표현을 사용하지 않습니다
3. 모든 원시 값과 문자열을 포장합니다
4. 한 줄에 점을 하나만 사용합니다
5. 이름을 줄여 쓰지 않습니다(축약 금지).
6. 모든 엔티티를 작게 유지합니다
7. 3개 이상의 스위프트 기본 데이터타입(Int, String, Double 등) 프로퍼티를 가진 타입을 구현하지 않습니다
8. 일급 콜렉션을 사용합니다
9. getter/setter를 구현하지 않습니다

객체지향 생활체조 원칙을 전부 적용하는 것은 아직 어려움이 있지만 생활체조란 이름처럼 익숙해지고 적용하기 위해서 노력중이다.

지금까지 작성했던 코드들은 대부분 코드컨벤션에 맞춰 리팩토링을 맞췄다. 개발은 둘이서 진행하기에 구두로 설명하고 넘어가거나 눈치껏 이해하고 넘어갔던 부분들을 코드를 정리하면서 다시보니 서로 코드에 대한 이해도도 높아지고 코드 컨벤션을 계속해서 상기해 보게되어 조금은 좋은 코드를 짜는 법을 배우고 있다. 또 서로 컨벤션을 제대로 준수했는지 확인하려고 한다. 그래서 더 적극적으로 코드리뷰를 진행중이다.

2. Continuous Integration

위에서 말한 코드 컨벤션이 생기면서 부수적으로 발견*(예견)된 기술부채다.

코드 컨벤션에 맞춰 코드를 작성하고 PR을 반복하다보면 코드컨벤션에 맞지 않는 내용이 발견되기도 한다. 코드리뷰의 목적중 하나라고 생각한다. 이것을 고치고 아직은 그런적이 없지만 간단한 수정사항의 경우 PR을 날리기전에 Build를 까먹는 경우가 생길뻔 한적이 몇 번 있었다.

프로젝트가 크지 않고 개발인원이 2명 뿐이라 단순히 다음 PR이 진행될때 수정 보완될 내용이었지만 그렇게 넘기다가는 나중에 분명히 당황할 일이 생길 수 있기 때문에 github Action을 통한 CI(Continuous Integration)를 구성해보았다.

github Action

단순히 github Action을 사용하여 PR이 작성되었을때 xcodebuild에 문제가 없는지를 확인하고 싶었다.

열심히 검색을 해본 내용들은 대부분 XCTest를 사용하여 Test가 통과하는지 확인하고 TestFlight에까지 올리는 작업들이 github Action을 통해서 이루어졌다.
내가 찾고자 하는 단순히 build만 돌려보는 작업이 아닌 test위주의 action이 작성된 글들이 많았고 TestFlight까지 올리는 작업에는 Secret key나 여러 암호화된 정보들이 필요해서 그런 내용들은 배제하고 단순히 build만 테스트할 수 있는 코드들을 찾아봤다.

빌드를 옵션 없이 돌리면 프로파일링 관련된 오류들이 나오는데 CODE_SIGNING_ALLOWED=NO 옵션을 줘서 해결했다.

Let's Git it!/.github/workflows/iOS.yml

# This is a basic workflow to help you get started with Actions

name: iOS workflow

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  # Allows you to run this workflow manually from the Actions tab
#   workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: macos-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a set of commands using the runners shell
      - name: Start xcode build 🛠
        run: |
          xcodebuild -project Git-Challenges/Git-Challenges.xcodeproj -scheme Let\'s\ Git\ it\! -destination "platform=iOS Simulator,name=iPhone 12" -configuration Release build CODE_SIGNING_ALLOWED=NO

참고 stackOverFlow

3. 기술스택 Combine 적용

현재까지 사용한 기술스택은 다음과 같다.

- SwiftUI

외부 라이브러리
- FireBase
- AlamoFire
- SwiftSoup

외부 라이브러리들은 Firebase Firestore에서 데이터를 가져오거나 웹사이트 파싱, API호출과같은 비동기 작업들에 주로 사용된다.

현재는 completionHandler를 사용하여 비동기를 강제로 동기화시켜서 해결하였는데 이 부분을 Combine을 사용하여 수정할 생각이다.
아직 Combine을 사용해본 적이 없어서 제대로 사용하는 법을 잘 모르기때문에 학습을 하면서 진행할 것이다.