애자일(프랙티스) - 애자일 코딩

의도적이고, 의미 있게 프로그램 하라

호어 온 소프트웨어 디자인 - 소프트웨어 설계를 하는 두가지 방법이 있다. 하나는 명백하게 어떤 결함도 없도록 무척 간결하게

소프트웨어를 만드는 방법이고, 다른 방법은 매우 복잡하게 만들어서 결함을 명백히 찾아내지 못하게 만드는 것이다.

- 코드를 개발할 때, 항상 편리함보다는 읽기 쉬움을 선택해야 한다. 코드 작성 시 성능이 좋지 않더라도 읽기 쉽다면 더 가치 있는 코드다.

ex) 디폴트 인수나 선택적인 인수가 코드를 읽기 어렵고, 이해하기 힘들며, 버그를 더 많이 만든다면, 나중에 혼란을 일으키는 것보다 인수를 

명확하게 설정하는 편이 낫다.

- 코드를 이해하기 쉽게 만드는 한 가지 방법은 무슨일이 벌어지는지 알 수 있도록 코드를 명확하게 만드는 것이다,

------------------------★ PIE 원칙!!--------------------------------

작성하는 코드는 의도를 명확히 전달하고, 반드시 의미가 있어야 한다. 이렇게 하면,

읽기 쉽고 이해하기 쉬운 코드가 될 것이다. 코드가 혼란스럽지 않기 떄문에,

잠재적인 에러도 피할 것이다. 의도적이고, 의미 있게 프로그램 하라

----------------------------------------------------------------------

코드로 대화하기

- 잘 선택한 이름과 명료한 실행 경로가 있다면, 코드에서 주석은 거의 필요 없다. 

- 주석에 의존하지 말고 코드 스스로가 말하게 하는 것이 좋다.

응집도 높은 코드를 작성하라

- 낮은 응집도를 갖는 결과는 매우 심각하다. (사수가 나에게 왜 기능들을 한 클래스, 메서드에 구현시키 않고 나누라고 했는지 알꺼 같다)

- 커다란 클래스나 컴포넌트(SOLID에서 S 독립적인 클래스 즉 독립적인 기능을 하는 모듈을 의미한다) 혹은 다방면에서 잡다한 클래스를 만들고픈 유혹을 피하라

★★★ 묻지 말고, 말하라  ★★★

- 지금 작성하는 설명은 객체지향 패러다임, 절차지향 패러다임(함수등)에 종속되지 않고 어떤 애자일 코드도 이 방법을 따라야 한다.

호출자로서, 호출된 객체의 상태를 기초로 결정해서는 안 되며, 호출된 객체의 상태를 변경해서도 안 된다. 여러분이 구현하는 로직은 호출된

객체의 책임이지, 여러분의 책임은 아니다. 객체의 외부에서 여러분이 결정하는것은 객체의 캡슐화를 위반하고, 버그에게 비옥한 번식장을

제공한다.

- 인터페이스 계약을 존중하는 클래스를 교체해서 기능을 추가하거나 강화하자, 위임은 언제나 상속보다 바람직하다.