잘못알고 있는 말들이나 지식들을 정리(?)

주석

부적절한 정보

• 다른 시스템(소스 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템 등)에 저장할 정보는 주석으로 적절하지 못하다.
• 예를 들어
  • 변경 이력은 장황한 날짜와 따분한 내용으로 소스코드를 번잡하게 만든다.

쓸모 없는 주석

오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 필요가 없다.
주석은 빨리 낡는다. 금방 필요없어질 주석은 달지 않는 편이 좋다.

중복된 주석

코드만으로도 충분한데 구구절절 설명하는 주석
i++; // i 증가

성의없는 주석

필요한 주석은 잘 작성되어야 한다.
주석에도 시간을 들여 멋지게 작성해야 한다.
단어를 신중하게 선택한다. 당연한 소리를 반복하지 않고 간결하고 명료하게 작성한다.

주석처리된 코드

코드를 읽다가 주석처리된 코드가 나오면 불편하다.
중요한 코드인지, 필요없는 코드인지 알 길이 없다.
하지만 아무도 삭제할 수 없다. 누군가에게는 필요한 코드일수도 있으니
따라서 해당 코드는 매일매일 낡아간다.
시간이 지나면서 주석처리된 코드 내에 사용된 변수/함수 등의 이름은 바뀌지만 주석코드를 수정하지는 않는다.
주석처리된 코드는 지워라. 필요한 사람이 이전버전을 확인할테니

환경

여러 단계로 빌드해야 한다

빌드는 간단히 한 단계로 끝나야 한다.

여러 단계로 테스트해야 한다

모든 단위 테스트는 한 명령으로 돌려야한다.
IDE에서 버튼 하나로 모든 테스트를 돌린다면 가장 이상적이다.

함수

너무 많은 인수

함수에서 파라미터의 개수는 적을수록 좋다.

출력 인수

Swift에서는 Stored Property를 사용하는 것이 좋을 듯

플래그 인수

Boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거이다.

죽은 함수

아무도 호출하지 않는 함수는 삭제한다.
주석처리된 코드랑 같은 느낌

일반

한 소스 파일에 여러 언어를 사용한다

오늘날 프로그래밍 환경은 한 소스 파일에서 다양한 언어를 지원한다.
자바 소스 파일 내에 HTML, JS 등을 포함한다.
이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 좋다.

당연한 동작을 구현하지 않는다

함수나 클래스는 '이름'과 연관된 혹은 당연하게 여길만한 동작을 해야 한다.

경계를 올바로 처리하지 않는다

코드는 올바로 동작해야 한다.
하지만 우리는 올바른 동작이 아주 복잡하다라는 말을 간과한다.
부지런함을 대신할 지름길은 없다.
모든 경계 조건, 구석진 곳, 예외는 우아하고 직관적인 알고리즘을 좌초시킬 암초다.
모든 조건들을 커버할 수 있는(커버리지 넓은) TC를 작성해서 테스트하라.

안전 절차 무시

예전 '체르노빌 원전 사고'는 책임자가 안전 절차를 무시하는 바람에 일어났다.
귀찮고 번거롭다는 이유로...

중복

이 책에서 나오는 가장 중요한 규칙 중 하나
DRY 법칙

• Don't Repeat Yourself
  책에서 이 규칙은 "모든 테스트를 통과한다"는 규칙 다음으로 중요하다고 꼽았다.

코드에서 중복을 발견할 때마다 추상화할 기회로 간주하다.
중복된 코드를 하위 클래스로 분할하라.
이렇듯 추상화로 중복을 처리하면 설계 언어의 어휘가 늘어난다.

1. 가장 뻔한 유형으로는 똑같은 코드가 여러 차례 나오는 중복이다.
   Ctrl + C/V 처럼 보이는 코드이다.
2. 여러 모듈에서 일련의 switch/case, if/else 문으로 똑같은 조건을 거듭 확인하는 중복이다.
   이런 중복은 다형성으로 대체해야 한다.
3. 알고리즘이 유사하나 코드가 서로 다른 중복이다.
   중복은 중복이므로 템플릿 메소드 패턴이나 전략 패턴으로 제거한다.

최근에 나온 디자인 패턴의 대다수는 중복을 제거하기 위한 방법이다

추상화 수준이 올바르지 못하다

추상화는 저차원 상세 개념에서 고차원 일반 개념을 분리한다.
추상화로 개념을 분리할 때는 철저해야 한다.
예를 들어, 세부 구현과 관련한 상수, 변수, 유틸리티 함수는 기초 클래스에 넣으면 안된다.
기초 클래스는 구현 정보에 무지(알고 있지 않는 것이)해야 마땅하다.

EX
public interface Stack{
Object pop() throws EmptyException;
void push(Object o) throws FullException;
double percentFull();
class EmptyException extends Exception{}
class FullException extends Exception{}
}

percentFull() 은 추상화 수준이 올바르지 못하다
Stack을 구현하는 방법은 다양하다.

기초 클래스가 파생 클래스에 의존한다.

개념을 기초 클래스와 파생 클래스로 나누는 이유는 독립성을 보장하기 위해서다.
일반적으로 기초 클래스는 파생 클래스를 몰라야 마땅하다.

과도한 정보

잘 정의된 모듈은 인터페이스가 아주 작다. 하지만 작은 인터페이스로도 많은 동작이 가능하다.
잘 정의된 인터페이스는 많은 함수를 제공하지 않는다. -> 결합도가 낮다.
부실하게 정의된 인터페이스는 많은 함수를 제공한다. -> 결합도가 높다.

클래스는 제공하는 메서드가 작을수록 좋다.
함수는 알고 있는 변수 수도 작을수록 좋다.

자료, 유틸리티 함수, 상수, 임시 변수를 숨겨라

죽은 코드

죽은 코드란 실행되지 않는 코드이다.
불가능한 조건을 확인하는 if / throw 문이 없는 try 문에서 catch 블록
해당 코드는 제거하라

수직 분리

변수와 함수는 사용되는 위치에 가깝게 정의한다.
지역 변수는 처음으로 사용하기 직전에 선언하며 수직으로 가까운 곳에 위치해야 한다.
선언한 위치로부터 몇백줄 아래에서 사용되면 안된다.

일관성 부족

어떤 개념을 특정 방식으로 구현했다면 유사한 개념도 같은 방식으로 구현하라.
착실하게 적용한다면 간단한 일괄성만으로도 코드를 읽고 수정하기 쉬워진다.

잡동사니

비어 있는 기본 생성자가 왜 필요한가?
아무도 사용하지 않는 변수, 호출되지 않는 함수, 정보를 제공하지 않는 주석 등
제거하라

인위적 결합

서로 무관한 개념을 인위적으로 결합하지 않는다.
일반적으로 enum은 특정 클래스에 속할 이유가 없다.
enum이 클래스에 속한다면 enum을 사용하는 코드가 특정 클래스를 알아야만 한다.
범용 static 함수도 마찬가지이다.
편한 곳에 두지 않고, 필요한 곳에 시간을 들여 놓아라

기능 욕심

'마틴 파울러'가 말하는 코드 냄새 중 하나이다.
클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야지 다른 클래스의 변수와 함수에 관심을 가져서는 안된다.
메서드가 다른 객체의 참조자와 변경자를 사용해 그 객체 내용을 조작한다면 메서드가 그 객체 클래스의 범위를 욕심내는 것이다.

EX
public class HourlyPayCalculator{
public Money calculateWeeklyPay(HourlyEmployee e){
int tenthRate = e.getTenthRate().getPennies();
int tenthsWorked = e.getTenthsWorked();

    ...

    return new Money(straightPay + overtimePay);
}

}

calculateWeeklyPay 메서드는 HourlyEmployee 객체에서 온갖 정보를 가져 온다.
즉, calculateWeeklyPay 메서드는 자신의 클래스인 HourlyPayCalculator 범위를 넘어 선다.

EX
public class HourlyPayCalculator{
private HourlyEmployee employee;

//생성자(){
    this.employee = e;
}

String reportHoues(){
    return String.format("Name : %s.....", employee.getName(), employee.getTenthWorked()/10...)
}

}

해당 reportHours() 역시 HourlyEmployee 클래스를 욕심낸다. 하지만 HourlyEmployee 클래스가 리포트 형식을 알 필요는 없다.
함수를 HourlyEmployee 클래스로 옮기면 OOP의 여러 원칙을 위반한다.
따라서 이와 같은 예외 케이스에는 다른 클래스를 욕심내는 상황이 있을 수 있다.

선택자 인수

함수 호출 끝에 달리는 false 인수만큼이나 밉살 스런 코드도 없다.
예) 초과 근무 수당은 1.5배로 계산해야 하는 메소드 내에서
public int calculateWeeklyPay(boolean overtime){
...
double overtimeRate = overtime ? 1.5 : 1.0 * tenthRate;
...
}
-> straightPay(), overTImePay(), overTimeBonus() ... 로 쪼개는 것이 낫다.
enum, int, boolean 등의 인수로 함수의 동작을 제어하는 것은 바람직하지 않다.

모호한 의도

코드를 짤 때는 의도를 분명히 밝힌다.

잘못 지운 책임

개발자가 내리는 가장 중요한 결정 중 하나가 코드를 배치하는 위치다.
예) PI 상수는 어디에 들어갈까? -> 삼각함수를 선언한 클래스에 넣어야 한다.

부적절한 static 함수

Math.max(a, b)는 좋은 static 메서드다.
특정 인스턴스와 관련된 기능이 아니다.
new Math().max(a, b)나 a.max(b) 같은 형태가 오히려 더 우습다.

EX
HourlyPayCalculator.calculatePay(employee, overtimeRate);

언뜻 보면 static 함수로 여겨도 적당하다. 특정 객체와 관련이 없으면서 모든 정보를 인수에서 가져오니까
하지만 함수를 재정의할 가능성이 존재한다.
수당을 계산하는 알고리즘이 여러 개일지도 모른다.

OverTimeHourlyPayCalculator 와 StraightTimeHourlyPayCalculator 로 분리하고 싶을지도 모른다.
따라서 해당 메서드는 static이 아닌 인스턴스 메서드가 적절하다.

서술적 변수

프로그램 가독성을 높이는 가장 효과적인 방법 중 하나가 계산을 여러 단계로 나누고 중간 값으로 서술적인 변수 이름을 사용하는 방법이다.

이름과 기능이 일치하는 함수

Date newDate = date.add(5);
해당 코드는 5일, 5시간, 5주 등 어떻게 변경하는 함수인지 알 수가 없다.
또한, 있던 date객체를 변경하는 것인지 새로운 Date객체를 반환하는 것인지 알 수가 없다.

5일을 더하여 변경하는 함수라면 addDaysTo()
5일을 더하여 새 Date 객체를 반환하는 함수라면 daysLater() 가 적당하다.

알고리즘을 이해하라

대다수 괴상한 코드는 사람들이 알고리즘을 충분히 이해하지 않은 채 코드를 구현한 탓이다.
잠시 멈추고 실제 알고리즘을 고민하는 대신, 여기저기 if문과 print를 사용하여 코드를 돌리는 탓이다.
알고리즘을 다 안다고 하지만 실제는 코드가 '돌아갈' 때까지 이리저리 찔러본다.

논리적 의존성을 물리적으로 드러내라

한 모듈이 다른 모듈에 의존한다면 물리적인 의존성도 있어야 한다. 논리적 의존성만으로는 부족하다.

If/Else, Switch/Case 보다는 다형성을 사용하라

3장에서 새 유형을 추가할 확률보다 새 함수를 추가할 확률이 높은 코드에서는 switch가 적합하다 주장했다.

1. 대다수 개발자가 switch 문을 사용하는 이유는 그 상황에서 가장 올바른 선택이기보다는 쉬운 선택이기 때문
2. 유형보다 함수가 더 쉽게 변하는 경우는 극히 드물다.

표준 표기법을 따르라

팀은 구현 표준을 따라야 한다.
인스턴스 변수 이름을 선언하는 위치, 클래스/메서드/변수 이름 명명 방법 등을 명시해야 한다.

매직 숫자는 명명된 상수로 교체하라

SECONDS_PER_DAY 는 86,400이다.
하지만 TWO, WORK_HOURS_PER_DAY 같은 상수가 필요할 까?
확실히 TWO는 필요가 없다. 현재 법정 근무 시간이 8시간 이지만 바뀔수도 있으니 WORK_HOURS_PER_DAY는 필요할수도 있다.

정확하라

관례보다 구조를 사용하라

설계 결정을 강제할 때는 규칙보다 관례를 사용한다.
예를 들어, enum 변수가 멋진 ㄴwitch/case 문보다 추상 메서드가 있는 기초 클래스가 더 좋다.

조건을 캡슐화하라

부울 논리는 이해하기 어렵다.
조건의 의도를 분명히 밝히는 함수로 표현하라
if(shouldVeDeleted(timer)) 라는 코드는 아래의 코드보다 좋다
if(timer.hasEcpired() && !timer.isRecurrent())

부정 조건을 피하라

부정 조건은 긍정 조겅보다 이해하기 어렵다.
if(buffer.shouldCompact()) 가 아래 코드보다 좋다.
if(!buffer.shouldNotCompact())

함수는 한 가지만 해야 한다.

함수를 짜다보면 한 함수 안에 여러 단락을 이어, 일련의 작업을 수행하고픈 유혹에 빠진다.

EX
public void pay(){
for (Employee e : employees){
if(e.isPayday()){
Money pay = e.calculatePay();
e.deliverPay(pay);
}
}
}

위의 함수는 3가지 임루를 수행한다.

1. 직원 목록을 루프로 돌며
2. 각 직원의 월급일을 확인
3. 해당 직원에게 월급을 지급

public void pay(){
for(Employee e: employees){
payIfNecessary(e);
}
}

private void payIfNecessary(Employee e){
if (e.isPayday()){
calculateAndDeliverPay(e);
}
}

private void calculateAndDeliverPay(Employee e){
Money pay = e.calculatePay();
e.deliverPay(pay);
}

숨겨진 시각적인 결합

때로는 시간적인 결합이 필요하다. 시간적인 결합을 숨기면 안된다.
public void dive(String reason){
saturateGradient();
reticulateSplines();
diveForMoog(reason);
}

보다는

public void dive(String reason){
Gradient gradient = saturateGradient();
List< Spline > splines = reticulateSplines(gradient);
diveForMoog(splines, reason);
}
가 더 좋다.
함수가 복잡해지기 하지만 시간적인 결합을 명백히 드러내어 수정을 방지하는 역할을 한다.

일관성을 유지하라

코드 구조를 잡을 때는 이유를 고민하라.
그 이유를 코드 구조로 명백히 표현하라.
구조에 일관성이 없어 보인다면, 다른 사람들이 맘대로 바꿔도 된다고 생각한다.

경계 조건을 캡슐화하라

경계 조건은 빼먹거나 놓치기 십상이다. 경계 조건은 한 곳에서 별도로 처리한다.
코드 여기저기에서 처리하지 않는다.
if(level + 1 < tags.length){
parts = new Parse(level + 1);
}
보다는
int nextLevel = level + 1;
을 사용해야 한다.

함수는 추상화 수준을 한 단계만 내려가야 한다

함수 내 모든 문장을 추상화 수준이 동일해야 한다.
그 추상화 수준은 함수 이름이 의미하는 작업보다 한 단계만 낮아야 한다.

설정 정보는 최상위 단계에 둬라

추상화 최상위 단계에 둬야 할 기본값 상수나 설정 관련 상수를 저차원 함수에 숨겨서는 안된다.
대신 고차원 함수에서 저차원 함수를 호출할 때, 인수로 넘긴다.

추이적 탐색을 피하라

일반적으로 한 모듈은 주변 모듈을 모를수록 좋다.
A가 B를 사용하고 B가 C를 사용한다 하더라도 A가 C를 알 필요는 없다.
이를 디미터의 법칙이라 부른다.
내가 아는 모듈이 연이어 자신이 아는 모듈을 따라가며 시스템 전체를 휘저을 필요가 없다는 의미이다.
여러 모듈에서 a.getB().getC() 라는 형태를 사용한다면 설계와 아키텍처를 바꿔 B와 C사이에 Q를 넣기가 어렵다.

의미 있는 이름

우리는 변수, 함수, 패키지, 소스파일, 디렉토리 등 많은 곳에 이름을 붙인다.

의도를 분명히 밝혀라

좋은 이름을 지으려면 시간이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많다!

변수, 함수, 타입의 이름은 이 질문들에 모두 답해야 한다.

1. 존재 이유는?
2. 수행 기능은?
3. 사용 방법은?
   주석이 필요하다면 의도를 분명히 드러내지 못한 것이다.

int d; // 경과 시간(단위 : 날짜)

이름 d는 아무 의미도 드러나지 않는다.
측정하려는 값과 단위를 표현하는 이름이 필요하다.

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

그릇된 정보를 피하라

그릇된 단서는 코드의 의미를 흐린다.
나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다.

ex) 여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면 accountList라고 명명하지 않는다.
accountGroup, Accounts 가 적당하다.

의미있게 구분하라

발음하기 쉬운 이름을 사용하라

genymdhms (generate date, year, month, day, hour, minute, second)
를 읽을 때는 "젠 와이 엠 디 에이치 엠 에스"라 읽었다고 한다. 혹은 "젠 샤 무다 힘즈"(ㅋㅋㅋㅋ)

만약 generationTimestamp 로 변경한다면 대화가 훨씬 편해질 것이다.

검색하기 쉬운 이름을 사용하라

문자 하나를 사용한다면 검색을 하기 힘들 것이다.
상수에도 상수명을 주는 것이 검색하기에 훨씬 편하다.

인코딩을 피하라

• 헝가리식 표기법
• 멤버 변수 접두어
• 인터페이스 클래스와 구현 클래스
  • 인터페이스 클래스에는 이전에는 IShapeFactory 와 같이 접두어로 I를 붙였다.
  • 요즘은 인터페이스 클래스의 이름은 ShapeFactory를 사용하고 구현 클래스의 이름을 ShapeFactoryImpl 로 사용한다.

깨끗한 코드

프로그래머 수만큼이나 깨끗한 코드에 대한 정의 또한 다양할 것이다.

나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다.
의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다.
성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.
깨끗한 코드는 한 가지를 제대로 한다.
비야네 스트롭스트룹 - C++ 창시자

효율 : 속도만을 뜻하지 않는다. CPU 자원을 낭비하는 코드도 우아하지 못하다.
나쁜 코드는 나쁜 코드를 유혹한다.

깨끗한 코드는 메모리 누수, Race Condition, 일관성 없는 명명법, 오류 처리 등 세세한 사항까지 꼼꼼하게 처리하는 코드다.

깨끗한 코드는 작성자가 아닌 다른 사람도 고치기 쉽다.

깨끗한 코드는 주의 깊게 작성한 코드다. 이미 작성자가 모든 사항을 고려했으므로, 고칠 궁리를 하다보면 다시 제자리로 돌아오게 된다.

지저분한 코드를 손 볼때, 중복과 표현력만 신경써도 깨끗한 코드에 더 가까워진다.

새로운 코드를 작성하기 위해서 기존 코드를 보게 된다.
지금 바꾸려는 함수 후에 어떤 함수가 호출되는지?, 전에는 어떻게 동작하는지?, 하위 클래스에 해당 함수가 오버라이딩되었는지? 등등
코드를 짜기 위해 기존 코드를 읽는 시간이 훨씬 길다.
따라서 읽기 쉬운 코드가 매우 중요하다.

깨끗한 코드

코드를 최대한 다양한 각도에서 살펴본다.
그렇게 연습한 것들을 토대로, 좋은 코드와 나쁜 코드를 구분할 수 있으며, 좋은 코드를 작성 또는 나쁜 코드를 좋은 코드로 바꾸는 실력도 생길 것이다.

코드는 존재한다

해당 책은 코드를 다룬다.
누군가는 코드보다 모델/요구사항에 집중해야한다고 생각할 것이다.
하지만 코드는 요구사항을 상세히 표현하는 수단이다.

언젠가 코드를 사동으로 생성하는 시대가 온다고 한다.
하지만 위에서 말했듯, 요구사항을 코드가 표현한다.

나쁜 코드

80년 대에 Killer App이 개발되었다. 많은 사용자들이 해당 앱을 사용했고, 인기도 많았다.
하지만 언젠가부터 버전 릴리즈가 늦춰지고, 버그가 남아있고, 죽는 횟수가 증가했다.
이러한 불편한 UX로 인해 사용자들은 떠났고, 회사는 망했다.
그 이유는 출시에 바빠 코드를 마구 짯다. 기능을 추가할수록 코드는 엉망이 되어버렸다.

(대학생 시절, 처음으로 앱을 개발했을 때가 생각이 난다. 처음 사용해보는 Unity엔진과 C#언어는 물론 어려웠다. 또한, 프로젝트를 최대한 빨리 런칭하고 싶었기에 별다른 공부는 안했다. '하다보면 차차 알게되겠지..' 라는 생각이었다. 물론 진행을 하면서 습득했던 것들은 있었다. 하지만 그렇게 습득한 것들이 나쁜 것이었고, 나쁜 코드를 작성하는 방법이었다. 그렇게 런칭된 게임은 그 후로는 다시는 쳐다보지 못하는 코드를 갖게 되었다.)

왜 나쁜코드를 작성하게 되는가?
급해서, 서둘러서, 코드를 다듬느라 시간을 보내면 팀의 일정에 누가 될까봐, 상사한테 한소리를 들을까봐, 지겨워서 등 정말 많은 이유로 인해 나쁜 코드를 그대로 배포하는 상황이 많다.
또한, 내가 짠 쓰레기 코드를 보며 나중에 꼭 손보겠다고 생각한 경험이 있다. 당시에는 "그래도 돌아가는 게, 안돌아가는 것보다는 훨씬 낫지"라며 말이다. 그 당시에는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

코드가 엉망이라 프로젝트 진도가 안나가는 경험도 있을 것이다.
"나쁜 코드는 개발 속도를 크게 떨어뜨린다."
코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 얽히고설킨 코드를 '해독'해서 새로운 얽히고설킨 코드를 더한다.
시간이 지나면서 그 부피는 점점 더 커져갈 것이고, 청소할 방법은 없어진다.

• 나쁜 코드가 쌓일수록 팀의 생산성을 떨어진다. 그러다 0에 수렴하기 때문에 관리층은 복구를 시도한다.
  • 생산성 증가를 위해 새로운 인력을 투입!
    • But, 새 인력들은 시스템 설계에 대한 조예가 깊지 않다. 결국 팀과 새로운 인력은 압력에 시달리고 결국은 나쁜 코드를 더 양산한다.