개발자가 하는 일은 무엇인가 ?
개발자는 '프로그램을 만드는 일' 을 한다.
프로그램은 왜 만들어는가?
프로그램은 '문제를 해결하기 위해' 만들어진다.
그렇다면, 개발자라는 존재는 어떤 존재인가?
개발자는 '프로그램'을 통해 '문제를 해결'하는 존재.
그리고 개발자로서 일하는 것은 이런 문제를 해결함을 통해 금전적 이익💰을 얻는 행위를 하는 것을 의미한다.
이런 프로세스를 기반으로 다양한 방법론들이 있다.
이러한 프로세스가 왜 팔요한 이유는 다음과 같다.
- 현실의 문제를 컴퓨터라는 가상의 공간에서 해결을 해야 하므로, 적합한 설계가 필요하다.
- 설계가 되었으면, 현실의 문제를 컴퓨터 시스템에서 해결 하도록 전산화 하는 과정이 필요하다.
개발자는 단순히 '코드 작성' 만을 하는 것이 아니라, 위 사진에서 보이는 프로세스 전반에 걸쳐서 역할을 하게 된다.
개발자가 문제를 해결함에 있어서 풍부한 경험, 직관이 있다면, 그것에 의존하게 되지만 한계가 존재한다.
(물론, 경험과 직관 또한 매우 중요하다)
- 경험하지 못한 새로운 문제 직면,
- 잘못된 직관을 가졌을 경우
그러므로 '유연하게 해결할 수 있는 방법론'을 익히는 것이 중요하다. 🔑
'개발자가 하는 거의 모든 일은 추상적이고 구조적인 생각에서 나온다.'
추상 : 여러가지 사물이나 개념에서 '공통' 되는 특성이나 속성따위를 '추출'하여 파악하는 작용
사실, 개발자들은 추상
이라는 개념을 상당히 많이 접한다.
하지만, 제대로 설명하기란 쉽지않다.
공통화와 추출 : 추상에서 가장 중요한 기법
추상의 핵심 :
사물을 단순화
하고 특정 관점에 따라재해석
하는 것.
현상 / 물체 -> 분석 / 해체 -> 결합
대상을 가능한 만큼 분해 후, 의도와 목적을 가지고 결합한다.
여기서 중요한 것은 '무의미한 분해는 의미가 없다' 는 것이다.
뼈만 보고 원래 진짜 모습을 알 수 없듯이, 과도한 추상화는 실제를 파악할 수 없다.
즉, 과도한 추상화는 개발에서도 위험하다.
어떤 기준으로 분해하고, 어떤 의도와 목적으로 결합하느냐에 따라 추상화의 결과가 다를 수 있다.
👉🏻 올바른 추상화는 '적절한 수준과 관점' 을 통해 나올 수 있다.
구조적 사고의 3가지 키워드 🔑
- 목적
- 무엇을 묶고 나눌 것인가
- 어떤 순서로 나열할 것인가
👉🏻 구조적 사고: "어떻게 나누고 채울 것인가" 에대해 고민하는 것,
🍧 추상화와 구조화에 대한 절대적인 기준은 없다.
늘 그렇듯, 은탄환은 존재하지 않는다.
구조화와 추상화는 흑백논리처럼 되거나 안되거나의 문제가 아니라, 계층과 같이 단계가 있다.
탑다운
바텀업
🍰 두 방법은 상호 보완적이다.
개발자는 현실의 문제
를 추상적이고 구조적인 사고를 통해 모델
로 표현 할 수 있다.
모델링 기법의 3가지
🍡Classification
- '어떻게 분류할 것인가?'
- Categorizaing : 비슷한 요소끼리 묶는것
- Grouping : 특정한 기준으로 묶는 것.
🍭Abstratcion
- '사물을 어떻게 바라볼 것인가?'
- Projection : 요소에서 필요한 내용을 뽑는것
- Layering: 요소를 계층으로 나눔
🍬Generalization
- '어떤 공통점이 있는가?'
- Pattern: 비슷한 사용사례를 묶어 공통적으로 쓸 수 있게 하는것.
- 디자인 패턴등이 좋은 예시.
소프트웨어는 다음 3가지 과정을 거쳐 만들어진다.
1. 도메인 모델링
2. 아키텍쳐
3. 코드 작성
위에서 언급했듯이 개발자는 문제를 프로그램을 통해 해결하는 존재를 의미한다. 👨🏻💻
도메인
은 우리가 해결할 문제
를 의미하며,
그러므로 개발자는 도메인을 통해 비지니스 로직을 설게 하는 것이다.
도메인 모델링 : 비지니스를 프로그램 세계로 표현하는 것.
즉, 요구사항과 전문지식을 개발세계로 변화시키는 과정을 의미한다.
모델링은 단계적인 추상화를 통해 현실의 문제를 프로그램 세계로 변화시킬 수 있다.
도메인 모델을 추상화를 통해 구체화 시키면 비지니스 문제를 개발세계로 가져올 수 있다.
아키텍쳐 : 개발자가 일을 하는 '방법' 을 의미한다.
아키텍쳐는 소프트웨어를 '어떻게 만드는가', '어떻게 나누는가' 를 의미한다.
일을 하는 방법을 의미하므로, 소프트웨어의 요구사항과 조직에 따라 달라질 수 있다.
아키텍쳐 문서를 통해 개발자들 간의 규칙을 생성할 수 있다.
아키텍쳐는 조직의 상황에 따라 변동가능하므로 언제든 변경가능하다는 유연한 사고를 가지는 것이 중요하다.
조직에서 가장 적정한 아키텍처가 무엇인지에 대한 고민은 필수적이다.
프로그래밍 패러다임
- 프로그램을 바라보는 관점. 인식의 틀
- 소프트웨어가 무엇으로 구성되어 있는가?
프로그래밍은 하나의 문제를 해결하기 위한 패러다임과, 그에 따른 방법론으로 구성된다.
사실, 패러다임은 컴퓨터가 보기엔 큰 의미가 없다. 패러다임은 사람을 위한 것이다.
패러다임의 좋은 예시 : 객체지향 패러다임
이러한 객체지향 패러다임을 필두로 여러 객체지향적 코딩 방법론이 생기게 되었다.
👉🏻 내가 만드는 소프트웨어는 어떤 패러다임이 적합한지 고민하는 것이 매우 필요하다.
로직의 3가지 관점
- usecase: 로직이 어떤 기능을 위해 존재하는지. 기능에 어떤 로직이 필요한가?
- aspect : 로직이 어떤 관점에서 사용되는지. 공통적으로 사용되는 로직이 무엇인가?
- function : 로직을 구성하는 함수. 로직에 어떤 함수가 필요한가?
세 가지 관점에 따라 로직을 분류 할 수 있다.
리팩토링은 기능을 수정하는 것이 아니라, 기능은 그대로 두고 코드를 개선하는 것.
3가지 리팩토링의 방법
- 추상화 : 코드내용을 숨길 것인가 드러낼 것인가.
- 구조화 : 코드 내용을 분리할 것인가 합칠 것인가.
- 일반화 : 공통되는 내용을 분리할 것인가 의도적으로 중복시킬 것인가.
👉🏻추상화, 구조화, 일반화의 '수준을 정하는 것'이 리팩토링 이다.
추상화와 구조화에 대한 인상적인 비유와 설명을 들었다.
개발이라는 것이 단순히 코드를 작성하고 기능을 동작하는 것에 그치지 않고,
더 좋은 코드를 위해 고민하고 생각을 끊임없이 하는 철학적인 것임을 다시 확신하게 되었다.
개발자는 코더가 아니다.
개발자는 소프트웨어을 찍어내는 사람이 아니다.
고민하지 않고,
더 욕심내지 않으면 성장할 수 없다.