분류 전체보기339 신입사원이 미리 알면 좋은 꿀팁 [시간]1. 20분 전회사에 최소 20분 전에 도착하기딱 20분 전까지 도착하려고 하면 5분 전에 도착하게 됨아침에는 여러 변수가 생길 수 있다.특히 지하철 시간이 살짝 밀리거나(앞차와의 간격)사람이 많아서 생각보다 걸어서 이동하는 시간이 길어지거나,회사 내부에서 엘리베이터로 이동해야 하는데, 엘리베이터 대기줄이 있다 !2. 10분 전장소 이동시 최소한 10분 전까지는 앉아있기뭔가를 준비해야 하는데 그 셋팅이 생각보다 잘 안될수도 있다. 미리 점검해보기[이메일]1. 회사 메일 아이디 정하기이건 조금 사바사일수 있고 회사에서 정한 이메일 형식이 있을 수 있는데, 관련 글들을 검색해보면 보통 이름을 활용한 아이디가 가장 무난한 것 같다.여기서 추가한다면 숫자를 넣거나, 특수문자(. 또는 _ )를 넣는건데'이.. 2025. 1. 7. [이벤트] 티스토리 오블완 챌린지 https://www.tistory.com/event/write-challenge-2024 작심삼주 오블완 챌린지오늘 블로그 완료! 21일 동안 매일 블로그에 글 쓰고 글력을 키워보세요.www.tistory.com 2024. 11. 5. component와 hook 에 적용한 SOLID - [hook 편] 목차SOLID 원칙 - FrontEnd에 적용이 가능할까?내 코드 의존성의 원인해결 방법 - component 또는 hook이 알아야 하는 정보 줄이기 (S: 단일 책임 원칙)잘못 설계하는 과정 (실제 예시) - 어떤 컴포넌트를 만드는지 알려줄 거에요.hook이 담당하는 데이터를 최소한 작게 분리해서 생각해보기 - 의미 덜어내기hook 분리의 장점 (O: 개방 폐쇄 원칙)컴포넌트와 컴포넌트 hook과 hook 간 최소한의 소통 통로 (I: 인터페이스 분리 원칙)수정된 설계 과정 (실제 예시) - 어떤 컴포넌트를 만드는지 안 알려줄 거에요.추가된 요구사항 (실제 예시)잠깐 component이야기를 해보자. 렌더링에서 예상치 못하게 의존성이 문제가 되는 지점 - map 메서드 고찰 (I: 인터페이스 분리 원.. 2024. 7. 21. 6월 회고 - 코드 의존성 줄이기 사이드 프로젝트를 하면서, 엄청나게 강한 결합으로 이루어진 코드는 리팩토링할 때 시간이 엄청 소요될 수 있다. 는 걸 깨달았다.그리고 추상화가 잘 되어있어야 코드를 수정하기에도 편하다. 는 것도 깨달았다.고칠 곳이 너무 많은데, 코드도 복잡하면..... ? (내가 작성한) 꾸린 코드의 복붙을 쉽게 생각하지 말자.. 나중에 할 일이 기하급수적으로 늘어나고, 후회한다.종종 책을 읽으면, '조립식' 코드에 대한 설명이 나오는데, 아 정말 맞다. 조립식이 가능해야 한다... 그렇지 않으면 리팩토링에 걸리는 시간도 많이 걸릴 뿐더러, 정말 리팩토링이 가능할까?시간이.. 코드 복붙은 1초도 안걸리지만, 그걸 정리하는데는 수십배가 든다. 수십배??? 아니, 수십배는 너무 적게 쳐줬다.반나절이 걸릴수도 있다. 이미 복.. 2024. 6. 30. 비동기와 이벤트 루프 이벤트 루프의 동작을 정리하고,비동기 코드의 동작 순서를 정리합니다. 🌸 잘못 이해하고 있는 내용이 있다면 알려주세요. 감사합니다 🌸 목차ko.javascript.info/event-loop 본문 예시 코드코드의 실행 순서 콜스택의 상태이벤트 루프와 마이크로 태스크 큐, 매크로 태스크 큐자바스크립트 튜토리얼 [이벤트 루프] 카테고리 이해하기'특정 태스크'란?렌더링 시점반복문 내의 DOM 조작은 렌더링과 관련이 있는 걸까? 들어가기 전에, 기억해야 할 내용입니다.콜스택이 비어야 태스크 큐의 작업이 콜스택으로 이동합니다.태스크 큐의 종류(1) 마이크로 태스크 큐 (빨리 처리되는 후속 작업. then, resolve 등)(2) 매크로 태스크 큐 (setTimeout 등) 1. ko.javascript.in.. 2024. 6. 6. 프로그래머스 코딩테스트 KAKAO (JavaScript) 카카오 코딩테스트 문제를 풀이하며, 주로 고민했던 내용들 입니다. 주로 아쉬웠던 부분을 정리했습니다.이진트리데이터 테이블 생성엣지케이스(MECE)선언적 코드 ↔ 절차적 코드(count변수, index변수, start변수, end변수 .... 예측불가. 과연 맞나?)메모이제이션 배열 개수MECE정규표현식효율성특이한 케이스시간복잡도와 중첩 반복문나쁜 코드 작성 습관(미리 일부 케이스를 셋팅해놓기, answer에 해당하는지를 먼저 if문으로 작성해서 인덴트 증가, 많은 조건문)제너레이터 사용으로 early return함수화 하는 이유: 모듈화 및 테스트 정보를 분리해서 생각하기(서로 어떤 시점의 데이터가 필요한지. 뭔가를 합쳐서 생각하고 있을 수도)반례 찾기 연습 선언적으로 작성하는 방법 고찰. . . JS.. 2024. 4. 25. 팀원과 소통 비용 줄이기 (고찰) 경험적으로 얻은 교훈을 작성해보려고 합니다. 1. 상대방에게 요구하는 사항, 질문 의도를 먼저 말한다. 2. 개조식으로도 표현이 가능한지 확인 3. 문장이 너무 길어지지는 않는지 확인 4. 모호한 표현이 있는지 점검해서 보완한다. (조건 또는 수식어를 함께 작성) 5. 줄 간격이 좁은 경우 엔터로 단락을 구분한다. 6. 이미지 첨부 1. 줄글은 가독성이 떨어질 수 도 있다. 음? 설명을 길게 해야, 내가 고민한 부분들을 모두 전달할 수 있지 않을까? 그런데 글은, 읽는 상대방을 배려해야 한다. 너무 많은 정보가 한꺼번에 등장하면, 글을 이해하기 위해 다시 처음부터 읽어야 할지도 모른다. 글을 다 읽고, 다시 파악하기 위해 고민해본적이 있는지 생각해보자. 그래서 무엇을 말하는 거지? 여기서 요구하는 나의 .. 2024. 3. 28. 좋은 코드, 나쁜 코드 프로그래머의 코드 개선법 https://product.kyobobook.co.kr/detail/S000061353995 좋은 코드, 나쁜 코드 | 톰 롱 - 교보문고좋은 코드, 나쁜 코드 | 이 책의 가장 큰 특징은 나쁜 코드가 왜 나쁜 코드인지 설명하고, 나쁜 코드를 좋은 코드로 바꿔가는 과정을 직접 보여주는 것이다. 이를 통해 독자는 좋은 코드와 나쁜product.kyobobook.co.kr PR 리뷰를 하면서, 주관적이지 않은 지표가 있을까 고민하기 시작하게 되었다. 특히 설계에 관해서는 best practice가 있는지 궁금해서 책을 읽어보게 되었다. 책에서는 왜 좋은 코드를 작성해야 하는지를 먼저 설명한다. 당장은 개발하는 데만도 시간이 부족하더라도, 신경써서 작성하지 않으면 생산성이 떨어지기 때문이라고 강조를 하는데 .. 2024. 3. 22. 6개월, 프론트엔드 회고 내가 했던 것, 그리고 미리 생각해봤더라면 좋았을 내용 PR에 gif 이미지 첨부(PR을 더 잘 설명하기 위한 방법)커밋 생활화타 팀원과 교류하기팀에서의 나의 페르소나 돌아보기(예측 가능한 사람이 되도록)팀워크를 위해 팀규칙과 컨벤션 정하기스크럼 시간에 오늘의 할 일 목록 만들기(목표 달성으로 인한 성취감)팀원의 요청에 대한 나의 태도(긍정적인 방향으로 생각해보기)문서화. 변경사항 발생 시 반드시 알리기원격 근무시 갖춰야 할 태도(소통의 양방향성을 위해 카메라와 스피커를 켜야 하는 이유)슬랙 스레드를 읽고 반응 남겨야 하는 이유(읽은 사람 체크, 리마인드, 의견에 대한 반응 확인)팀 프로젝트 회고글 1. 첫 과제 PRGIF 이미지와 함께 업로드 간단한 과제였지만,● 직접 코드를 실행하지 않고도● 코드.. 2024. 3. 17. 이전 1 2 3 4 ··· 38 다음