개발/클린코드 (6) 썸네일형 리스트형 [클린코드 10장] 클래스 클래스 체계 변수 public static private static private 함수 공개 함수 비공개 함수 비공개 함수는 자신을 호출하는 공개함수 직후에 넣자. 캡슐화 캡슐화를 최우선시 하자. 테스트 코드에 꼭 필요하다면 함수나 변수를 protected로 선언하거나, 패키지 전체로 공개할 수도 있다. 클래스 생성시 고려할 사항 1. 클래스는 작아야 한다. 얼마나 작아야 하는가? 위 질문이 떠오른다면, 해법은 간단하다. 클래스가 맡은 책임을 세자. 책에서는 SuperDashboard 클래스를 예시로 들었다. 내가 생각한 예제는 주방 가전 제품이다. 만약 아래의 기능을 모두 가진 가전 제품이 있다면 어떨까 밥을 한다 빵을 굽는다. 달걀 후라이도 가능하다. 빙수를 만들 수 있다. 기능이 너무 많다 보니,.. 5. 형식 1. 고차 함수에서 저차 함수 순으로 나열. 2. 새로운 개념이 등장할 때 빈행 넣기 3. 변수 3.1 로컬 변수: 사용하는 위치에 최대한 가깝게 선언 3.2 인스턴스 변수: 클래스의 맨 처음에 선언 4. 유사한 개념끼리 모으기 예. assertTrue assertFalse 5. 가로형식 최대 120자를 넘지 말자. 6. 들여쓰기 지키기 쿼리를 짜거나, 함수를 작성할 때 들여쓰기 꼭 지키자. 7. 팀 내 규칙 생성 자바 코드 컨벤션 외에도 개발 팀별로 작성 규칙을 명시할 필요가 있다. 예. 네이밍 규칙, 괄호의 위치, 들여쓰기 등 -> 아름다운 코드는 한 사람이 작성한 것처럼 일관성이 있어야 한다. 4장. 주석 주석은 잘못된 정보를 전달할지도 모른다. 코드는 리팩토링, 기능 추가를 통해 끊임 없이 변한다. 주석이 설명하는 기능이 삭제/수정될 수도 있다. 기능 설명이 필요한 메소드는 클래스로 분리하여 쪼개자. 의미가 모호한 메소드/변수명은 길더라도 자세하게 바꾸자. /* 오늘 결석한 학생들을 구하는 함수는 아래와 같이 자세한 이름으로 개선할 수 있다 */ // bad students.get() // 오늘 결석한 학생들 // good students.getTodaysAbsentStudents 좋은 주석 1. 저작권 표시 -> 회사명, 라이센스 등 -> 반복된다면 하나의 별도 파일로 관리하는 것이 더 낫다. 2. 외부 라이브러리를 사용하는 과정에서 의도를 명확히 밝혀야할 경우 3. TODO 주석 -> 그렇다고 해서,.. [요약] 3. 함수 1. 함수는 작게 만들어라 1.1 작은 함수의 정의 오직 하나의 일만 하는 함수 1.2 어떻게 작게 만들까? A. 객체지향 생활체조 원칙 1번과 2번을 적용한다. 1) 한 메소드에 오직 한 개의 들여쓰기만 한다 2) else 키워드를 쓰지 않는다. B. 함수당 추상화 수준은 하나로 - 비슷한 추상화 수준의 함수끼리 한 함수내에서 사용한다. C. 내려가기 규칙: 위에서 아래로 코드 읽기 추상화 레벨이 다양할 경우, (1) 추상화단계가 높은 함수가 먼저 정의되고 (2) 페이지의 아래로 내려갈 수록 추상화 단계가 낮은 함수가 나온다. /* 추상화 3단계*/ String renderPage() { renderMenu(); // 추상화 3단계 내부에서는 2단계 함수만 사용한다. 1단계는 사용하지 않는다. rend.. [요약] 2.의미 있는 이름 1. 올바른 이름이란 변수명/클래스명/함수명은 아래의 질문에 답할 수 있어야 한다. - 변수(클래스,함수)의 존재 이유 - 수행 기능 - 사용 방법 역할이 제대로 명시된 이름과 그렇지 않은 이름을 비교해보자. /*bad*/ ind day; // 경과 시간 (단위, 날짜) /*good*/ int daySinceCreation; 위 코드의 bad는 주석이 있기 때문에 괜찮지 않냐고 물을 수도 있다. 하지만 day를 여러 곳에서 사용한다면 어떨까. 유지보수를 하는 나 같은 사람은 최초 작성자의 의도를 읽기 위해 매번 주석이 정의된 곳으로 스크롤을 왔다갔다할 것이다. 사실 내가 짠 과거의 코드도 저런 모습이 많다.. 반성하자 내 자신 2. 나쁜 이름과 좋은 이름의 예시 2.1 이름에 포함된 자료형 -> Bad .. [요약] 1장. 깨끗한 코드 1. 본문 요약 르블랑의 법칙 -나중에 리팩토링한다는 말은 새빨간 거짓말이다. 개발 기간에 깨끗한 코드를 만들어내자. 좋은 개발자(=시니어개발자)란 - 기획자, PM이 납득할 수 있도록 현재 시스템을 설명하고, 개발 초기에 꼼꼼하게 설계하는 사람. 관리자가 나쁜 코드의 위험을 인지하도록 설득할 것 깨끗한 코드란 - 한가지 일을 제대로 한다. 의존성을 낮추어야 함 - 단위테스트, 인수 테스트 존재 - 의미 있는 이름 - 중복을 제거한다. - (내 생각) 1) 테스트 케이스는 반드시 필요하다. 아무리 주석을 자세히 적어놔도, input값과 output을 명확히 제공하는 테스트 케이스를 읽는 것이 훨씬 효율적이다. 2) 의미 있는 이름을 짓자. frmPop() 이런 함수를 최근 유지보수중인 코드에서 봤다. f.. 이전 1 다음