인생 1회차 (First-Life) Ing

오늘 TIL 3줄 요약 클래스는 작을 수록 좋다 하나의 클래스는 하나의 책임만! 응집력 있는 클래스를 만들어라 책에서 기억하고 싶은 내용 변수목록 : 정적static 공개 public 상수 > 정적 비공개 private 변수 > 비공개 인스턴스 변수 변수목록 다음에는 공개함수가 나오고 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉 추상화 단계가 순차적으로 내려감 클래스를 설계할 때도, 함수와 마찬가지고 '작게'가 기본 규칙 클래스 이름은 해당 클래스 책임을 기술해야 한다. (실제로 작명은 클래스 크기를 줄이는 첫번째 관문) 클래스 이름이 모호하다면 클래스 책임이 너무 많아서다. [단일 책임 원칙 (SRP : Single Responsibility Principle) ] 단일 책임 원칙 : ..

오늘의 TIL 3줄 요약 * 테스트 코드는 실제 코드만큼이나 중요하다 * 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화한다 * 테스트코드의 표현력을 높이고 간결하게 정리하자 책에서 기억하고 싶은 내용 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다 3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다 * 테스트 코드는 실제 코드 못지 않게 중요하다. 실제 코드 못지않게 깨끗하게 짜야 한다. * 단위 테스트 코드는 유연성, 유지보수성, 재사용성을 제공한다. * 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. * 깨끗한 테스트 코드를 만들려면? 가독성을 위해 명..

오늘 TIL 3줄 요약 깨끗한 코드와 오류 처리는 확실히 연관성이 있다 오류코드보다는 예외를 사용하라 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다 책에서 기억하고 싶은 내용 깨끗한 코드와 오류 처리는 확실히 연관성이 있다. 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. (여기서 좌우된다는 표현은 코드 기반이 오류만 처리한다는 의미가 아니라 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 거의 불가능하다는 의미) 오류 코드보다 예외를 사용하라 Try-Catch-Finally문부터 작성하라 미확인unchecked예외를 사용하라 예외에 의미를 제공하라 (예외를 던질 때는 전후 상황을 충분히 덧붙인다) 호출자를 고려해 예외 ..

오늘 TIL 3줄 요약 객체는 동작을 공개하고 자료를 숨긴다. 자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는 것이 좋다. 객체지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적은 코드에서 어려운 변경은 객체지향 코드에서 쉽다. 책에서 기억하고 싶은 내용 변수를 비공개private로 정의하는 이유 : 남들이 변수에 의존하지 않게 만들고 싶어서 변수를 private으로 선언하더라도 각 값마다 조회get 함수와 설정set 함수를 제공한다면 구현을 외부로 노출하는 셈 구현을 감추려면 추상화가 필요하다! 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다 객체지향 코드에서 어려운 변경은 절차적인 코드..

오늘 TIL 3줄 요약 코드는 중요한 의사소통의 일환이다. 올바른 형식을 지키서 코드를 짜자(가로, 세로) 팀 규칙은 개인의 선호보다 우선! 책에서 기억하고 싶은 내용 코드 형식은 중요한 의사소통의 일환이다. 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 신문 기사처럼 작성하라 (이름은 간단하면서도 설명이 가능하게, 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경써서 짓기. 아래로 내려갈수록 의도를 세세하게 묘사) 개념은 빈 행으로 분리하라 세로 밀집도 (서로 밀접한 코드 행은 세로로 가까이 놓여야 함) 수직 거리 (같은 파일에 속할 정도로 밀접한 두 개념은 세로 거리로 연관성을 표현한다. 여기서 연관성이란 한 개념을 이해하는 데 다른 개염이 중요..

오늘 TIL 3줄 요약 주석은 필요악이다 주석 대신 코드로 의도를 표현하라 주석은 반드시 필요할 때만, 최소한으로 사용하라 책에서 기억하고 싶은 내용 주석은 '필요악' 이다. 우리에게 프로그래밍 언어를 치밀하게 사용해 의도를 표현할 능력이 있다면, 주석은 전혀 필요하지 않으리라. 하지만 그렇지 못해서 쓰는 것이 주석 (그만큼 주석은 안쓰는 것이 좋다.) 주석은 나쁜 코드를 보완하지 못한다. 나쁜 코드를 주석으로 설명하려 애쓰는 대신 코드를 수정하라. 코드로 의도를 표현하라 - 법적인 주석 -정보를 제공하는 주석 -의도를 설명하는 주석 -의미를 명료하게 밝히는 주석 -결과를 경고하는 주석 -TODO주석 -중요성을 강조하는 주석 -주절거리는 주석 -같은 이야기를 하는 주석 -오해할 여지가 있는 주석 -의무적..

오늘 TIL 3줄 요약 '한 가지'만 하는 함수를 만들어라 중복을 줄여라 잘 읽히는 이야기처럼 코드를 풀어가라 책에서 기억하고 싶은 내용 작게 만들어라 - 가로 100자, 100줄 이상 금지. 20줄도 김 블록과 들여쓰기 - if/else문, while문 등에 들어가는 블록은 한 줄이어야 한다는 의미 = 중첩구조가 생길만큼 함수가 커져서는 안됨 한 가지만 해라 - 한 가지 기능만 하되, 그 기능이 잘 동작해야 함 함수가 '한 가지' 기능만 수행하는지 확인하는 방법? 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈. 함수 당 추상화 수준은 하나로!..

오늘 TIL 요약 문장이나 문단처럼 읽히는 코드 아니면 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데 집중하자 책에서 기억하고 싶은 내용 의도를 분명히 밝혀라 -변수(혹은 함수나 클래스)의 존재 이유, 수행 기능, 사용 방법 그외 주석이 필요하다면 의도를 분명히 드러내지 못한 것 => 문제는 코드의 단축성이 아니라 함축성 그릇된 정보를 피하라 - 일관성이 떨어지는 정보는 그릇된 정보 의미 있게 구분하라 발음하기 쉬운 이름을 사용하라 검색하기 쉬운 이름을 사용하라 (ex. 7, e 조심) 인코딩을 피하라 자신의 기억력을 자랑하지 마라 (루프에서 반복 횟수를 세는 변수를 쓸 때 'l'은 절대 안됨!) 기발한 이름은 피하라 한 개념에 한 단어를 사용하라 말장난을 하지 마라 해법 영역, 문제 영역에서 가져온..

오늘 TIL 3줄 요약 중복을 피하라 한 기능만 수행하라 제대로 표현하고, 작게 추상화 하라 책에서 기억하고 싶은 내용 "사소한 곳에서 발휘하는 정직은 사소하지 않다" "책임 있는 전문가라면 프로젝트를 시작할 때 생각하고 계획할 시간을 확보해야 한다" 기계가 실행할 정도로 상세하게 요구사항을 명시하는 직업, 바로 이것이 프로그래밍. 이렇게 명시한 결과가 바로 코드다. 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. 나쁜 코드는? 개발 속도를 떨어뜨린다. 팀 생산성이 떨어진다. 좋은 코드를 사수하는 일은 우리 프로그래머들의 책임이다. 깨끗한 코드는? '보기에 즐거운' 코드, 한가지에 집중한 코드 - 비야네 스트롭 스트룹 잘 쓴 문장처럼 읽히는 코드 - 그래디 부치 '다른' 사람이 고치기 쉬..