독서록

[Clean Code] 4장 주석

좋은 주석 법적인 주석 때로는 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시한다. 예를 들어, 각 소스 파일 첫머리에 주석으로 들어가는 저작권 정보와 소유권 정보는 필요하고도 타당하다. 의미를 명료하게 밝히는 주석 인수나 반환 값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 중요하다. TODO 주석 TODO 주석은 프로그래머가 필요하다 여기지만 당장 구현하기 어려운 업무를 기술한다. 더 이상 필요 없는 기능을 삭제하라는 알림, 누군가에게 문제를 봐달라는 요청, 더 좋은 이름을 떠올려달라는 부탁, 앞으로 발생할 이벤트에 맞춰 코드를 고치라는 주의 등에 유용하다.

[Clean Code] 3장 함수

작게 만들어라 함수를 만드는 첫 번째 규칙은 '작게'다. if 문 / else 문 / while 문 등에 들어가는 블록은 한 줄 이어야 한다. 대개 거기서 함수를 호출한다. 그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수 이름을 적절히 짓는다면 코드를 이해하기도 쉬워진다. 중첩 구조가 생길 만큼 함수가 커져서는 안 된다는 뜻이다. 한 가지만 해라 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다. 함수가 '한 가지'만 하는지 판단하는 방법은 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 서술적인 이름을 사용하라 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다..

[Clean Code] 2장 의미 있는 이름

이름을 잘 짓는 규칙 의도를 분명히 밝혀라 따로 주석이 필요 없을 정도로 사용 목적이 드러나야 한다. 그릇된 정보를 피하라 독단적인 축약를 피하고 서로 흡사한 이름을 사용하지 않는다. 의미 있게 구분하라 연속된 숫자를 붙이거나, 불용어를 덧붙이는 건 아무런 정보도 제공하지 않는다. 읽는 사람이 차이를 알도록 이름을 지어라 발음하기 쉬운 이름을 사용하라 검색하기 쉬운 이름을 사용하라 간단한 메서드에서는 로컬 변수를 한 문자로 사용해도 된다. 이름 길이는 범위에 비례해야 한다. 인코딩을 피하라 변수 이름에 타입을 인코딩할 필요 없다. 인터페이스는 접두어를 붙이지 않아도 된다. 자신의 기억력을 자랑하지 마라 명료함이 중요하다. 남이 이해하기 쉬운 코드를 내놓아야 한다. 클래스는 명사나 명사구를 사용하고 동사는..

[Clean Code] 1장 깨끗한 코드

깨끗한 코드는 "가독성"이 좋다. 단순하고 직접적이다. 작성자가 아닌 사람도 읽기 쉽고, 고치기 쉽다. 책에서 제시되는 코드 규칙 모든 테스트를 통과한다.(TDD) 중복이 없다. 시스템 내 모든 설계 아이디어를 포함한다. 클래스, 메서드, 함수 등은 최대한 줄인다. 깨끗한 코드를 만드는 비결 중복을 줄여라 한 기능만 수행하라 표현력을 높여라 (의미 있는 이름 짓기) 초반부터 간단한 추상화를 고려하라 메서드 추출 리팩토링 기법 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러 개 두기

[Clean Architecture] 3부 설계 원칙: SOLID

SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명해준다. SOLID 원칙의 목적은 변경에 유연한, 이해하기 쉬운, 많은 소프트웨어 시스템 컴포넌트의 기반이 되는 소프트웨어 아키텍처를 만들고자 함. 7장 SRP: 단일 책임 원칙 하나의 모듈은 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다는 원칙. 1. 원칙을 위반하는 징후 1: 우발적 중복 하나의 컴포넌트에 대한 변경 사항이 다른 컴포넌트에도 영향을 미치는 문제. SRP는 서로 다른 액터(변경을 요하는 집단)가 의존하는 코드를 각각 분리시키라고 말한다. 2. 원칙을 위반하는 징후 2: 병합 둘 이상의 사람이 서로 다른 목적으로 동일한 소스 파일을 변경하는 경우 병합(충돌)이 발생..

[Clean Architecture] 2부 벽돌부터 시작하기: 프로그래밍 패러다임

3장 패러다임 개요 1. 구조적 프로그래밍 최초로 적용된 패러다임. 구조적 프로그래밍은 제어 흐름의 직접적인 전환에 대해 규칙을 부과한다. 2. 객체 지향 프로그래밍 함수 포인터를 특정 규칙에 따라 사용하는 과정을 통해 필연적으로 다형성이 등장하게 되었다. 객체 지향 프로그래밍은 제어 흐름의 간접적인 전환에 대해 규칙을 부과한다. 3. 함수형 프로그래밍 람다 계산법의 기초가 되는 개념은 불변성(immutability)으로 심볼(symbol)의 값이 변경되지 않는다는 개념이다. 이는 함수형 언어에는 할당문이 전혀 없다는 뜻이기도 하다. 함수형 프로그래밍은 할당문에 대해 규칙을 부과한다. 각 패러다임은 일종의 추가적인 규칙을 부과한다. 즉, 패러다임은 무엇을 해야 할지를 말하기보다는 무엇을 해서는 안 되는지..

[Clean Architecture] 1부 소개

옮긴이의 글 소프트웨어 시스템이란 무엇인지를 우리는 제대로 이해하고 있을까? 소프트웨어 시스템을 통해서 우리가 얻고자 하는 것은 무엇일까? 잘 설계한 소프트웨어 아키텍처는 소프트웨어 시스템을 만들 때 왜 중요할까? 중요하다면 어떻게 해야 소프트웨어 아키텍처를 잘 만들 수 있을까? 1장 설계와 아키텍처란? 우선 설계와 아키텍처 사이에는 차이가 없다. 둘은 동일하다. 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지 보수하는 데 투입되는 인력을 최소화하는 데 있다. 고객의 요구를 만족시키는 데 드는 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계, 새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계이다. 개발자는 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다..