스타트업 인턴 한달차 배운점

현재 한달 째 스타트업에 개발자로 일하고 있다. 

학교 연계 인턴으로 다니고 있다. 

 

회사에서는 아이오닉을 프론트엔드 프레임 워크로 사용했다. 

그래서 난 ,, 처음 사용해보는 프레임워크인 아이오닉과 친해지기 위해

 

한달동안은 거의 퇴근하고도 코딩.. 주말에도 코딩...을 했다 

 

또한 평일에도 일 5시간정도 5일동안 코딩을 해서 

인생에서 가장 많은 시간을 코딩에 사용한 한달이였다.

 

그래서 나는 고작 한달이라는 시간동안 앱 개발과 배포의 과정을 모두 경험해 볼 수 있었다.

이 과정에서 배운점들과 나중에 개선하고자 하는 점을 아주 간략하게 적어두려고 한다 .. 

 

배포 

ios 는 테스트 플라잇

ios는 xcode로 빌드하여 테스트 플라잇에 업로드 한다. 

 

안드로이드는 안드로이드 스튜디오로 빌드한 후 

앱스토어에 빌드된 파일을 직접 올린다. 

 

백 서버도 gcloud 를 사용한다. 

혼자서 하나하나 해봤으면 정말 오래 헤멨을 텐데 , 많이 알려주셔서 빠르게 배울 수 있었다. 

 

단축키 

지금까지 컴퓨터를 하면서 단축키를 정말 안쓰고 살았는데

회사 다니면서 많이 외웠다.

 

사수가 키보드로 거의 예술을 해서 

나도 단축키를 좀 외우고 연습하게 됐다

 

모든 코드에는 이유가 있다..

 

어플 내에는 사진을 찍어서 서버에 저장해야 하는 부분이 꽤 있었다. 

코드를 짜다가 사진을 보내는 부분의 로직이 조금 다른 부분이 있었다. 

특정 기능의 경우 사진을 하나 찍을때마다 서버로 전송하게 작성해 놨었다. 

 

그래서 나는 로직을 모두 같게 만들기 위해서 사진과 데이터를 한번에 서버로 전달하여 처리하도록 변경하였다. 

 배포 이후 약 2일 후에 나의 잘못을 알게 되었다

 

알고보니 사진을 하나씩 전송하는 로직은 처리 속도를 위하여 미리 서버로 사진을 전송하는 로직이였다. 

앱을 만들어본 경험이 없는 나는 속도에 대해서는 전혀 생각하지 못하고 코드를 짰던 것이다.

 

그리고 그 코드에는 항상 이유가 있던 것이었다. 

앞으로는 납득이 가지 않는 부분이 있으면 한번 물어보고 개발하고자 한다. 

 

사진의 저장 방법

사진을 디비에 모두 저장하지 않고, firebase에 업로드 한 뒤, url을 디비에 저장해 놓는 방식을 사용한다. 

 

DB 

디비버를 사용하는데 디비버에 익숙하지 않아서 디비 권한을 늦게 받았다 ㅎㅎ 민망 

sql 쿼리문 짜는법을 거의 잊어버려서

select * from `tablename` where  id ="어쩌구" 

고작 이런 쿼리도 검색해서 짰다..

 

그래도 지금은 제법 디비랑 친해져서

테스트 데이터를 내가 원하는 상태로 만드는  쿼리도 짜서 사용하고 , 필요한 데이터들도 뽑아준다. 

 

sequilzer 

시퀄라이져와도 제법 친해졌다. 

특히 디비를 다루는 부분이 추상화가 잘 되어있어서 인상깊었다.

쿼리의 condition을 만드는 코드를 따로 만들어 놔서 내 프로젝트도 적용하려고 한다. 

 

디비에 새롭게 생성한 컬럼 마이그레이션 

새로운 기능을 위해서 몇개의 테이블을 직접  설계하고, 몇개의 컬럼을 삽입했다.

근데 막상 나중에 실제 디비에도 이를 적용하려고 하니 뭘 바꿨는지 잘 기억이 나지 않았다.

 

앞으로는 테이블 만들 때 사용한 쿼리문을 잘 정리해 둘것  

그리고 디비버에는 직접 데이터를 수정하고, 이를 쿼리로 추출해주는 기능이 있었다..!

앞으로 새 컬럼추가같은건 디비버를 이용하고, 쿼리를 적어둬야지 

 

특정 테이블에 새로운 컬럼이 생기게 되면, 기존 데이터들에게도 새로운 컬럼에 어떤 값을 줄지 정해야 한다. 

이 작업은 쿼리를 짜서 하거나, 직접 디비버로 편집을 하더라

당연한 말이지만 그 당시에는 신기했어서 적어봤다. 

 

 

협업 

개발팀과의 협업과 기획팀(디자인팀?)과의 협업을 둘다 해볼 수 있었다.

특히 디자인과 기획을 다 해주니 나는 만들기만 하면 되서 너무 좋았다

개발팀과의 협업

이번 앱은 둘이서 앱을 기능별로 나누어서 따로 개발했다.

conflict가 일어날거라는 우려와 달리, conflict는 거의 없었다. 

 

그대신 기능 연결할 때 생각보다 시간이 많이 들었다. 

막상 기능을 연결하려고 보면, 서로 다른 컬럼을 사용해서 데이터를 뽑아온다던가, 연결에 필요한 데이터가 내가 사용하는 페이지에 없다던가 하는 잡다한 문제가 많이 일어났다.

앞으로는 개발 도중에 서로 사용한 컬럼을 조금 더 공유하거나, 기능 연결에 쓸 시간을 조금 더 분배 해야 겠다. 

 

기획(디자인?) 팀과의 협업

기획자가 해달라고 한 것은 그냥 만들어야 하는거라고 생각했다.

그런데 이해가 가지 않는 부분은 질문할 수 있고, 함께 대화하여 바꿔 나갈 수 있다는걸 배웠다. 

 

내 일정상에서 절대 못할것 같은 기능들은 미뤄달라고 부탁하기도 하고, 

현재 상황에서 불필요한데 개발 시간이 많이 들어가는 기능은 대화를 통해 조금더 구현이 쉬운 다른 방법으로 구현할 수 도 있었다. 

 

실수

실수는 정말 많은 시간을 잡아먹는다..

특히 스펠링 틀리면 정말 답도 없다.

 

복사 붙여넣기를 생활화 해야지 

 

테스트

아무리 웹으로 테스트 해봐도, 빌드를 해보면 보지 못한 에러가 많이 나온다.

이번에는 정말 급박하게 배포를 하게 되서 빌드 후에 오류를 너무 급하게 잡아야 했다.

 

다음에는 중간중간 한번씩 빌드해보고 에러를 잡고자 한다. 

 

코드 리뷰 

약 두번정도의 코드 리뷰를 받았다.

 

두개정도의 핵심이 있었다.

 

1. 관리해야 할 객체를 줄여라  

예를들어 출고 완료 목록, 출고중인 목록 이렇게 두가지를 출력할 일이 필요하다고 치자.

처음에는 코드를 두개의 리스트를 다르게 뽑아 왔다. 

근데 이렇게 많은 리스트를 관리하게 되면 코드가 복잡해 진다고 지양하라고 하심

그래서 나중에는 데이터 타입을 잘 설계해서 화면에 뿌린다. 

 

2. 서버에 update 나 insert 할 데이터를 보낼 때는 , 딱 그 데이터만 보내야 함 

 그냥 데이터에 flag를 통해 변경되었는지, 새로 삽입되었는지를 표시해서 

 그 뭉탱이를 서버에 보내버렸었다..

 그걸 보고 사수가 충격 받은것 같았다(죄송합니다 ㅎㅎ)  보통 그렇게 안하고 딱 변경할 데이터만 보낸다고 합니다.