make it happen 123

22년의 이도현

다니던 회사를 그만두고 프로그래밍 공부에 전념해야겠다고 다짐한 후 벌써 1년이 흘렀다. 22년을 마무리하는 시점에서 지난 1년 동안 이루어 낸 것들과 아쉬웠던 부분을 정리해 보고, 23년 목표를 설정해 보려고 한다. 22년에 이루어 낸 것들 개발과 관련된 기반 지식을 많이 쌓았다. 멀게만 느껴졌던 서버, DB 와 같은 분야를 가볍게나마 배워보면서 전체적인 웹의 흐름을 조금 더 이해할 수 있게 되었다. 또한 알고리즘과 자료구조에 대한 공부를 통해 구현능력과 사고력도 높아진 것 같다. 자바스크립트 코어도 꾸준히 학습하면서 기본 동작 방식에 대한 이해도 할 수 있었다. 처음으로 누군가에게 도움 되는 서비스를 만들었다. 친구의 업무 환경을 개선해 줄 수 있는 서비스를 만들어 실제로 유의미한 성과를 냈는데, 이를..

목표와 회고 2022.12.30

우테코 프론트엔드 5기 - 최종 코딩 테스트 후기

12월 17일 토요일, 최종 코딩 테스트를 치렀다. 이번 후기에서는 프리코스 종료부터 시험 이후의 복기까지의 과정과 우테코 지원 과정을 최종적으로 마치며 드는 생각을 정리해 보려고 한다. 📆 1차 합격자 발표까지 주어진 3주 프리코스 4주 차를 마치고, 1차 합격자 발표까지는 3주 정도의 시간이 있었는데, 프리코스 종료 안내 메일에서는 2~4주 차 미션을 다시 구현해 보길 권했다. 매주 미션을 진행하면서도 스스로 부족함을 느낀 부분이 많았고, 제출했던 미션 코드를 보면서 경악을 했던 기억도 있던 터라 자체적으로 프리코스를 연장해서 진행했다. 🚴‍♀️ 기존 미션 복습 프리코스 종료 이후 바로 숫자 야구, 로또, 다리 건너기 미션을 복습했다. 복습을 하면서, 이전 제출 코드와는 확연히 비교되는 코드를 작성할..

목표와 회고 2022.12.21

우테코 프론트엔드 5기 - 프리코스 4주 차 후기

프리코스의 막이 내렸다. 말로 표현할 수 없는 감정이 오간다. 지금 이 감정에 대한 이야기는 글 마지막에 하도록 하겠다. 이번 후기에는 미션으로 성장했던 부분을 설명하고, 마무리로는 앞으로 프로그래밍을 공부하며 내가 가져야 할 태도와 자세에 대해 적어 보겠다. 🔧 3주 차 공통 피드백 수용 4주 차 미션 시작에 앞서 3주 차 공통 피드백을 점검했다. 객체의 상태 접근을 제한한다 객체는 객체스럽게 사용한다. / 데이터를 꺼내지 말고 메시지를 던지도록 구현한다. 필드의 수를 줄이기 위해 노력한다. 피드백의 worst 코드가 내 코드와 정확히 일치해서.. 뜨끔했다.. 객체를 분리했다면 getter메서드로 데이터를 꺼낼 것이 아니라, 분리한 이유에 맞는 기능이 구현되어 있어야 한다는 뜻으로 이해했다. (위 내용..

목표와 회고 2022.11.22

Git - merge, rebase 개념과 차이

여러분은 branch를 병합하는 방법을 알고 계시나요? 우리는 협업 환경에서 Git을 사용합니다. 각 팀원은 자신이 맡은 기능을 개발하기 위해 branch를 만들어 작업합니다. 팀원들의 개발이 끝났다면, 모두의 작업물(branch)을 한 곳에 모아 하나의 작품을 완성해야 합니다. 이번 포스팅에서는 branch를 병합하는 대표적인 방법인 merge와 rebase에 대해 알아보겠습니다. 포스팅에 쓰이는 모든 시각화 자료는 https://learngitbranching.js.org 에서 발췌하였습니다. Git의 여러가지 기능을 배우기 정말 좋은 사이트이니 사용해보시는 걸 추천합니다. Learn Git Branching An interactive Git visualization tool to educate an..

Git 2022.11.18

우테코 프론트엔드 5기 - 프리코스 3주 차 후기

프리코스 3주 차를 마무리했다. 3주 차는 매일매일 눈 떠보면 시간이 사라지는 마법 같은 하루를 보냈다.😅 뒤이어 설명할 추가된 요구사항이 큰 몫을 해줬다. 이번 후기도 성장했던 부분과 차주 목표를 중점으로 적어 나가 보겠다. 🔧 2주 차 공통 피드백 수용 3주 차 미션 시작에 앞서 2주 차 공통 피드백을 점검했다. README.md를 상세히 작성한다. 기능 목록을 재검토한다. 기능 목록을 업데이트한다. 이전 미션을 진행하면서, 기능 구현 목록 작성에 너무 많은 시간을 할애했던 기억이 있다. 상세히 작성하는 것은 중요하지만 그렇다고 함수, 메서드의 설계와 구현처럼 언제든지 변경될 수 있고 구현하는 시점이 되어봐야 알 수 있는 것들을 미리 생각하고 적지 않도록 주의하라는 내용이었다. 이 피드백을 보고 첫 ..

목표와 회고 2022.11.15

Jest - Matcher란?

여러분들은 Jest로 테스트 코드를 작성할 때 다양한 Matcher를 사용하고 계시나요? 오늘은 Jest에서 테스트 코드를 작성할 때 자주 사용하는 Matcher에 대해서 알아보겠습니다. 1. toBe( value ) 기본형을 비교할 때 자주 사용합니다. 값이 같은지 비교합니다. 대상이 원시형(primitive type)이라면 값을 비교하고, 참조형(reference type)이라면 같은 대상을 참조하는지 비교합니다. (얕은 비교) describe("toBe 테스트", () => { test("원시형 비교", () => { const result = "123"; expect(result).toBe("123"); // test passed! }); test("참조형 비교", () => { const res..

Testing 2022.11.12

우테코 프론트엔드 5기 - 프리코스 2주 차 후기

프리코스 2주 차를 마무리했다. 2주 차 미션은 우여곡절이 훨씬 많았다. 그걸 다 부셔내고 후기를 적고 있다니... 확실히 성장했다! 이번 후기도 성장했던 부분과 차주 목표를 중점으로 적어 나가 보겠다. 🔧 1주 차 공통 피드백 점검 2주 차 미션 시작에 앞서 1주 차 공통 피드백을 점검했다. 커밋 메시지를 의미 있게 작성한다. 1주 차 미션을 진행하며 커밋 컨벤션을 적용했지만, 익숙하지 않은 탓에 실수를 많이 했었다. 의미 있는 커밋 메시지에 대해 리마인드 했다. 이름을 통해 의도를 드러낸다. 축약하지 않는다. 공백 라인을 의미 있게 사용한다. 변수, 함수명을 축약하다가 중의적인 표현이 되어버린 적이 많은 것 같다. 이름이 길어지더라도 확실한 의도를 전할 수 있도록 해야겠다고 생각했다. space와 t..

목표와 회고 2022.11.08

Testing - 테스트 코드의 목적과 규칙, Jest 기본 문법

여러분들은 테스트 코드의 중요성을 알고 계신가요? 많은 개발자들이 자신이 작성한 코드를 테스트하기 위해, 또는 더 좋은 코드를 작성하기 위해 테스트 코드를 작성합니다. 코드를 위해 또 코드를 작성한다니 의아하지 않나요? 오늘은 테스트 코드를 작성하는 이유와 많은 개발자들이 사용하고 있는 Jest 테스팅 라이브러리에 대해 알아보겠습니다. 1. 테스트 코드의 목적 테스트 코드를 작성하는 목적이자 장점은 대표적으로 다음과 같습니다. 개발 과정 중 예상하지 못했던 문제를 미리 발견할 수 있다. 작성한 코드가 의도대로 동작하는지 검증할 수 있다. 코드 리팩터링 후 기존 소스와 동일한 동작을 하는지 검증할 수 있다. 장점만 있지 않겠죠? 흔히 테스트 코드의 단점으로 다음을 말합니다. 테스트 코드까지 작성해야 하므로..

Testing 2022.11.03

우테코 프론트엔드 5기 - 프리코스 1주 차 후기

드디어 기다리던 프리코스가 시작되었다! 짧은 시간이었지만, 배운 것은 엄청났고 성장했다. 남은 프리코스 기간동안 성장과 약점 보완을 목표로 달려나갈 것이다! 앞으로 매주 프리코스 후기를 작성하며 지난 한 주를 정리하려 한다. 성장했던 부분과 차주 목표를 중점으로 적어 나가 보겠다. 🏄‍♂️ 1주 차 미션 - 온보딩 1주 차 미션은 코딩 테스트와 유사한 형식의 과제였고, 총 7개의 문제를 요구사항대로 처리해야 했다. 여러 요구 사항 중, 내가 가장 많이 성장할 수 있었던 요구 사항은 다음과 같다. 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다. 🎯 기능 구현 목록의 중요성 계획 없이 무작정 시작한 개인 프로젝트를 완성하기 위해 정말 많은 시간을 투자한 경험이 있다. 구..

목표와 회고 2022.11.01

Git - Commit message convention이란 ?

여러분은 Git을 어떻게 사용하고 계시나요? commit message는 올바르게 작성하고 계시나요? 저는 Git을 작업 내용을 저장하거나, 기록을 남기는 [혼자만의 저장소] 느낌으로 사용하고 있었습니다. 때문에 commit message 또한 적당히 얼버무려 작성하곤 했죠.. 하지만 실제 개발 업무는 대부분이 협업으로 이루어지고, 한 프로젝트를 여러 명이서 관리하게 됩니다. 때문에 협업 환경에서 효과적으로 Git을 사용하려면 Commit message convention을 지켜야 합니다. 이번 포스팅에서는 많은 개발자들이 사용하는 대표적인 구조를 토대로 설명하겠습니다. 1. commit message 기본 구조 기본 구조는 다음과 같습니다. (scope): (body) (footer) ..

Git 2022.10.29