포스트

킥보드 프로젝트 후기

일주일간의 팀프로젝트가 끝났다. 개인후기는 지난번 글에 적었고, 튜터님의 리뷰를 여기에 적어본다.

후기.

1. 장점

  • 상용되어 있는 서비스처럼 퀄리티적인 측면을 많이 신경쓴 것으로 보임
  • 화면이 엄청 많아서 앱이 풍성해 보였음
  • 리드미 구성을 잘 해두었음.

2. 보완할 점 및 수정내용

1. 싱글톤 패턴

단순히 활용하고 끝이 아니라, 어떤 장점이 있는지 단점이 있는지 꼭 알아보고 이해하고 있기!!!

싱글톤 패턴이란?

특정 용도로 객체를 하나만 생성하여, 공용으로 사용하고 싶을 때 사용하는 디자인 패턴

  1. 장점
    • 한번만 생성하면 되므로 메모리 낭비를 방지
    • 전역 Instance로 다른 클래스와 공유가 쉽다.
    • 공통된 객체를 여러개 생성해서 사용하는 상황이 많이 발생할때 사용
  2. 단점
    • 싱글톤 패턴이 너무 많은 일을 하거나, 너무나 많은 데이터를 공유 시킬 경우, 다른 클래스간의 결합도가 높아져 개방-폐쇄 원칙을 위배.
      • 수정과 테스트가 어려워짐.
      • 의존성이 생김
  3. 예시 출처
    1
    2
    3
    4
    5
    6
    7
    8
    9
    
    class Singleton {
     static let shared = Singleton()
        
     var x = 0
        
     private init() { }
    }
    Hello.shared.x = 123
    print(Hello.shared.x) // 123
    

개방-폐쇄 원칙?

개방-폐쇄 원칙(OCP, Open-Closed Principle)은 ‘소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다’는 프로그래밍 원칙이다. 출처: 위키

출처 : https://babbab2.tistory.com/66

여기서 연습을 해보면 좋을듯.

2. 컨벤션

컨벤션을 러프하게 잡다보면 문제가 생길 수 있음 > 잘 챙기기!

우리조에서 발생했던 문제점

  1. VC의 Identifier 규칙 부재로 인한 문제발생
    • ex) SigninVC / signinVC / SignInVC
      • Identifer의 대소문자를 사람마다 다르게 써서 merge후 해당 화면전환시 Exception 발생.
      • SigninVC를 사용하기로 최종 결정.
  2. VC 생성시, 정확한 명칭의 부재
    • ex) MapViewController가 아닌 MapVC로 생성.
      • refactor → rename을 통해 이름 일괄적으로 변경

3. Static으로 Cell 관리

셀 아이덴티파이어를 스태틱하게 설정해두는 것 시도해보기

이전까지 이렇게 했는데 왜 이번에는 까먹었는지 모르겠다.

1
2
3
4
5
6
7
8
9
10
11
struct Constants {
    
    static let counponCell = "CouponCollectionViewCell"
    static let guideCell = "guideList"
    static let guideTableCell = "GuideTableViewCell"
    static let ProfileTableCell = "ProfileTableViewCell"
    static let profileList = "ProfileList"
        
}
// Tableview CellforRowAt의 한부분
guard let cell = GuideTable.dequeueReusableCell(withIdentifier: Constants.guideCell, for: indexPath) as? GuideTableViewCell else { return UITableViewCell () }

수정완료.

4. Cell Function

셀에서 자체 펑션으로 데이터/모델이 들어왔을 때 바꾸는 동작들이 실행되는 위치를 조정해보기

cellForRowAt 메서드에 cell을 하나하나 정의하는게 아닌 CustomCell Class에서 미리 정의 하고 시작.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Custom cell class
func configure(cellModel: ProfileModel) {
        iconImageView.image = UIImage(named: cellModel.iconName)
        titleLabel.text = cellModel.title
    }

// cellForRowAt
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        guard let cell = tableView.dequeueReusableCell(withIdentifier: Constants.profileList, for: indexPath) as? ProfileTableViewCell else {
            return UITableViewCell ()
            
        }
        
        let item = dummyData[indexPath.row]
        
        cell.configure(cellModel: item) // modified
        
        return cell
    }

수정완료.

KPT

🐾  Keep 우리가 잘한 것 → 지속해야 할 부분

  • 매일 2번의 데일리 스크럼을 통해 서로의 진행 상황을 트래킹 함
  • 업무 진행 대시보드를 활용하여 개발 순서와 진행을 관리함
  • 팀원들 간의 협력을 중요시하며 서로 진행을 도움
  • 기본적으로 서로를 존중하는 의식이 바탕이 되어 즐거운 마음으로 프로젝트에 임할 수 있었음.

⚠️  Problem 팀에서 발생한 문제와 → 해결방법

  • 문제점
    • 코드 컨벤션 : 러프하게 잡은 코드 컨벤션 때문에 변수명의 통일 등 통합 시간을 추가로 소요했다
    • 카카오맵 Docs와 SDK간 메서드 불일치 등의 이슈로 맵 선정 과정에서 어려움을 겪음.
    • 화면전환시 데이터 전달, back 버튼 유무 등 시행착오가 다수 발생
  • 해결방안
    • 코드 컨벤션의 문서화
    • 의사결정 과정을 거쳐 구현 방식 변경 결정 (KakaoMap SDK 에서 Apple MapKit로 변경) 맵 자체는 Apple MapKit으로 구현하였으며, 위치 검색 기능 사용을 위한 KakaoMap REST API 사용
    • 생명주기, 화면전환 방식 변경을 통해 최적화된 화면전환 방식을 설정. 화면전환은 전체적인 통일감을 위해 NavigationController를 사용한 화면전환을 일괄적으로 사용. 생명 주기의 경우 어느 시점에서 메소드가 필요한지 확인 후 적절한 위치에 사용하는 방식으로 해결. 데이터 저장의 경우, 필요에 따라 UserDefault, Coredata, Singleton Pattern을 사용하여 해결.

💪 Try (+ Feel) 다음 프로젝트를 위해 해야할 노력 및 느낀점

  • Try
  • 프로젝트의 리팩토링 및 기능 개선 계획을 세웠다
  • 팀원이 바뀌어도 지금 팀 분위기를 유지하려고 노력
  • Feel
  • 일주일의 팀 프로젝트였지만 내용, 화면구성, 그리고 다양한 기능 구현 등 지난 키오스크와 비교했을때는 난이도는 확실히 달랐습니다. 하지만 이런 어려운 난이도에도 불구하고 할 수 있었던 가장 큰 이유는 팀원끼리 서로 할 수 있다는 자신감과 서로에 대한 신뢰감이라고 생각합니다. 저번에도 그랬고 이번에도 너무 좋은 팀원분들을 만나서 재미있게 했던 한 주였습니다.

위의 소감은 팀원분을 제외한 내꺼만 적는다.

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.