프로그래밍 독서 (16) 썸네일형 리스트형 더 괜찮은 개발자가 되기 위한 리액트 스타일 가이드 들어가면서 프리코스와 Lv1의 Vanilla JS를 거쳐서 Lv2 에서는 리액트로 프로젝트를 하고 있다. 우테코에서는 '야생학습'을 강조하는데.. (궁금하면 함께자라기 라는 책을 찾아보시라) 나는 학교생활을 오래해서 그런지는 몰라도 좋은 레퍼런스가 없으면 공부가 잘 안되는 스타일인데다가, 목표가 없으면 멍때리고 있는 시간이 많아서 뭔가 미션이후 코드리뷰 수정하기 싫은날이면 책을 꼭 읽곤 한다. '더 괜찮은 개발자가 되기 위한 리액트 스타일 가이드' 는 잠실캠퍼스에 구비된 책인데 도서관에서 빌려보기 전에 여기서 오늘안에 다 읽고 정리해보자는 마음가짐으로 도전해보려고 한다. 이번 미션이 끝나기 전에 다 읽고 습득할 수 있기를 바라며... 시작한다!! 인사이트1 꽤 옛날 책이라서 읽는건 자유이나 가볍게 읽으라는 이야기를 들어서 가볍게 얻은 인사이트 위주로 정리하도록 하겠습니다. 1. 렌더를 할때 아이콘이나 이미지등이 개당 조그마한 시간을 차지해도 요즘은 굉장히 많은 이미지들이 첨부돼서 시간에 차이가 많이남. 이걸 해결하기위해서 css스프라이트등을 쓰기도 했음 2, 코드스타일 대부분의 브라우저에서 배열에 push메서드를 쓰는것(ex arr.push(i))보다 리터럴 방식을 쓰는것(ex arr[i] = i)이 두배정도의 성능이득이 있음. 오브젝트의 경우에는 리터럴을 쓰나 연산자를 쓰나(ex obj.i = i) 큰 성능차이가 없었음 3. 코드스타일 스코프 체인에 관해서 생각해봐야함. 현재 찾는 위치에 데이터가 없으면 그 상위 스코프에 가서 데이터를 찾아야함. 이러면 .. 3. 그래서 애자일이 뭔데 애자일. 참 많이 들어봤지만 아직도 뭔지 모르겠다. 정처기만 봐도 애자일 모델, 애자일 방법론.. 참 어렵다. 애자일은 불확실 성이 높은 문제를 해결하기 위해서 문제 해결 방법론이 공통점을 모아서 만든 방법론이다. 프로그래밍은 계속해서 변경, 수정점이 생기고 시장도 바뀌고, 사장도 바뀌고, 팀원도 바뀌고, 구조도 바뀌고 참.. 많이도 바뀐다. 불확실성이 높은 분야다..! 애자일이 너무 잘 어울릴 것 같지 않은가? 하지만 애자일은 마법의 키는 아닌 것 같다. 다만 우리가 어떻게 살아야 할지 고민하게 해주는 간단한 행동강령 같은 느낌이었다. 내가 뽑아낸 애자일의 Key Point는 '빠른 피드백' 이다. 고객도 팀원으로 생각하는게 좋지 않나 싶다. 고객과도 소통을 많이할수록 좋다. 2. 함께. /*예전에 협동에 대해서 이야기 할때면 꼭 나오는 예시가 있었다. 3명의 팀원이 추운 설산을 가는데 동료 한 명이 다리를 다쳤다. 업고가지 않으면 도저히 데려갈 수 없는 상태. 한 동료는 어쩔 수 없겠다며 다친 동료를 버리고 금방 없어져 버렸고, 당신은 동료를 버리지 못해 업고 가기 시작한다. 우여곡절끝에 다리를 다친 동료를 데리고 산장에 도착한 당신은 먼저 간 친구고 아직 못왔다는 소식을 듣게 되고, 다음날 그 친구는 싸늘한 주검으로 발견된다. 당신은 다친 동료를 업고 오면서 체온을 보존하기가 더 쉬웠기 때문에 먼 캠프까지 올 수 있었던 것!! 하지만 혼자간 친구는 빨리 갔지만, 체온을 못 보존해서 금방 죽어버린 것이다. 아프리카 속담에도 비슷한 말이 있다. "혼자가면 빨리 가지만, 함께가면 멀리간다... 1. 자라기 위한 조건 '경력, 그 견딜수 없는 무거움' 이라는 소제목이 눈길을 끈다. 연구실에 갔다가 박사과정을 하지 않고 나오는 친구들이 있다. 여러 사정이 있겠지만, 몇몇은 박사를 나왔는데 쓸만한 연구 하나 가진게 없다면 그거야 말로 큰일이라면서 연구실을 나왔다고 하는 친구들이 있다. 경력이 모든것을 보여주던 시대는 지났다고 생각한다. 짬만 차면 세상이 내 발 아래 있을 줄만 알았던 군생활과는 다르게, 나는 매일 성장하지 않으면 안된다. 어떻게 잘 하는가 보다 어떻게 자라는가 가 이 책의 전부다. '특정 영역에서 개인이 얻을 수 있는 최고의 퍼포먼스는 경험을 오래한다고 해서 자동적으로 얻을 수 있는 것은 아닙니다.' (에릭슨) 양치질에 대한 비유를 든다. 우리는 양치를 20년 가까이 하지만 양치의 달인이 되지 않는다. 크.. 10. 클래스 클래스를 예쁘고 깨끗하게 만드는 팁에관한 챕터입니다. 몇가지 팁이 나와있었습니다. 중요한것은 클래스를 작게 쪼개서 이해하기 쉽도록 만드는 것입니다. 같은 10개의 기능을 가진 클래스를 1개로 만드나 10개로 만드나 정보량은 같지만 10개로 쪼갰을때에 각 클래스가 가진 권한이 분리돼서 이해하기 쉽습니다. 또한 프로그램은 지속적으로 수정과 변화가 일어나기 때문에 클래스와 메서드는 최대한 작게 쪼개서 단일한 일만 하도록 하는것이 좋습니다. - 순서 처음 나오는 부분은 클래스 안에서의 순서입니다 1. static public 2. static private 3. private instance 4. public method 의 순서대로 하는게 국룰이라고 합니다. - SOLID 1. SRP(Single Respon.. 9. 단위 테스트 가장 중요한 3요소. 가독성, 가독성, 가독성 테스트 코드는 실제 코드와는 다르지만 수평하게 생각해야한다. 아무렇게나 짜면 안된다. 제 1번 요구사항은 가독성이다 아래에서는 좀더 세분화한 다섯가지 규칙 (FIRST 규칙)을 제시한다. 1. Fast 빠른 빠르지 않은 테스트 코드는 점점 돌리기가 힘들어지고 유지보수에 문제를 만든다 2. Independant 독립적인 각 테스트가 서로 의존하고 있으면 점점 테스트코드를 분화시키기 어려워진다. 각 함수가 한가지 일만 하는 것처럼 각 테스트도 한가지 일만 해야하고 서로 독립적일수록 좋다. 3. Repeatable 반복하는 환경이 바뀌어도 반복가능해야한다. 집이든 회사든 어디서든. 4. Self-validating 자가검증하는 결과를 성공, 실패로만 내야한다. 결.. 8. 경계 뒷 파트로 갈수록 확실히 책의 전반부와 다르게 협업을 위한 방법들이 많이 소개되는것 같습니다. 아직 배움이 짧아서 공감하기 어려운 내용들이지만 완주를 목표로 이해한만큼 기록하겠습니다. 개발을 하게 되면 다양한 api나 라이브러리 등을 가져다 써야할 일이 생깁니다.(거의 무조건) 이럴때 확장성을 잘 생각하며 짜야합니다. 일종의 도킹처럼, 결합하는 그 부분에서 생기는 이슈와 결합후 호환에 대한 이슈를 고려해야 합니다. 책에서 추천해주는 가장 좋은 방법은 test를 적극 활용하는 것입니다. 코드를 직접 뜯어서 하나하나 이해하는 것보다 용도에 맞게 test를 통해서 사용법만 익히면서 배우는 것이 훨씬 경제적 이라고 주장합니다. 이전 1 2 다음
