디자인 패턴 5주차 수업 정리

엔지니어링 : 지식이나 과학적 체계를 현실으로 만들어내는 것.

리버스엔지니어링 : 만들어진 것을 토대로 청사진이나 설계도면 및 원리를 만들어냄.

디자인 측면에서 공학 : 먼저 어떻게 만들지 구조를 설계하고 이 정해진 설계를 바탕으로 프로그래밍을 함

소프트웨어 공학에선 UML이란 국제표준이 존재.

어려운 구조의 소프트웨어를 짤 때 먼저 설계를 하고 코딩을 해야 함.

우리 코드의 문제? 올바르게 동작을 하는지 판정할 수 없다. 기준이 없기 때문.

내가 무엇을 해야하는지 먼저 문서화를 해야 함. 이를 통해 내가 무엇을 해야하는지 명확하게 할 수 있음.

소프트웨어 관리의 가장 중요한 점은 '버전을 픽스'해야 하는 것.

고로 우리는 어디까지 만들지를 문서화해야 하고 이에 대한 설계를 잘 해야 함.

-티켓

-버전 픽스

개발 스펙이 확정되지 않은 것은 개발하면 안됨.

반복되는 무한작업에 번아웃이 됨 -> 좀비처럼 부활하지 않는 버전으로 픽스를 해야 함!

커밋로그 메시지는 항상 버전 픽스로 남아야 함.

티켓방식으로 하면 클래스의 수정사항이 매번 중복되면서 업무가 많아짐.

하지만 버전 방식으로 관리를 하면 개발할 사항이 픽스되어 있기 때문에 개발작업이 늘어나지 않음.

설계도면을 그리고 코드를 짜라 -> 계획을 세우고 코드를 짜라

코드를 먼저 짠다면 사후 문서작업을 해줘야 함. 무엇이 제대로 구현됬는지 알기 위해서. (sebe api doc에서 하듯이)

가장 이상적인 것은 역공학과 순공학이 일치하는 것.

CMMI -> 역공학과 순공학이 서로 일치하는지 판정하는 국제 표준 모델.

UML 이해: 화살표의 방향만 보자

ㄱ -> ㄴ : ㄴ은 ㄱ를 모른다. 바라보고 있지않기 때문.

메소드의 인자를 잘 적어주자.

생성자 및 필수 메소드들은 위쪽에 위치시키는게 상속시킬 때 보기 좋음.

학습체계와 어휘체계를 잘 짜는 것이 프로그래머들이 해야할 일.

남들에게 협업하면서 내가 어떠한 근거로 이렇게 만들었다는 근거를 제시해야 함 -> UML 작성.

해야 되는 일이 어디까지 인지 꼭 정해야 하고 새로운 일이 들어오면 버전 픽스를 해야 함.

즉 abc 일을 하는데 d라는 일이 들어와서 abdc 이렇게 하지말고 'abc' 'd' 이런식으로 버전을 픽스해서 어디까지 할지 정해서

진행하라는 것.

이렇게 하면 일을 정해진 기간내에 끝낼 수 있을 것.

무엇을 만들지 정했다면

무엇을 할 것이라는 것을 말로 할 수 있어야 함.

티켓의 목표와 개발으로서의 목표는 다르다.

이쁘게 해주세요 <--> 서버와 클라이언트간의 속도 개선, 레이턴시를 이렇게 개발해서 개선한다

우리가 만든 기능은 인수테스트로 증명을 해야 한다. 내 코드를 어떻게 인수적으로 해야 할지 확인해야 함.

호스트 코드를 보고 실제로 돌려보는 것이 인수테스트임.

실제환경에서 도는 것을 확인하고 전진을 해야 함.

실제환경에서 실제로 도는지 알기 위해서 인수테스트를 하는 것.

코드를 짤 때 실제환경에서 돌아가는지 아닌지 확인을 해보면서 진행을 해야 함.(중급)

꼴을 알 수 없게 되는 상태에서 프로그래밍을 하는 것(고급)

코딩을 잘 하고 싶으면 특정 제품, 언어에 대한 선호를 버려라.

나의 트리를 찾고, 기저레이어에 접근할 수 있게끔 실력을 쌓아야 함.

어느 분야든 한 레이어씩 아래 단계로 내려갈 수록 연봉이 올라감.

하위 레이어로 내려갈 수 있도록 실력쌓는 것이 중요. 회사를 골라갈 수 있다.

다형성 : 부모형이 올 수 있는 자리면 자식형이 대신 올 수 있음

부모형을 사용하는 자리라면 자식형이 와도 사용할 수 있다

class Item{

 action(){

  console.log('item')

 }

}

class NormalItem extends Item{

 action(){

  console.log('Normal');

 }

};

const f = (item) => {

 item.action();

};

f(new Item);

f(new NormalItem);

item = new Item();

item.action();

<--->

item = new NormalItem();

item.action();

class Item{

 msg(){

  return this.action();

 }

 action(){

  console.log('item')

 }

}

class NormalItem extends Item{

 action(){

  console.log('Normal');

 }

};

item = new NormalItem();

const f = (item) => {

 item.msg();

};

f(new NormalItem); // Normal

다형성, 내적동질성, 대체가능성

class Item{

 msg(){

  return this.action();

 }

 action(){

  console.log('item')

 }

}

class NormalItem extends Item{

 action(){

  console.log('Normal');

 }

 test(){}

};

item = new NormalItem();

const f = (item) => {

 item.msg();

 item.test(); // 형 검사기가 없기 때문에 오류가 나지 않는다. 하지만 해선 안된다!

};

제네릭프로그래밍 : 제네릭한 알고리즘을 도출하기 위해서 추상형으로 메소드를 받음.

더 많은 형이 들어가면 갈 수록 제약조건이 많이 들어감.

그러므로 중복을 방지하기 위해서 추상형을 지향함. 중복되는 요소는 부모에 한번 기술하면 됨.

팩토리로 밖에 확장성을 주입받을 수 있다.

외부 라이프사이클이 있는 경우 DI를 주입가능