개발자는 대게 2가지로 분류
기술 주의
대상을 물리적인 기술에 기준하여 해석하고 평가하는 사고 방식
논리 주의
대상을 추상적인 논리에 의해 해석하고 평가하는 사고 방식
대상 을 해석하고 평가할때, 두 가지 주의로 바라보면 대상을 바라보게 된다
추상화 & 구체화
구체화가 모여 추상화가 된다
구체화가 추상화에 의존
구체화는 추상화가 없이 존재할 수 없다?
•
추상화는 인간 복잡도가 높고, 구체화는 인간 복잡도가 낮다
•
추상화는 높은 수준, 구체화는 낮은 수준
◦
낮은 수준은 높은 수준 없이는 존재하지 않습니다.
◦
추상화는 논리주의, 구체화는 기술 주의
◦
EX) 음악은 추상화(높은 수준) , 가창력은 구체화(낮은 수준)
▪
사람의 감정을 움직이게 만드는 가수(대상)가 논리적으로 뛰어남
▪
가창력과 기교가 좋은 가수가 기술적으로 뛰어남
그러나, 학원(대상)은 기술을 잘 알려주는 곳이 좋다
그렇다면, 소프트웨어는 어떨까요?
예시들을 살펴보겠습니다
Command Pattern
개체 자체가 명령이다
아래 예시는, 구체화(기술)의 관점에선 동일하지만, 추상화(논리)의 관점에선 동일하지 않다고 볼 수 있다
class SaveCommand() {
void Execute() {
}
}
class Save() {
void Run() {
}
}
JavaScript
복사
API로써, HTTP 통신의 단점
도메인을 풀어낸 원격지의 API 호출 계약
기술 주의
•
데이터 전송 오버헤드
•
비 압축 데이터 전송
•
등등…
논리 주의
•
통신 계약이 너무 구체적으로 표현되어 도메인 적용이 무리
◦
동사 GET, POST, PUT, DELETE
▪
타이머를 만든다고 했을때, TimeStart를 호출하면, 어떤 동작을 해야할까?
▪
이미 4가지 동작방식만으로 제공되기에, 구체적으로 동작을 만들어내기 어렵다
연속 통합(CI)
작업자들의 결과물을 매우 자주 통합하자는 것
빌드 자동화 사용 : Github Actions
•
자동화(기술)를 쓰고 있을뿐, 연속 통합의 정의(논리)면에서는 연속통합 중인지 체크할 수 없음
빌드 자동화 사용X : 모든 팀원이 Task를 하루 안에 끝낼 수 있는 양으로 쪼개어 매일 병합
•
자동화(기술)을 안 쓰고 있지만, 확실하게 연속 통합의 정의(논리)면에서는 지켜지고 있다
본론 을 살펴보자
논리 주의자
대상을 기술주의, 논리 주의에 기준하여 해석하고 평가하는 자
패러다임, 특징, 논리 집착
거시적 관점, 인간 복잡도를 중요시함
실제 가치 창출, 인간적 입장
특정 기술을 깊게 하지 않음
높은 수준에서 생각
기술 주의자
대상을 기술주의에 기준하여 해석하고 평가하는 자
성능, 기술, 최적화에 집착
미시적 관점, 시간 복잡도, 공간 복잡도를 중요시함
신기술, 트렌드, 기계적 입장
특정 기술을 사랑함
낮은 수준에서 생각
대부분의 시장 참여자들은, 논리주의가 매우 약하다
그래서 대상을 생각할때, 논리주의적 관점으로 대상을 해석해야한다
(논리주의는 두 관점 모두를 고려하기에)
보통 대부분은 처음엔 기술 주의로 시작하게 되고, 보통 그럴 수 밖에 없긴 하다
여기서 시간이 지난 후엔, 극소수만이 논리 주의자로 발전할 수가 있는 것이다
현재 시장의 대다수는 기술주의자이다(시작은 보통 쉬운걸로 하기 때문에)
당연하게도, 패러다임같은 추상화 기법들은 어렵다
그렇기에, 시작하기가 어렵다. 그러나, 소수가 되기 위해선 결국 논리주의자가 되어야한다
기술 주의자들은,
답이 공간 복잡도와 시간 복잡도 그 사이에 위치한다고 본다
논리 주의자들은,
답이 공간 복잡도, 시간 복잡도, 인간 복잡도 그 사이에 위치한다고 본다
이처럼 객체지향적 언어들은, 기계들에게 매우 불리하다 → 논리적이다
이렇게 기계들을 불편하게 만드는 것들은, 인간 복잡도를 낮추는 작업이다
클린 아키텍쳐
Robert C. Martin은 소스코드를 제공하지는 않는다
그는 논리주의자여서, 클린 아키텍쳐는 중요하다고 말하지만, 소스코드는 불필요하다는 말이다
대중들은 마틴의 생각과는 달리, 직접 예제를 만들어서 구체화시켜 공유하고 다룬다.
논리가 중요하다. 예제를 만들어서 뭐하는가?