작심삼일 개발이야기

리팩토링 정의 리팩토링 → 겉보기 동작은 유지한 채, 이해하기 쉽게 내부 구조를 변경하는 기법 리팩토링 과정에서 발견된 버그는 리팩토링 후에도 남아 있어야 한다. 리팩토링은 코드를 이해하고 수정하기 쉽게 만드는 것이다. 리팩토링을 진행하며 버그를 고치지 말라고 하는데... 눈앞에 버그를 놔두고 지나가야 하는 건가 라는 의문이 든다. 리팩토링 하는 이유 코드만 봐서는 설계를 파악하기 어렵다. 코드량이 줄면 수정하는데 드는 노력은 크게 달라진다. 모든 코드가 언제나 고유한 일을 수행함을 보장한다. 내 의도를 더 명확하게 전달하기 위해 다른 사람을 배려하기 위해서가 아니라 바로 나 자신을 위해 버그를 찾기 쉽다. 기억할 필요가 있는 것들은 최대한 코드에 담아내자 (외부에 담으려 X) 일단 리팩토링을 하는 이유..

JS에서 객체 프로퍼티 접근법은 2가지가 있다. const obj = { a: "A" }; // 마침표 접근법 obj.a; // 대괄호 접근법 obj["a"]; 객체에 값을 수정하거나 추가할 때는 아래의 방법으로 하면 된다. const obj = { a: "A" }; // 수정(마침표 접근법) obj.a = "a"; // 수정(대괄호 접근법) obj["a"] = "a"; // 추가(마침표 접근법) obj.b = "B"; // 추가(대괄호 접근법) obj["b"] = "B"; TS에서는 JS와 같은 방법으로 추가하면 에러가 발생한다. (수정은 괜찮다.) const obj = { a: "A" }; // 추가(마침표 접근법) obj.b = "B"; // 추가(대괄호 접근법) obj["b"] = "B"; Pro..

앞에 작성하지 않는 단원들은 JAVA 친화적으로 너무 보기 싫어서 안 봤다 ㅋㅋ 몰라 마지막 단원으로 17장 읽고 클린 코드는 여기서 마무리! 솔직히 17장만 읽어도 이 책이 어떤 말을 하려는지 알 수 있는 것 같다. 주석 극단적인것 까지는 아니지만 주석은 99% 필요 없다고 생각을 가지고 있다. 물론 이 책을 읽으며 생각이 점점 확고해지지만 확실히 코드를 보다 보면 관리되는 주석을 본 적이 없다. 그럴 바엔 차라리 안 쓰는 게 좋다는 생각이 점점 커지는 중... 부적절한 정보 주석은 코드와 설계에 기술적인 설명을 부연하는 수단이다. 예를 들어, 소스 코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템, 기타 기록 관리 시스템에 저장할 정보는 주석으로 적절하지 못하다. 이러한 것들은 git을 이용해..

100번째 글로 뭘 쓸까 하다가 기나긴 추석 연휴도 끝난 겸 기분이 우울하니 오랜만에 일기로 때우기 물론 처음 글 쓸 때처럼 불타오르지는 않지만 개발 블로그를 잊지 않고 쓰려고 노력하고 있다. 벌써 경력 1년 채웠고... 올해도 3달 정도 남았고... 개발실력은 늘지 않는 것 같고... 나만 뒤처지는 느낌 아 모르겠다~ 네 제가 바로 물경력입니다. 200, 300개 꾸준히 글 써야지 ~ 많이 봐주세요 잠들면 출근해야 된다 ㅋㅋ ㅋㅋ ㅋㅋ ㅋㅋ 아 ㅋㅋ ㅋㅋ ㅋㅋ ㅋㅋ 자야지... 추석 때 찍은 달 사진 자랑할게요 (댓글에 소원 적어주시면 이루어집니다. 진짜)

스터디 끝나고 일주일이 지났다. 오늘은 14장을 진행하는 날인데 아무도 준비하지 않았다 ㅋㅋㅋㅋ 그래서 저번에 올리지 못한 13장을 올릴꺼다. 이번 내용은 같은 팀원의 요약을 가져왔찌만 이해는 못했따. 동시성과 깔끔한 코드는 양립하기 어렵다. 동시성이 필요한 이유 구조와 효율을 개선하기 위해 응답 시간과 작업 처리량을 개선하기 위해 무엇과 언제를 분리하게 되면 시스템 구조가 크게 달라진다. 하지만 동시성이 성능을 항상 개선하는 것도 아니고, 부하를 유발하고 복잡하고 버그도 재현하기 어렵다. 동시성 코드로 인해 발생할 수 있는 문제로부터 시스템 방어하는 방법 단일 책임 원칙 동시성 코드는 다른 코드와 분리하라. 임계영역의 수를 줄인다 보호할 임계영역은 synchronized 키워드로 보호하라고 권장하는데,..

17일 스터디를 진행하고 벌써 일주일째 다되어가서 늦은 업로드 휴가를 쓰면 공부도 하기 싫고 일상으로 돌아오기가 더 힘든 것 같다 창발적 설계로 깔끔한 코드를 구현하자 여기서 창발적이란 집단 지성? 같은 의미인 것 같다. 개별적으로 보면 크지 않지만 모이면 시너지가 생기는 그런 느낌 켄트 벡이 제시한 단순한 설계 규칙 네 가지 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 의도한 대로 돌아가는 시스템을 내놓아야 한다. 테스트 케이스를 많이 작성할수록 결합도를 낮춰야 한다. 테스트 케이스를 작성하면 설계 품질이 높아진다. 단순한 설계 규칙 2~4: 리팩터링 테스트 케이스를 모두 작성했다면 점진적으로 ..

패스트 캠퍼스의 short book에 조은 개발자님의 지금 시작하는 프런트엔드 개발자를 위한 조언 책이 발간되었다. 요즘 공부도 하기 싫고 그렇다고 놀 수는 없고 short book이라고 하길래 가볍게 읽을 마음으로 구매해서 읽었다. 정말 short 해서 완독까지 1시간 정도 걸린 것 같다. 책 내용을 정리하기 보단 책을 읽으면서 느낀 점 위주로 적어보려 한다. 학습: 이론과 실전 프런트엔드 개발을 하면서 에러를 고치긴 고쳤는데 왜 고쳐졌는지 모를 때가 있었다. 문제없이 동작은 해서 넘어갔지만 좋은 습관은 아닌 것 같다. 나는 물론 리액트를 사용하며 개발을 진행하니 자바스크립트의 딥한 영역까지 몰라도 구현이 가능하긴 하다. 하지만 왜 가능하냐고 묻는다면 대답을 할 수가 없다. 언제까지 미뤄둘지는 모르겠지..

11장 시스템 도시를 세운다면? 도시가 돌아가는 이유 중 하나는 적절한 추상화와 모듈화 때문이다. 소프트웨어 팀도 도시처럼 구성한다. 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴보는 장이다. 시스템 제작과 시스템 사용을 분리하라 제작(construction)과 사용(use)은 아주 다르다. 소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야 한다. (프론트엔드 관점에서는 무슨 말인지 1도 모르겠다) 시작 단계는 관심사 분리를 해야한다. 책에서 소개하는 초기화 지연(Lazy Initialization), 계산 지연(Lazy Evaluation)이 있다. 따로 간단하게 정리를 해두어서 링크로 대신한다. (지연 초기화) 초기화 지연, 지연 초기화 어떤 단어가 맞는지 잘 모르겠다. 확장 개발을 할 때 우..

클린 코드 책을 읽다 지연 초기화에 대해 조금 더 알아봤다. 마침 리액트 최적화에 관련된 글을 찾아서 정리해봤다. 아래의 두 코드를 비교해보자 코드 1 const Counter = () => { const [count, setCount] = useState( Number.parseInt(window.localStorage.getItem(cacheKey)), ) useEffect(() => { window.localStorage.setItem(cacheKey, count) }, [cacheKey, count]) return ( Count: {count} setCount((prevCount) => prevCount - 1)}>- setCount((prevCount) => prevCount + 1)}>+ ) ..

Next.js에서는 웹페이지의 사용 방식에 따라서 다양한 방식으로 데이터를 가져올 수 있다. 아래에서 설명하는 방법으로 적절한 방법으로 사용하면 될 것 같다. SSR (Server-side rendering) SSG (Static-site generation) CSR (Client-side rendering) ISR (Incremental Static Regeneration) SSR export async function getServerSideProps(context) { return { props: {} } } 해당 함수를 사용하면 서버에서만 실행되고 브라우저에서는 실행되지 않는다. 페이지에서만 사용할 수 있다. 언제 getServerSideProps를 사용해야 되나? 데이터를 가져와야 하는 페이지..