Clean Code

좋은 리뷰 이 부분은 코드 응집도가 조금 낮아보이는데 더 높게 만들 수 있는 방법이 없을까요? 제가 이 부분의 코드를 잘 이해하지 못했는데, 한 번 설명해주실 수 있나요? 이 부분은 ~ 한 것 같은데 제가 보기에는 ~정도의 변수가 더 서술적이고 좋은 것 같아요. 반영해주실 수 있으실까요? LGTM(look good to me)! 정말 고생하셨습니다. 이 부분 코드가 정말 맘에 드네요. 이 부분은 저희 컨벤션이 아닌것 같은데 ~~ 게 변경해주실 수 있나요? 나쁜리뷰 무지성 비난, 대안 없이 그저 비판, 불만만 늘어놓는 리뷰 아 여기 이렇게 하시면 어떡해요. (무관심) PR 리뷰할 때 나쁘게 리뷰를 쓰게 된다면 본인도 그렇고 듣는 상대방으로 하여금 갈등이 생길 것입니다. 생각보다 개발자 사이에서도 나쁜 리뷰..

함수의 분리 (역할과 책임이 다른 것을 명확히 파악하기) // 여기서의 ... 스프레드 연산자가 아닌 내용의 축약을 나타냄 const someArray = [...] //bad someArray.filter((item)=>{ ... }) .map((item)=>{ ... }) .forEach((item)=>{ ... }) //good someArray.filter(checkValid) .map(itemToAnotherItem) .forEach(doSomething) const checkValid = (item) => { return boolean; } const itemToAnotherItem = (item) => { ... return anotherItem; } const doSomething = (i..

추상화? 구체화? 추상적이다, 구체적이다 추상적이다 - 구체적이지 않아 막연하고 일반적인 것 알 필요 없는 정보 숨기기 / 필요한 정보만 노출하기 우리는 아주 가까이에서 추상화가 되어있는 함수를 아주 많이 볼 수 있습니다. // useState 는 그저 state 와 setState 함수만 반환할 뿐 내부 구현은 모두 숨겨져 있음 const [state,setState] = useState(); // useEffect 는 의존성 배열과 콜백을 넘겨주면 알아서 effect를 실행시켜준다는 // 사실만을 노출하고 있음 useEffect(()=>{} ,[]) 이처럼 우리는 너무 복잡한 정보를 제공해주지 않도록 적절히 추상화를 하고 구체적인 정보를 숨길 필요가 있습니다. 아래 코드를 한 번 봐볼까요? // 추상..

명확한 조건 선택하기 긍정조건 사용하기 //bad const isNotBoy = false; //good const isBoy = true; // ! 표기가 잘보이지 않고 부정의 부정이라 조건문을 잘못 해석할 여지가 다분함 if(!isNotBoy){} if(isBoy){} 꼭 부정문을 사용해야할때는?? 조건문에 이름 붙이기 const isBoy = !isNotBoy // if 문 바로 상단에서 긍정 조건으로 변경해주기! if(isBoy){} 함수를 통해서 조건을 사용하자 //bad if(name === 'js' && obj.someProperty.title === "sparta" && height < 180) {...} //good const isJsTutor = name === 'js' && obj.s..

코드 컨벤션 1. camelCase 거의 대부분의 변수 함수 선언에 사용됩니다. const thisIsVariable = true; const goToHome = () => { return; } 2. kebab-case 페이지, pathname, 폴더명, css className 에 사용됩니다. pages ㄴ todo-list ㄴTodoList.tsx ㄴ todo-detail ㄴTodoDetail.tsx class-name, .item-id 3. snake_case 소문자 표현은 잘쓰이지 않지만, 대문자 표현은 상수 표현 할때 많이 사용합니다. const default_snake_case = '파이썬에서 많이 쓰임 js는 잘 안씀' // 요건 js 에서 많이 씀 const MILLISECONDS_PER_..

아래 글을 보고 단번에 정확한 뜻을 알 수 있나요? 이처럼 이해하기 어려운 글은 사람들로 하여금 오해를 불러 일으킵니다. 과연 코드는 다를까요? 코드도 결국엔 글입니다. 이해하기 힘든 코드들은 내가 이 코드를 통해 뭘 하고 싶었는지 전혀 알 수 없게 합니다. 그렇기에 우리는 코드를 계속해서 읽기 쉬운 방향으로 변경하도록 노력하여야 합니다. 좀 더 유명한 사람의 표현을 볼까요? “I like my code to be elegant and efficient. The logic should be straightforward and make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete ..