소프트웨어 설계를 위한 추상적, 구조적 사고

(present.do)

소프트웨어는 어떠한 문제를 해결하기 위해 존재합니다. 그렇기 때문에 개발자는 문제를 이해하고 그것에 맞게 설계하여 구현합니다. 이때 문제를 이해하고 설계하는 데 있어 개발자에게 추상적 사고와 구조적 사고는 큰 무기입니다.

보통 추상적, 구조적 사고는 난해하거나 두루뭉술하게 설명될 때가 많습니다. 하지만 이러한 사고를 하는 구체적인 방법론은 분명히 존재합니다. 이 발표에서는 개발자가 추상적이고 구조적인 사고를 하는 구체적인 방법과 이러한 사고를 통해 도메인 모델링, 리팩토링, 아키텍처 등 소프트웨어를 설계하는 법을 소개합니다.

개발자가 하는 일은 프로그램을 만드는 것
프로그램을 만드는 이유는 특정 문제를 해결하기 위함이고 문제를 해결하는 이유는 비즈니스를 위한 것
프로그램을 만들 때 네 가지 단계로 이루어져 있음
- 이해 / 분석 -> 설계 -> 구현 -> 피드백
개발자는 시니어가 될 수록 코드 작성 뿐만 아니라 이 모든 단계에 관여하게됨
시니어는 경험을 기반한 직관을 통해 문제를 빠르게 해결함
하지만 직관은 위험할 수 있음. 따라서 방법론을 익히는 것이 중요
추상적, 구조적 사고가 그러한 방법론의 기초
추상은 요소에서 공통적인 것 혹은 관심있는 것을 추출하는 것
그래서 추상은 사물을 단순화 한다음 재해석하는 것이라 볼 수 있음
요소 환원주의 사고를 통해 단순화하고 재해석 할 수 있음
요소 뿐만 아니라 행동도 추상화가 가능하다.
추상화는 계층이 존재한다.
- 적절한 추상화 수준을 정해야 한다.
- 과도한 추상화는 실체를 알 수 없기 때문에 좋지 않다.
구조적 사고는 내용을 겹치지 않고 빈틈없이 정리하는 것
- MECE 프레임워크와 유사
중요한 것은 무조건 겹치지 않고 빈틈없이 정리되야 한다는 점은 아님
구조화도 추상화처럼 단계가 있습니다. 한 발자국 더 멀리서 보는 것이 가능
추상적이고 구조적인 사고 방식을 하는 구체적인 방법이 존재함
- 탑다운과 바텀업
- 모델
  - Classification
  - Abstraction
  - Generalization
- 프레임워크 사고
소프트웨어 설계에 추상적, 구조적 사고 적용 가능함
소프트웨어 구현 단계를 크게 3가지로 나누면 도메인 모델링, 아키텍처, 코드 작성으로 나눌 수 있음
도메인 모델링은 요구사항을 추상적으로 뽑아내고 점진적으로 확장하는 것이 가능
아키텍처는 일을 하는 방법을 나타냄
- 어떻게 일하는가, 어떻게 나누는가
아키텍처는 요구사항 -> 컨셉 -> 구현 -> 피드백 프로세스를 따름
추상적인 아키텍처 컨셉을 점진적으로 구체화하는 것이 가능
프로그래밍 패러다임은 소프트웨어의 구성요소를 바라보는 시선
로직은 세가지 측면으로 바라볼 수 있음. Function, Usecase, Aspect
문법 설탕은 추상화된 프로그래밍 문법
- 독이 될 수도 있음
리팩토링은 패러다임, 코드 크기, 소유권, 중복 여부, 수정 가능성, 의존이라는 6가지 관점으로 볼 수 있음
리팩토링은 세 가지 방법이 존재. 추상화, 구조화, 일반화
추상적이고 구조적인 사고력을 기르기 위해선 다양한 경험을 하는 것이 좋음
도식화를 하는것은 큰 도움이됨
직관은 경험주의적 사고. 시간을 절약할 수 있지만 위험할 수 있음
패턴은 추상적인 사고를 익히는데 도움이 됨
꼭 추상적이고 구조적인 것이 만능은 아님