본문 바로가기

CS/CS Book

 (32)
[Clean Code | 10장 클래스 ] Day15,16 기억하고 싶은 부분 클래스는 적어야 한다 단일 책임 원칙 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다 변경할 이유가 하나여야 한다 클래스는 인스턴스 변수 수가 작아야 한다 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 높다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다 소감 객체에 대해 이야기할때 응집도와 결합도에 대한 말이 나온다 응집도는 높아야 하고 결합도는 낮아야 한다고 하는데 둘이 비슷하게 느껴져서 둘의 차이점이 무엇인가 생각 들곤 했었다. 책에서 응집도에 대해서 메서드에서 인스턴스 변수를 쓸수록 응집도가 높다는 설명에서 좀 더 감을 잡을 수 있었다. 필요한 건 있어야 하니까 필요한 건 멤버변수라 보면 메서드 입장에서 변수를 파라미터나 전역변..
[Clean Code | 9장 단위 테스트 ] Day14 기억하고 싶은 부분 TDD 세 가지 법칙 실패하는 단위테스트 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기로 한다. 깨끗한 코드 유지하기 개념당 assert 문 수를 최소로 줄여라 테스트 함수 하나는 개념 하나만 테스트하라 소감 깨끗한 코드 유지하기 부분이 납득되었다. 빠른 테스트를 위해 알아보기 어려운 상태의 테스트 코드를 작성하는 것은 나중에 바뀔 실제코드에 맞게 테스트 코드도 변경되어야 하므로 테스트 코드 변경을 어렵게 만들기에 그렇다 도서관 프로젝트에서 배포 전에 만든 단위 테스트가 얼..
[Clean Code | 7장 오류처리 ] Day10~12 기억하고 싶은 부분 뭔가 잘못될 가능성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다. 어떤 면에서 try 블록은 트랜잭션과 비슷하다. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. null을 반환하는 습관 흔히 저지르는 바람에 오류를 유발하는 행위를 설명하면서 첫 번째 예시로 들음 null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 누구하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다. null 확인이 너무 많아 문제. 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다. 특수 사례 패턴 (SPECIAL CASE P..
[Clean Code | 6장 객체와 자료구조] Day09 기억하고 싶은 부분 “변수를 비공개로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다.” private처리하는 목적으로 가져다 쓰는 입장에서는 내부가 어떻게 되어있든 혹은 특정 값에는 접근하지 못하게 하고 싶어서라고만 생각했었다. 같은 것을 의미하는 것일수도 있지만 조금은 다른 관점에서 private를 바라보았다는 생각이 든다. “변수를 private으로 선언하더라도 각 값마다 get함수와 set함수를 제공한다면 구현을 외부로 노출하는 셈이다” “인터페이스와 get/set 함수만으로는 추상화가 이뤄지지 않는다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각 없이 get/set 함수를 추가하는 방법이 가장 나쁘다.” private로 선언한 ..
[Clean Code | 5장 형식 맞추기 ] Day08 기억하고 싶은 부분 코드가 어수선해 보인다면 독자들은 프로젝트의 다른 측면도 똑같이 무성의한 태도로 처리했으리라 생각할 것이다 신문 기사처럼 작성하라 개념은 빈 행으로 분리하라 서로 밀접한 개념은 세로로 가까이 둬야 한다 지역변수는 각 함수 맨 처음에 선언해야 한다 소감 형식이라 하면 고리 타분하다 생각들 수도 있는데 사례들을 보여주어서 확 와닿았다. 가끔 알고리즘 문제 다른 이의 풀이를 보면 줄 수를 줄이기 위한 컨셉이지만 재미로 한 줄에 다 적는 경우도 있다. 그렇게 되면 그 글은 대강 보다가 말게 되는데 그런 점에서 들여 쓰기 없이 한 예시가 책에서 나오고 들여쓰기 있을 때와 비교되어서 확실하게 와닿았다 한 줄을 80자로 억제하는 규칙의 이름을 알 수 있어 나름 나에게는 유익하였고 저자는 120자를..
[Clean Code] Day07 Practice mission1.js // BAD 더러운 코드 😣 // Hint❕ : 검색하기 쉬운 이름을 사용하세요. // blastOFF는 로켓 발사를 의미. 86400000은 하루의 밀리초 (milliseconds) 의미. // What the heck is 86400000 for? // setTimeout(blastOff, 86400000); // GOOD 😎 // 위 코드를 깨끗하게 다시 작성해 주세요. const dayTimeMilliseconds = 24 * 60 * 60 * 1000; milliseconds setTimeout(blastOff, dayTimeMilliseconds); // 어떻게 고쳤는지, 사례에서 무엇을 배워야 하는지 설명해주세요. /** * const dayTimeMilliseconds..
[Clean Code | 4장 주석] Day05, 06 기억에 남는 내용 코드는 결국 바뀐다. 하지만 주석은 코드가 바뀌는 속도만큼 변화를 빠르게 반영하지 못한다 그런점에서 주석을 가급적 안쓰는 것을 권장하는 모습이 인상 깊다 이전에 "프로그래머의 뇌" 스터디를 하며 다른 분과 주석에 관해 생각을 나누었을 때 그분도 주석을 가급적 안쓰는 것을 선호하셨었다 나의 경우 주석이 있는 편이 설명이 되어서 좋지 않나라는 생각과 주석이 없어도 될만큼의 깔끔한 코드를 모든 코드에서 만들어내기는 힘들었고 협업을 같이하게 될때 팀원이 그렇다고 한다면 그에 맞추기 위해 클린코드를 지향하느라 부담이 느껴지고 서비스보다 깔끔한 코드에만 신경쓰게 될거 같아서 당시에는 약간은 거부감이 들었었다. 이 파트를 읽고보니 주석을 지양하는 태도를 가지신 분들의 생각도 이해가 되었다
[Clean Code | 3장 함수] Day03, 04 ch03 함수 기억하고 싶은 부분 함수가 작을수록 더 좋다 좋다면서 5줄로 줄이는 것을 권장하는게 인상 깊다 중첩 구조가 생길만큼 함수가 커져서는 안 된다. 함수 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 우테코 코딩 룰이 함수당 15줄, 들여쓰기는 1단이라고 몇년 전에 들었었는데 그 방식이 떠올랐다. 함수는 한가지를 해야한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 함수를 만드는 이유는 큰 개념을(함수 이름을) 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서가 아니던가 “코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다” 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다. 그런 다음, 여러 단어를 사용해 함수 기..
[Clean Code | 2장 의미있는 이름] Day02 기억하고 싶은 부분 " 변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다 " "변수(혹은 함수, 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다" Before int d; // 경과 시간(단위: 날짜) After int elapsedTimeInDays; int daysSinceCreation; int daysSinceModeification; int fileAgeInDays; "발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다." "전문가 프로그래머는 자신의 능력을 좋은 방향으로 상요해 남들이 이해하는 코드를 내놓는다" "의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책..
[Clean Code] Day 00 2~3년 전쯤 사놓고 먼지만 자연스럽게 쌓아두던 클린코드를 노마드코더에서 챌린지가 있는 김에 읽어보려한다. 마침내! 첫날은 구비한 책 인증이라 이렇게 글을 소박하게 남겨보게 되었다 사진의 흔들림이 현장감이 느껴져서 뭔가 뭔가 리얼하다

티스토리툴바