그토록 원하던 서버개발자가 되고 힘들었지만 어느덧 100일차가 넘어가고 있는 시점이 되었다.
100일간 어떻게든 1인분은 하기 위해서 노력했고 물론 1인분은 못하지만 나름 도움이 되고 있지 않나?혼자서 위로할 수있는정도는 된것 같다.
100일간 크게 서버 개발자로써 나름 여러가지 경험과 성과를 이룬것 같다.
1. ORM만 사용하다 SQL의 묘미를 알아내다!
솔직히, 취업 전까지 sql을 직접 쓰는 일이 없었다. 애초에 orm만 사용하다 편리함에 잊혀졌고 sql 사용하는 방법도 가물가물했다. 그러다 json 필드에 데이터를 막넣어서 꺼내쓰던 비정규화의 끝판왕이던 테이블을 정규화하는 작업을 하게 되었고 기존의 데이터를 정규화한 필드에 알맞게 넣어야하는 일이 생기며... sql을 쓸수 밖에 없게 되었다. 하지만 이게 뭐람 python 스크립트로 django 임포트후 for문을 돌려 하나하나 넣어야 하지않나? 밖에 생각못하던 것과 달리 postgres의 문법은 update에 특화 되어있지 않나? 생각했다. 물론 sql의 묘미는 이것이 아니라 group by를 탑재하신 Read에서 성과를 드러냈다. 여러 이슈가 생기는 실서비스에서는 원인이 무엇인지 데이터베이스에서 조금만 찾아보면 다나온다 그리고 다른팀에서 데이터를 요청했을때 sql을 사용하면 쭈르륵 나오게 된다ㅎㅎ 매번 print문으로 뽑아서 주던 이전의 나의 모습은 잊게 되었다.
2. 성능을 끌어올리는 법을 알아 가고 있다.
1번의 경험과 이어지는데 기본적으로 정규화 vs 비정규화를 비교한다면, 항상 그렇지는 않지만 조회시 정규화가 잘된 구조가 성능이 더 좋다는걸 몸소 알게 되었다. 물론 생성 삭제, 수정시에는 안그럴수도 있겠지만 기존에 비정규화되어있던 테이블에서 데이터를 가져와 2중 반복문 구조를 벗어던지고 쿼리 한번으로 해결하게 되어 속도가 기존과 비교해 굉장히 빨라졌다. 이작업을 하며 몸에 익힌 팁은 아래와같다.
- 서버에서 데이터베이스 호출은 최대한 줄여야한다. 비용이 상당히 높다.
- 데이터호출 2번 vs 데이터 호출 1번 + for문 이라면 예외 상황을 제외하고 보통 후자를 선택해야한다. 네트워크 호출 한번이후 메모리에 데이터를 올리고 작업하는것이 확실히 빠르다.
- 결과가 true, false로 구현되는 구조라면 exists를 애용하자! 모든 데이터를 끝까지 조회하는것은 굉장히 비효율적이다. exists면 해당 조건에 걸리는순간 결과를 반환한다. 물론 false라면 끝까지 가겠지만? 조금이라도!!데이터가 많으면 많을수록 개선효과가 두둑할꺼다.
- 언어의 내장함수를 애용하자! 사실 내장함수는 내가 그냥 구현하면 되는거잖아?라는 생각을 가지고 있었고 필수적인 것을 제외하고는 일부러 익히려고 하지 않았다. 하지만, 내장함수의 내부구조를 까보면(물론 python에만 해당할수도있는얘기!) 그건 아니였다. 내가 구현한 방법보다 훨씬 최적화되어 구현되어있고 또 알아가다보면 python comprehension처럼 일반 적인 for append구조보다 성능을 배로 띄어나게 만들수 있는 좋은 함수들이 있다.
말이 너무길어지는데 이번 챕터는 따로 블로그에 게시를 해야겠다.
3. 테스트와 문서화는 선택이 아닌 필수다.
사실 나는 이두가지가 필요없는것이라 생각했다. 테스트 자체는 예를 들면 3과5를 더했을때 8인가요?라는걸 확인 하는것과 같이 느껴왔고 문서화는 내가 코드를 가독성 좋게 짜고 폴더 및 파일 구조도 잘배치 하면 해결된다 생각했다. 내생각이 먼저 바뀐 건 문서화부터였다. 이미 몇년간 서비스를 지속하며 여러명의 개발자들이 거쳐간 서비스는 대체로 나같은 신입 뿐만 아니라 경력직분들도 파악하는데 굉장한 어려움을 느끼며 초반에 먼저해야하는 작업이다. 해당 서비스의 목적과 히스토리 그리고 배포 및 빌드 방법과 같은 문서가 제대로 정리 되어있다면 후에 오는 개발자들을 위해 도움이 될뿐만아니라 시간이 지나고 다시 유지보수를 해야할때 자신에게도 굉장한 시간절약이 될것이다.
테스트의 경우, 코드 리팩터링 과정을 거치고 당연히 내가 만진 부분만 테스트 후 커밋해서 서비스 배포를 진행 했는데 주문을 하는과정에서 내가 고친 코드의 오류로 인해 다른 증정 상품이 나가게된 상황이 발생했다.... 이때 굉장한 멘붕이 왔고 정신을 차리고 난후 테스트의 중요성이 여기서 나오는구나라고 느끼게 되었다. 3+5=8이라는 당연한 결과를 테스트 하지 않는것은 수백 수천개의 함수와 클래스로 이뤄진서비스에서 하나가 바뀌게 되면 3+5=300이라는 결과를 초래할수 있다. 이는 내가 고친 부분이 다른곳에도 영향을 끼치기 때문이며 시간을 생각했을때도 매번 고칠때마다 직접 하나하나 확인하는것이 아닌 똑같은 상황을 테스트 코드로 미리 설정해둠으로써 우리가 예상한 3+5=8이라는 결과가 커밋시에 매번 서비스 전체적으로 동일해야함을 확인하는 과정을 거침으로써 문제발생을 대비할수 있다.
주저리 주저리 말이 많았는데 100일간 나도 모르는 사이에 실력이 많이 늘어난것 같다는 느낌을 받고 있고 새로운것을 습득하는 재미를 느낀다. 사실 나는 도움이 안되고 그냥 민폐만 끼치는거 같다라는 생각때문에 조급해하며 회사일에만 메달려 있었는데 매번 조급해하지 않아도 된다는 좋은 동료분들이 있어서 다행이고 그런 조급함이 오히려 나의 성장에 도움을 줬다는 생각도 한다. 이제는 워라벨을 찾아 보려 하는데 취미중 하나로 기술 블로그를 활성화 시키는걸 해볼까 한다. 암튼! 다음 마음가짐 카테고리는 200일차에 오늘걸루!!! 그때 까지 화이팅이다~
'개발 life > 마음가짐' 카테고리의 다른 글
| 스타트업 신입 개발자가 되었다!(15일만의 퇴사후 이직썰) (1) | 2022.08.20 |
|---|---|
| it 연합동아리 '프로그라피'시작 (0) | 2022.03.24 |
| 창업? 개발자 취업? 목표가 무엇일까? (0) | 2022.01.06 |
| 요기요 채용 설명회(OMT) (0) | 2021.11.17 |
| 다가오는 취업의 압박- 개발자 취업 방법 (0) | 2021.10.20 |
