DesignPattern

마음가짐

훌륭한 프로그래머는 게을러야 한다.

문서화, 그림을 그려라

리팩토링을 해라

개발자

깨끗한 코드는 가독성이 좋고 구조적으로 이해하기 쉬운 코드이다.

깨끗한 코드의 원칙

1. 다른 개발자에게 API를 제공한다는 마음가짐으로

2. 남이 봐도 쉬운 코드를 짜라

3. 자신의 코드만 보지 마라

4. 통일성 있는 코드 작성

5. 커뮤니케이션 하라

6. 리팩토링하라.

죽은 문서를 만들지 말라.

1. 어떤 개발자가 문서를 만드는 부서에 가고 싶겠는가?

   　-> 하지만 정말 필요하다.

   -> 그림이 들어간 논리적인 설명이 필요하다.

2. 좋은 문서를 작성하기 위해서는 구조적인 좋은 소스가 필요하다.

3. 나중에 시간나면 고쳐야지 – 절대 못 고친다.

   -> 항상 개발 할 때 모든 시간을 고려해서, 개발 + 문서화 + 리팩토링 3배의 시간을 잡아라

패턴은 그냥 이름만 붙여진 것일 뿐이다.

1. 어떠한 패턴이던 2가지 공통점을 기억하라

   • 공통점 묶기

   • 조금만 알기

2. 패턴 강박증에 걸리지 마라.

   • 굳이 모든 패턴을 다 익히고 외우며, 모든 곳에 패턴을 적용시키려 노력하지 않아도 된다.

3. 알면 좋지만, 얽매이지는 마라.

4. 요구사항은 끝이 없고, 변하지 않는 코드는 없다.

리팩토링 시 살펴볼 것

공통점 묶기, 조금만 알기, 함수 쪼개기를 현명하게 하는 게 굉장히 좋음

시간내서 하는 것이 아니라, 구현의 한 부분이다.

1. 클래스가 꼭 필요한 변수와 함수를 가지고 있는가?

2. 클래스 사이의 연관성은 크지 않는가?

3. 클래스가 너무 크지 않은가?

4. 코드가 이해하기 쉬운가?

5. 요구사항에 변화하는 코드와 변화하지 않는 코드는 무엇인가?

6. 하나의 함수는 하나의 일만 하는가?

개발팀

개발팀에는 조악한 테크닉 보다는 팀웍이 중요하다.

객체지향은 업무를 분배하거나 팀원들 모두가 절대 규칙으로 여길 때 진정한 가치를 가진다.

끊임없이 문제 상황에 적합한 구조를 찾고 리팩토링 함으로써 올바른 갈로 갈 수 있도록 노력하자.

요구사항을 어떻게 모든 개발자들에게 잘 분배하느냐?

1. 어떻게 문제를 분석할 것인가?

2. 어떻게 업무를 나눌 것인가?

3. 어떻게 업무를 전달하고 설명할 것인가?

4. 어떤 방법으로 개발자가 일하길 원하는가?

5. 어떻게 결과를 확인할 것인가?

6. 어떻게 통합할 것인가?

기본적인 패턴은 한번 씩 그래도 예제를 이용해 만들어 볼 것!