2021 상반기 회고 (1~6월)

코딩테스트 알고리즘 준비

---

개인적으로 알고리즘 공부에 대해 회의적이었다.

실무에서 큰 도움이 되는거 같지도 않고... 문제를 풀기위해 학습하는 느낌이 강했다.

하지만 이직을 위한 1차 관문이 일반적으로 코딩테스트이기에 준비는 해야했다.

학업을 위한 공부와 문제풀기를 위한 공부는 따로 있다고 생각해서,

A-Z까지 모든 알고리즘을 정석으로 공부하기 보다는 코딩테스트 통과를 목적으로 준비했다.

1) 어떤 문제를 풀어야할까 ?

알고리즘을 연구해 코딩계에 내 이름이 박힌 알고리즘을 만들고 싶진 않아서 효율적으로 풀거만 알아보기로 했다.

구글링하다가 찾은 동빈나님 유튜브에 어느정도 가이드라인이 있어서 참고해 방향을 잡았는데,

그간 코딩테스트를 풀면서 버벅이던 부분과 같은 부분이어서 집중 보완하기로 했다.

탐색 / DFS / BFS 등 전체를 탐색해 가장 효율적인 루트 하나를 찾아내는 문제가 바로 그것이다.

2) 어떻게 풀어야할까 ?

leetcode / hackerrank / codility / 프로그래머스 / 백준 등등

여러군데 문제를 살펴봤는데, 주로 푼건 프로그래머스와 백준이었던거 같다.

특히 프로그래머스 고득점 kit와 백준 단계별 풀기를 활용했다.

하루에 한문제씩 출근하자마자 30분 시간을 정해서 풀고 타임오버될때까지 안풀리면 찾아보고 풀고 끝!

한문제를 오래 고민하여 완벽하게 이해하는거보다 여러 문제 푸는 방식 익히는게 더 좋을거 같다고 생각했다.

오래잡고 있어봐야 재미도 없고 푸는 목적은 코딩테스트 통과이기 때문에 딱 통과할 정도의 투자를 했다.

https://chrome.google.com/webstore/detail/timer-25-the-minimalist-t/gmdbcklinofignhfmibchnmgjcocccbh?hl=ko 

Timer 25: 미니멀리스트 타이머

30분 동안 문제를 잡고 있으려면 타이머가 있어야하는데 크롬 확장프로그램 중 요거를 활용했다.

확장프로그램에 남은 시간도 나오고 종료되면 알람도 띄워주기때문에 나름 쏠쏠하게 사용 가능했다.

지방 파견 전까지는 꾸준히 1일1문제를 이어오고 있었고, 종종 실전 코테도 보곤했는데

나름의 성과라면 프로그래머스에서 한번씩 기업 코테를 보게 해주는데 카카오뱅크 코테 1차 패스정도려나

물론 2차는 손도 못댔다...(JPA는 해본적이 없어서...ㅠ)

요즘 JPA도 많은 곳에서 활용하는거 같아서 JPA강좌도 인프런에서 구매해뒀다.

https://www.inflearn.com/course/ORM-JPA-Basic

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

하반기에는 해당 강좌 시리즈를 주루룩 한번 보고 개인프로젝트를 JPA로 해보고 싶다.

현재 일하는 곳에서는 JPA는 사용하지 않아서 볼때마다 늘 새롭고 짜릿하겠지만

한편으론 mybatis를 쓸 때와 JPA를 쓸 때의 장단점이 눈에 보여서 나름 재미도 있을듯 싶다.

하반기 회고에는 재밌는 JPA 프로젝트도 올릴 수 있길 바래본다!

 

공유와 문서화

---

상반기에는 상대적으로 여유가 많았다.

이런 여유 시간이 있을 때 리펙토링과 소스정리를 해놔야 미래의 내가 바쁠 때 지금의 나에게 고마워할 것이기 때문에

속도 개선을 위한 리펙토링과 개발 편의를 위한 소스정리를 해나갔다.

리펙토링을 하면서 이런저런 호기심이 생겨(특히 대량데이터 관련) 테스트도 혼자해보다가 사내 wiki가 떠올랐다.

같은 팀 중 한 분이 정말 열심히 관리해주셔서 그런지 더 쓰고 싶어진거도 있었고,

개발은 공유와 문서화도 필요하다고 생각해서 나름 테스트해본 것과 삽질한 것 등등 모두 wiki에 올렸다.

(물론 변수명 등등 바꿔서 내 블로그에도 올렸다!)

삽질한거에 대한 정리와 API의 문서화는 바빠도 나중에 짬내서 정리하는게 좋겠다.

같은 삽질을 하며 시간 낭비를 하지 않을 수 있고 (심지어 예전에 했던 삽질을 또 하는 경우도 봤다ㅋㅋㅋ...그건 나였고...)

업데이트 된 API의 기능을 직접 소스 분석하며 찾지 않아도 된다.

일하다보면 최신판이 아닌 API 레퍼런스를 종종 보게되는데, 업데이트 된 내용을 몰랐다가 나중에 다른 사람 소스보고

이런 메소드도 있었구나... 하며 사용한 적이 있다.

아는 사람만 보이는 아만보 메소드들을 만들지 않으려면 문서화하는 습관을 들여야겠다.

 

지방 파견

---

공공기관 프로젝트에 투입되어 얼떨결에 지방까지 파견을 가게 되었다.

솔루션은 자사제품이 있는 SI라는 말을 뒤로하고 '회바회!(회사바이회사) 팀바팀!(팀바이팀)'을 외치며 호기롭게 들어갔는데...

그 말을 들을걸 그랬나보다.

출장 개념으로 며칠 다녀오는건 작은 환기가 되어줄 수 있지만, 몇 달 상주는 개인적인 계획도 틀어지고 심신을 지치게 만든다.

SI도 업체 파견 개념이라 자사 서비스가 있는 곳을 원했던건데,

차라리 이럴거면 수도권 내 파견이 보장되는 SI로 옮기는게 더 나은 선택이 아닐까 하는 생각도 든다.

게다가 폐쇄망 업체라 개발자의 생명인 구글링도 못하고 기존 라이브러리만 가져다가 써야하고

이전 회고에도 쓴거 같은데 폐쇄망인 업체는 개인적으로 맞지 않는듯 싶다.

하반기 회고에는 지방 상주의 투덜거림보다는 재밌는 개인프로젝트에 대한 얘기가 가득하길 바라며 이만 마쳐야겠다!