솔적솔적

개발을 하다 보면 시간복잡도(Big-O)와 고차 함수(map, filter, reduce 등)를 모두 접하게 되는데이전에 언뜻 보기엔 전혀 다른 분야의 개념처럼 보였다.시간복잡도는 알고리즘 이론의 영역.고차 함수는 함수형 프로그래밍과 언어 문법의 영역. 하지만 실제 현업에서는 이 둘을 따로 떼어 생각하기 어렵다.왜냐하면, 고차 함수의 사용 자체가 곧 시간복잡도와 직결되기 때문이다. 시간복잡도란? 시간복잡도란, 입력 크기에 따라 알고리즘이 얼마나 빠르게 실행되는지를 수학적으로 나타내는 지표.O(1): 입력 크기와 관계없이 항상 일정한 시간.O(n): 입력 크기에 비례해서 시간이 늘어남.O(n²): 입력 크기의 제곱에 비례해 시간이 늘어남.개발자는 이 복잡도를 바탕으로 코드가 효율적인지 판단한다. 고차..

너는 if문을 왜 그렇게 써?그리고 중첩된 else if, 왜 좋지 못한 코드를 쓰는거야?switch문을 사용할 생각은 없는거야? 여기에서 아, 내가 급하게 기능 구현만하려했었다라는 반성 연이어,협업 시 팀원의 분노게이지를 상승시키지않을만한 좋은 코드란 것에 대해서 돌이키며 유념하고자 정리하는 글이다. 소프트웨어에서 기본 원칙이나 클린 코드 등 책들을 읽으며 알았던 좋은 코드에대해서 정리해보면, 코드를 읽는 사람이 쉽게 이해할 수 있어야하는 “가독성” ⇒ 변수명, 함수명, 들여쓰기, 구조가 직관적이어야한다Readability ⇒ 읽기 쉬운가? 코드 수정이나 기능 추가 시 다른 부분에 영향을 최소화해야하는 “유지 보수성”Maintainability ⇒ 고치기 쉬운가? 중복 코드 제거, 모듈화, ..

오늘의 글은window.location.reload()가 위험할 수 있는 이유와,React 프로젝트에서의 더 좋은 새로고침 전략에 대해서 정리해보고자한다. 버튼 클릭 시 “새로고침”이 필요하다는 요구사항을 종종 만납니다. 흔히 떠올리는 건 바로window.location.reload();하지만, 구현하면서 항상 생각해야한다.이 코드가 우리 프로젝트에 적합한 코드인가? 왜 섣부른 전체 리로드가 위험할까 🤔상태 손실이 되어도 괜찮은가: 메모리 기반 상태(React state, Zustand 등 사용 시) 전부 초기화된다.현재 참여 중인 프로젝트는 i18n을 적용해 한국어/일본어 다국어 선택 기능을 제공하고 있는데,단순히 window.location.reload()를 사용하면 이 상태들도 모두 초기화..

웹에서 '로그인 상태 유지' 또는 '자동 로그인' 기능을 구현할 때어느 저장소에 무엇을 두느냐는 보안, 편의성 균형의 문제다. 1편에서 저장소 종류와 특성을 정리했다면2편에서는 공격 벡터인 XXS/CSRF를 기준으로 실전 방어법과설계 패턴을 이리저리 생각하고 구글링한 결과를 정리해볼 예정이다. (*이건 그저 구현하며 저의 생각을 정리하는 내용이지 정답은 아닙니다.)- Access Token, Refresh Token 같은 것은가능한 클라이언트쪽에서 JS접근 불가한 HttpOnly 쿠키 + Secure + SameSite 설정으로 관리하는 것으로하는 것이 좋다생각한다.- Access Token은 가능한 **메모리(짧은 수명)**에서 관리하고 필요 시 refresh cookie로 재발급한다.- 비민감..