격동하는 기획속에서 개발하기

부제: 4개월간 초기 스타트업 MVP 서비스 개발기�@SON

발표 순서

• @SON 의 상태
• 어떤 서비스를 개발중이었나요?
• 기획의 변했어요!
• 고객 범위가 변했습니다
• 아 이걸 고려 못했네요
• 오늘 짠 코드는 내일의 레거시!
• 아쉬웠던 점들
• 질문 받습니다

프로젝트 시작 당시 @SoN의 상태

프로젝트 시작 당시 @SON의 상태 PHP 실력편

• 라라벨 경험 전무
• php 공부 거의 안해봄
• PSR 그건 먹는건가요?
• composer가 뭐에요?
• php는 서버 설정 어떻게 하나요?

요약: @SON 은 PHP를 할 줄 몰랐다.

프로젝트 시작 당시 @SON의 상태 경력편

• MVC 가 뭔지는 알고 있다.
• Spring + hibernate 기반으로 업무를 했었다.
• REST를 기반으로 API 를 업무에서 사용했다.
• 디자인 패턴에 대해서 여러모로 공부를 하고 있는 상태였다.
• N-layer 구조는 이해하고 있다.
• ORM을 사용해 보았다.
• 회사 경력은 5개월 있는 상태였다

요약: @SON 은 서버 개발을 해보았다

​

​

어떤 서비스를 개발 중이었나요?

모빌리티(?) 서비스 입니다.

처음에는

렌터카 업주 - 차량 탁송 기사 매칭 서비스 && 렌터카 �차량 관리

​

최종은

차량 탁송이 필요한 업종의 업주 - 탁송 기사 매칭 서비스

​

서비스 구성

고객사

APP

기사�APP

소스 구조 간략 편

기획이 변했어요! - 0�고객 범위가 변했습니다!

고객 범위가 변했어요!

렌터카 사업자 ONLY

모든 사업자

그래서 이런 부분이 변했습니다

• 데이터의 변동
• 회사 테이블 내부에 상태값 구분 추가
• 상태 값 모아놓은 const 내부에 값 추가 �
• 기능 변화
• 고객사 직원 로그인 API
• 고객사 회원가입 및 고객사 직원 회원가입
• 탁송 기사 선정 로직

미리 이렇게 했으면 좋았을 것 같다 싶은 부분들

• 함수의 세분화
• 특정 로직 함수 내부에 100줄 가량의 코드를 작성 했었습니다.
• 반복되는 일부 로직을 때어냈다면 수정 작업이 한결 수월했을텐데 하는 아쉬움이 있습니다.�
• 로그인에 미리 Custom Validator 클래스를 만들었어야 했다.
• 로그인에 대한 custom validator 가 있었을 경우면 validator 를 수정하는 게 변경사항의 전부 였을 것이고, 사이드 이펙트도 적었지 않았을까요?

이건 다행이었다 싶은 부분들

• 인증을 수행하는 서비스 레이어의 별도 작성
• 이것 덕분에 여러개의 클래스를 보면서 수정 할 일은 없었습니다.
• 개별적으로 테스트하기 한결 편했습니다.(제대로된 테스트인지는…)�
• DB 스키마는 다행히 어느정도의 변동을 고려한 채 만들어 놓았던 부분.�
• 한가지의 기능 단위로 함수를 1차적으로 분할한 부분
• 덕분에 문제가 발생하면 적어도 어떤 함수 1개를 고치면 되었습니다.

기획이 변했어요! - 1�핵심 기능의 흐름이 변했어요!

그럴때는 이렇게 했습니다.

• 기존 흐름에서 어떤 부분들이 바뀌는지 확인합니다. �
• 원하는 결과값을 어떻게 하면 뽑아 낼 수 있는지 고민해 봅니다. �
• 실제로 필요한 변화의 범위가 어느정도인지 확인합니다
• ex1) 특정 함수 내부의 일부분을 변경한다.
• ex2) DB 에서 변경되어야 하는 것이 있는지 확인한다.
• 기존 소스를 버리고 아예 재작성을 해야하는지 확인한다. �
• 기획자 분에게 대략 얼마쯤 걸릴것 같다고 얘기합니다.�
• 변경하고 테스트 합니다.

EX) 탁송 진행중에 특정 시점마다 FCM 푸시가 날아 가면 좋겠어요!

• Notifications라는 기능이 있지만 메세지 종류가 약 15개 정도 되기에 사용하지 않는게 나을것이라고 판단했습니다.
• 특정한 템플릿 형식을 띄고 있기에 해당 템플릿들을 한개 클래스 내부에 모아 놓게 되었습니다.
• 기존에 ApiClient 디렉토리에 위치하는게 의미상 알맞다고 판단하고 추가했습니다.

​

그래서 소스는 이런 구조로 짜여지게 되었습니다.

다른 분들은 어떻게 하시나요?

기획이 변했어요! - 2�아! 이걸 고려 못했네요.

예를 들자면

• 기획 부분
• 유저 사용에서 이런 예외가 있었네요!
• 이런 정보를 추가 수집해주세요�(유사 제품: 이런 통계 데이터가 필요해요)
• 이런 기능도 추가되어야 해요! �
• 개발 부분
• API 파라미터가 추가되어야 하네요
• 이런 푸쉬도 내려주세요
• 짜고 보니 중복 코드가 많네요
• 기획이 바뀌니 지금 구조랑 맞지 않아요

기획 요청에는 이런 식으로 대응해 보았습니다.

• 기획자와 얘기후 추가 범위를 결정한다.
• 기존 소스에서 비슷한 역할을 하는 것들을 찾아본다.
• 유사 역할을 하는게 많아지면 한데 묶어서 새로운 클래스를 만든다.
• 비슷한 역할을 하는 것이 한 클래스에 모여있고 새로운 함수가 추가 되면 �함수를 하나 만들고 재사용 가능한 것들을 모아 함수로 분할 한다.
• 때로는 DB 테이블에 특정 칼럼을 추가하고 특정 함수 내부를 바꾼다.
• 경우에 따라서…. 구조를 뒤엎으면 화장실 가서 조용히 울어 봅니다.

개발하다보니 변경 해야 할 부분이 보이면

• 내 시야가 이렇게 짧구나 하고 반성한다
• 어디까지 변경해야 하는지 고민해본다.
• 다른 팀원들에게 이런 부분을 이렇게 고치려고 한다고 알려드리고 의견을 구해본다.
• 대략 소요될 만한 시간을 생각하고, 수정 작업에 들어간다.
• 완성이 되면 해당 함수 테스트 -> 기능 전체 테스트를 진행한다.

상태 값이 유독 많이 변하고 추가 되서 이런걸 만들어서 썼었습니다.

어떻게 해야 이런 변동을 �잘 예측 할 수 있을까요?!

오늘 짠 코드는 내일의 레거시!

왜 그렇게 느꼈나요?

• 서비스 !== 소프트웨어�
• 알고있던 지식이 잘못된 것을 알면 바꾸게 되어있네요!�
• 더 효율적인 방식이 있고, 공수 대비 도입의 이익이 크면 넣을 수 밖에 없군요!�
• 안 좋은걸 알아도 지금은 넣을 수 밖에 없는 코드도 있네요 ㅠㅠ�
• 이전에는 필요했지만 지금은 필요 없는 코드가 생기네요!

PUG 멤버 분들께 질문 있습니다!

• 어떻게 하면 변화 하는 부분을 줄일 수 있을까요? �
• 기획자 분들 과의 커뮤니케이션 어떻게 하면 잘 할 수 있을까요? �
• 어떻게 해야 비개발자 분들이 납득하는 일정을 잡을 수 있을까요?

아쉬웠던 점들

• PHP Unit 활용
• 네이밍 규칙
• DI(Dependency Injection) 도입
• Guzzle Http 사용하는 부분 싱글턴(Singleton) 도입
• 레디스(Redis)를 사용한 캐쉬 서버 도입
• OAuth 도입
• 트랜잭션 처리 개선
• DTO 도입
• 개발시의 기록 남기기
• 마이그레이션 활용
• 서비스(비즈니스)에 대한 이해도가 낮았던 순간들

질문 받습니다!

아 저 친구랑 한번 일해보고싶네�OR

옆에 앉혀 놓고 혼내보고 싶네 �하시는 분은?!

const $NAME = 손주호�$e_mail = joohotheman@gmail.com

$phone_num = 01072116470

$git_hub_link = https://github.com/Sonjoo

발표 들어주셔서 감사합니다