끝이 없을 모험 이야기

Design Pattern의 효과
Design Pattern을 통해 내가 만들 소프트웨어에 어떤 class가 존재해야 하고 그들의 관계는 어떠해야 하는지를 빠르게 이해하고 접근할 수 있다.
최근 언어들은 Hello World!! 부터가 아닌
최소한의 구조가 갖춰진 프로젝트 형태에서 시작함
 
Design Pattern을 재사용하는 이유
재사용: 생산성(보다 빠른 시간안에 소프트웨어를 출시하기 위함)과 신뢰성(그 패턴이 오랫동안 사용되어 와서 대부분의 문제가 정리되었다고 봄) 증가, 개발 시간 감소
디자인 패턴도 재활용, 재사용한다.
 
Design Pattern
흔히 발생하는 문제에 대한 솔루션을 재사용한다. 특정 프로그래밍 언어의 특징을 반영하지 않는다. 코드와 밀결합된 것이 아니다. Class와 그들의 상관관계에 대한 것이다. 알고리즘의 상위개념이다.
객체지향 디자인 패턴: 전형적으로 클래스나 오브젝트 간의 상관관계를 보여준다.

 
Adapter Pattern
신입 사원이 주로 쓴다.
목표: 기존의 클래스, 코드를 수정하지 않으면서 서로를 연결하기 위해 만들어졌다. (건들면 안 되는 입력 파라미터 3개를 요구하는 adaptee와 입력 파라미터 1개를 요구하는 adaptee를 연결해주기 위해 중간에 adapter를 끼워 맞추는 것이다.) 양립 불가능한 인터페이스를 가진 클래스들을 작동하게 하기위한 코드이다.
Adapter 클래스가 adaptee를 호출한다.
c++에서는 adapter class가 어댑티 클래스를 상속했다.
C++은 다중 상속이 됨( istream, ostream을 상속받는 iostream)
다중 상속이 안되면, mixing class를 사용함.
Adaptee: 수정X
Adapter: 우리가 작성, 수정하는 코드
1대1의 관계
Adapter class가 adaptee를 부르고 클라이언트의 입력을 연결해주는 역할
adaptee, 클라이언트를 안 고쳐도 됨!
 
Façade Pattern
1대n의 관계
겉면만 모양을 유지하고 뒤는 좋게 바꾸는 것이다.
목적: 사용자의 interface는 바꾸지 않겠다.
Client가 Façade class를 호출하면 파사드는 필요에 따라 다른 클래스를 호출한다. 파사드 클래스의 메소드 안에서 클래스의 객체를 생성한다.
성능이 좋지 못하다는 단점이 있다.
사용자가 복잡한 서브 시스템에 직접 접근하지 못하도록 한다. 예쁜 인터페이스로 입구를 차단해버림
내부에 작동하는걸 외부에 보여줄 필요가 없다.
모든 프로그래밍 언어의 기본 철학
Information hiding, Encapsule 좋음
 
Decorator Pattern
객체가 동적으로 움직이고 있는 중에 특정 기능을 추가하고 뺄 수 있다. 게임에서는 아이템이나 무기를 추가할 수 있도록 하는 디자인 패턴이다. 즉 기능을 추가할 수 있다.
1대n의 관계

Component를 base로 하여 concreteComponent와 decorator class를 생성하고 decorator를 base로 하는 concreteDecorator class를 생성한다. Decorator는 component 클래스와 has relationship 관계이다. 이때 ConcreteComponent는 가장 기본적인 아무것도 없는 캐릭터이고, concreteDecorator는 갑옷, 칼, 총 등 추가되는 아이템들이다.
ConcreteComponent: 가장 기본적인 아무것도 없는 캐릭, 먼저 실행됨
ConcreteDecorator: 갑옷, 칼, 총 등 추가되는 아이템들
 
Singleton
반드시 하나의 객체만 존재해야 한다. 절대로 이 클래스에서 만들어진 객체가 두 개 이상이면 안 된다. Ex) 자원을 관리하거나 중요한 데이터를 관리하는 프로그램에서 사용됨, 하드웨어의 자원은 물리적으로 하나이다. 두개 이상의 제어가 발생할 경우 충돌한다.
 
최근에 나온 소프트웨어 디자인 관련 책: clean code, clean, architecture
디자인 패턴은
SW 설계에 있어 시행착오를 줄여 줌
Design Pattern은 매우매우매우 호불호가 갈릴 수 있음
클래스 다이어그램으로 시각화
언어마다 구조가 다를 수 있음 -> Dependency
 
디자인 패턴의 비판
1. poor language
언어가 별로 안 좋아서 기능적을 부족한 게 많아서 디자인 패턴을 고민하는 것 아니냐?
23개 중 16개 의미가 없었음
-> 그래도 7개는 의미 있네, 쓰기 싫으면 쓰지마 (호불호 갈림)
2. 불필요하게 복잡성만 높인다.

디지털 노마드의 정의

디지털 노마드: (직장이 아닌 다른 곳으로 떠나) 원하는 곳에서 개발하거나 일할 자유를 말한다. 유목민이라고 말하기도 한다.

어디에서 일하는 지를 정하는 대신 그 선택에 책임을 져야 한다.

디지털 노마드를 찬성하는 고용주의 입장

고용주들은 전세계적으로 최고의 인재를 모을 수 있다. 중견, 중소 기업에서 국내의 인재들을 데려오기 힘들 때 다른 나라에 있는, 예를 들어 비교적 인건비가 저렴한 인도에서 경쟁력 있는 인재를 고용할 수 있다.

디지털 노마드를 찬성하는 개인 개발자의 입장

편리하다는 장점이 있다. 이동시간이 감소된다는 점, 집을 새로 마련하지 않아도 된다는 점, 주거비. 식사. 교통 면에서 직장에 출근하여 직장에서 일하는 것보다 비용이 적게 든다. 즉 경제적 부담이 감소된다. 또한 근무 시간이 자유롭다는 장점이 있다.

Covid 이전과 이후의 디지털 노마드를 찬성하는 이유

Covid 이전에는 훌륭한 인재를 채용하기 위해 디지털 노마드를 했다면, Covid 이후에는 직원을 한 곳에 모아두지 않는다면 돈을 안써도 된다는 것을 깨닳았기 때문이다. 예를 들어 직원을 한 곳에 모아뒀을 때 들어가는 부동산 값, 커피 값, 식당 등 업무 환경을 위해 드는 잡다한 비용이 많다.

이전에는 직원의 움직임, 장소에 벗어나는 것 등에 압박

이후에는 거점 오피스 등이 많이 생기고 장소 압박이 적다 (문화적 변화)

어디서 디지털 노마드를 하는지, 그리고 그 기준은?

기준

1.인터넷이 빠른가?

2.물가가 싼가?

장소

일본, 캘리포니아: 집 가격이 비싸서 비대면을 좋아함

한국은 치안이 괜찮은편이다. 그래서 서울로 많이들 디지털 노마드 하러 온다.

제주도에서 가장 열심이다.

제주도에는 다음, 카카오 본사가 있다. 장소에 독립적인(회사가 어디 있든 문제없는) 개발사들을 위치시켜 지역 활성화를 유도한다. 제주도가 그 예시이다.

워케이션: work+vacation: 휴양지 등에 회사를 위치시킨다.

디지털 노마드 tools

Slack은 Collaboration을 위한 것이다. 업무용 채팅 소프트웨어이고 개발 도구와 연동이 된다. 과거의 기록을 찾아볼 수 있다.

구글 드라이브는 Team Work를 위한 것이다.

Zoom은 Communication을 위한 것이다.

Doist(Item Manager), TRELLO(Project Manager), Parabol(Agile Meeting)

보안 때문에 웹에서 IDE를 구현하는 경우도 있음

애초에 코드가 세어 나가지 않도록

애자일 스크럼, 깃허브 etc...

기업에도 채팅 시스템 존재:

채팅 로그, 트래픽 분석을 통해 직원의 영향력 등을 파악함

다 감시하고 인사과에서 유용하게 씀

실제로 네이버 비즈니스 플랫폼은 기업들한테 제공하는 서비스

기업들은 빠르게 서비스를 만드는 것이 중요함

-> 웹 서비스 구현을 전부 오픈소스로 해버림

    -> 서비스 사용화 시간 단축

미네르바 대학

크게 5개 학과로 나눠 여행하면서 온라인으로 수업 받음. 여러 나라로 여행을 다니면서 교육을 함. “비판적인 사고, 창의적인 사고, 효율적인 소통”

전 세계 7개의 도시를 순환하면서 학생들이 함께 생활하는 하이브리드 주거 모델을 제공함.

철학: 고등 교육의 위기, 꼭 대학에서 해야 할 필요가 없음, 대학에서는 실용적 지식을 가르쳐야 함, 글로벌 문화, 다 차원적인 교육, 우리 시대의 가장 복잡한 문제를 해결하는 데 필요한 광범위한 지식과 실용적인 기술

MIT는 서로 다른 전공의 사람들이 모여 협업하고 인프라 제공에 대학의 의미가 있다고 함.

인류 존속에 관한 문제 해결을 위한 학과 존재함.

과 5개: 예술&인문학, computational sciences(컴퓨터를 도구로 삼아 문제를 해결함, engineer 계열은 아님), 자연 과학, 사회 과학, 비즈니스

computational sciences: 컴퓨터로 사회 문제를 분석한다. Computer science가 아니다.

문제를 찾아서 해결하는 방식으로 가르침. Learn the critical skills you need to make evidence-based, data informed decisions.

Tokbox: Active Learning Platform

Uncertainty: 불확실성에 대한 대비로 개인의 능력을 기른다

불확실한 미래에 대해 개인 주도적 문제 정의 및 해결을 위함

여행은 이러한 문제정의에 대한 도움

프랑 에꼴 42: 교수가 없는 교육 기관 -> 한국에서도 모방해 42서울을 만듦.

1. unittest

 Unittest를 처음 경험해보기 때문에 먼저 매우 간단한 코드를 통해 unittest를 해보았다. myCalc.py 파일에 input 파라미터를 두 개를 받아 더한 값을 return 해주는 add함수와 input 파 라미터로 두 개를 받아 첫 번째 input에서 두 번째 input을 뺀 값을 return 해주는 substract 함수 를 정의했다.

그리고 나서 unittest를 위한 test.py 파일을 작성했다. unittest.TestCase로부터 파생된 MyCalcTest 클래스를 생성했다. 그리고 test_add와 test_substract 테스트 메서드를 작성했고, 그 안에서 self.assertEqual()를 사용하여 결과를 검사했다. 마지막 줄에서 unittest.main()이 실행되면, 테스트 메서드들이 실행되게 된다.

여기서 주의할 점은 테스트 메서드의 이름은 반드시 test로 시작해야 한다는 것이다. 그래야 테스트를 실행할 때 해당 메서드가 누락되지 않고 정확히 테스트 케이스로 인식이 된다.

unittest 모듈의 TestCase 클래스틑 assertEqual 말고도 assert로 시작하는 많은 메서드를 제공한다.

MyCalcTest 클래스는 TestCase 클래스를 상속하고 있기 때문에 부모 클래스인 TestCase가 제공하는 모든 메서드를 self를 통해 접근하여 호출할 수 있다.

IDLE에서 test.py를 실행한 결과는 다음과 같다. 두개의 메서드를 통과했기 때문에 점( . )이 2개가 찍히는 것을 볼 수 있다.

참고로 점( . )대신에 좀 더 자세한 피드백을 받고 싶다면 -v 옵션을 붙여서 테스트를 실행하면 된다.

test_add 메서드와 test_substract 메서드가 잘 실행된 것을 볼 수 있다.

test_add 메서드를 아래와 같이 수정하고 test.py 파일을 실행하면,

테스트가 실패했다고 알려주며 어떤 부분이 틀렸는지를 피드백 해준다.

2. unittest.mock

 mocking이란 단위 테스트를 작성할 때 외부에 의존하는 부분을 임의의 가짜로 대체하는 기법 이다. 즉, 외부 서비스에 의존하지 않고 독립적으로 실행이 가능한 단위 테스트를 작성하기 위해 서 사용되는 테스팅 기법이다. 다른 사람의 코드를 사용해 짠 코드를 테스트해야 하는데 아직 다 른 사람이 코드를 다 작성하지 못했을 때 사용한다.

test.py를 수정하여 unittest.mock를 사용해 코드를 작성하고 실행시켜 보았다. 결과는 아래와 같다.

20과 10을 더하면 30이지만 mock을 통해 실패하지 않고 정상이라 판단되었다.

 TDD 기법에 대해 공부한 후 직접 unittest를 해보니 더 잘 와닿는 것 같다. 평소에 소프트웨어 를 작성하는 방식과는 조금 달라 신기했지만 생각보다 괜찮은 기법이라고 여겨진다. 다음에 소프 트웨어를 개발할 대 TDD 기법을 이용해 해봐도 좋을 것 같다는 생각이 들었다.