Scroll indicator done

2024 인프콘 후기

세미나 2024. 8. 2. 22:55
728x90

2022년부터 꾸준히 참가신청을 했으나 항상 당첨이 안됐었고... 설마 3연속 탈락이겠어~라는 생각과함께 2024 인프콘도 티켓팅 대열에 합류했다. 

하지만 결과는...

이렇게 올해도 인프콘 다녀온 사람들의 후기글을 보며 부러워하는 일만 남았다고 생각하고 포기하고있던 찰나! 

이 누추한 곳에 귀한분이 자미님... 너무 감사합니다. 🥲

혹시라도 전산 착오라는 이야기가 나올까봐 잽싸게 초대권을 등록하고 인프콘 행사날만 기다렸다. 

현장의 열기... 아마 세션 시작 직전이라 많은 사람들이 발표장으로 들어갔을 타이밍에도 불구하고 사람이 많다...

2024 인프콘의 발표 세션들은 2024 인프콘 발표/프로그램 세션에서 확인할 수 있는데 몸이 5개면 좋을련만...
닝겐의 한계로 각 세션별로 한 개씩밖에 듣지 못했고 아래와 같이 총 5개의 세션을 들었다. 

  • 지속 성장 가능한 설계를 만들어가는 방법 - 김재민님
  • 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기 - 배휘동님
  • 처음으로 기술 리더가 된 개발자를위한 안내서 - 박서진님
  • 클린 스프링, 스프링 개발자를 위한 클린코드 전략 - 이일민(토비)님
  • 객체지향은 여전히 유용한가? - 조영호님
  • OpenAPI Generator 실전편: 효율적인 코드를 작성하는 법 - 이한님

 

1. 지속 성장 가능한 설계를 만들어가는 방법 - 김재민님

설계를 잘하는 방법은 "설계를 하지 않는 것!" 이다. 라며 시작부터 강한 어그로(?)를 끄셨던 재민님은 개념과 격벽의 이야기를 시작으로 웹툰 서비스, 커머스 등등의 사례로 예시를 들며 발표를 진행해주셨다. 

개념: 웹툰 서비스를 만든다고 생각해보자.
작가, 연재, 작품, 결제, 구매, 리뷰.... 더 나아가서는 PD, 랭킹, 포인트, 소장, 만료 같은 개념들을 떠올려볼 수 있고 자연스럽게 이를 그룹핑하는 시도를 하게될 것이다. 개념을 생각하면 할 수록 더 많은 개념그룹이 생기게된다.

격벽: 격벽은 접근에 대한 제어와 통제의 역할

개념과 격벽이 잘 설정되었는지에대한 척도

격벽을 만들었다면 변경한 개념과 관련된 코드만 수정이 생긴다. 
하지만 개념과 격벽을 잘못 관리하고있다면 전혀 다른 개념 그룹이 수정된다거나 혹은 같은 개념 그룹이 수정되지 않는다거나하는 상황이 발생한다. 

예시) 대출 - 사례

신청, 실행, 상환을 대출의 행위 정도로 바라봤으나 대출을 수정했을 때, 신청 서비스, 실행 서비스, 상환 서비스가 대출의 수정에 모두 영향을 받았고 대출이라는 개념을 너무 크게 잡은 것이 아닌가하는 의심이 발생 ➡️  행위로 분리했던 신청, 실행, 상환을 행위가 아니라 대출과 같은 크기의 개념으로 뽑아냄 상환이 실패하면 상환 재시도, 추가 이자 등을 실행하게되는데, 이 개념으로 넘어갈 때 까지 상환 개념에서는 상황 성공 혹은 실패 상태가 나왔을 때, 개념적으로 자기의 역할을 다 한 것! 상환 실패에 대한 재시도 연체라는 새로운 개념을 만들어냄. 상환 실패의 결과물로 연체를 만들어 냄. 상환 재시도, 추가 이자 --> 연체 납부와 연체 이자 (행위) 상태는 개념이 아니다. 개념이 상태에 표기되는 것

핵심 포인트

하나의 개념이 많이 쓰이면 분리를 검토하자
상태에 의해 개념이 생기면 격벽을 세워보자.

 

개념도 계층이 나뉘게된다

1 급 개념 > 2급 개념 > 3급 개념 ... > N급 개념

개념이 많은 소프트웨어는 개념 계층을 나눠서 생각해야한다.
비즈니스를 지탱하는 것을 개념으로 지칭하는 것이 맞다.
외부연동사는 개념없는 곳에 속할 확률이 높다.   (외부연동사는 커머스 사례에서 언급된 케이스)

격벽보다 더 높은 수준 참조 불가의 벽 의 안쪽에 외부 연동사를 둬야한다.

외부 연동사는 (수집 및 정제 영역으로 보고) batch를 통해서 db에 데이터를 긁어 저장하는 용도 정도로만 써야한다.
참조 불가의 벽은 별도의 모듈로 분리해서 확실하게 격벽을 쳐주는 것이 좋다. core 모듈에 외부에 의존하는 개념이 생기면 안된다.
core 모듈에 외부에 의존하는 개념이 생기면 안된다. 

미묘하지만 더 중요 혹은 덜 중요한 개념이 있다.
모든 것이 개념이 되진 않기 때문에 핵심 개념이 되는 것을 찾아서 관리해줘야하고 올바르게 개념이있는지 지속적으로 체크해줘야한다
외부나 핵심 비즈니스를 관리해서 더 명확하게해야한다.

진짜 핵심 

  • 인정하자 
    • 요구사항은 계속 변한다.  (요구사항은 변한다는 사실만 별하지 않는다) 
    • 완벽할 설계란 없다. 
    • Software는 Soft 해야한다. 
  • 하지말자 
    • 요구사항이 완벽해야 설계 가능해요. 
    • 우리 설계에서 그건 개발 못해요. (변경된 요구사항을 수용할 수 있도록 설계르 변경해야한다) 
    • 설계해 봐야 개발 일정이 나옵니다. 
  • 상기하자 
    • 성급한 설계는 모든 것을 망가트린다 
    • 과도한 설계는 모든 것을 망가트린다 
    • 설계는 필요한 만큼만 하자

 

분석 > 설계 > 구현   하지말고 지금할 수 있는 최소한의 구현을 먼저 했으면 좋겠다.
개념 + 격벽을 활용한 구현을 진행하고 증명 + 피드백 하면서  << 테스트 코드로 반복하면서... => (자연스럽게) 설계가 나오게 된다.

전달하고싶은 이야기

개념을 잡고 >> 격벽을 세워 >> 구현을 채워나가 >> "설계를 완성"한다


 

2. 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기  - 배휘동님

디버깅 역량을 효과적으로 키우기 어려운 이유 

  1. 신호 인식
  2. 과거 경험과의 유사성
  3. 전제조건
  4. 사전지식
  5. 과거 경험과의 유사성 

디버깅 고수들의 머릿속을 파헤치다 

Q. 디버깅을 잘하는 사람과 못 하는 사람의 차이가 큰 게 무엇인지 ? 

디버깅은 마법이 아닌 마술이다. (본인도 어떻게 하는지 모르는) 
  • 마법: 신비하고 이해하기 어려운 무언가 
  • 마술: 트릭, 손기술을 익히면 누구나 배울 수 있는 기술 

디버깅의 3단계 

  • 원인 파악 
  • 문제 해결 
  • 사후 처리 

디버깅 고수들은 원인 파악에 시간을 많이 쏟는다.  (전문성의 핵심) 

(디버깅 정의) 
디버깅 = 의도대로 동작하지 않는 무언가를 정상화하는 행위 
정상적인 상황이 무엇인지 명확히 정의를 내려야한다. 
정보 수집, 가설 설정, 가설 검증 <=> 어떤 조건에서 어떤 순서로 어떤 일들이 벌어져야 하는가?   => 심적 표상 

문제 원인 파악을 위한 5단계 가이드 (이자 훈련볍) 

  1. 문제 정의 
  2. 정상 동작 정의 
  3. 최소 재현 환경 구축하며 관찰 
  4. 차이를 발생시키는 다양한 원인 탐색 
  5. 가설 검증 및 검증 

위의 단계는  심적 표상을 만들어내는 것 

문제 원인 파악을 위한 5단계 가이드 (들어가기 전에) 

(사전) 작업을 위한 계획 세우기 (시간 분배 등) <-- 적절하게 멈추고 회고하기 

  1. 문제 정의 
  2. 정상 동작 정의 
  3. 최소 재현 환경 구축하며 관찰 
  4. 차이를 발생시키는 다양한 원인 탐색 
  5. 가설 검증 및 검증 
    • (사후)  해결법 설계, ROI 파악, 우선순위 결정... 

고수들은 1~5 단계를 꼭 순서대로 진행하는 것은 아님. 
1 <-> 5단계를 왔다갔다하며 진행함 

1. 문제 정의 

  1. 이정표 만들기
  2. 사전에 작업 계획 세울 때 함께 할 때도 많음
  3. 중간회고할 때마다 메타인지를 켜주는
  4. 다른 사람에게 문제에 대해 설명하고
  5. 이게 없으면 당장 중요하지 않은 문제에 빠져들어 시간을 허비할 수있음.

2. 정상 동작 정의

  • 심적 표상 만들기. '정상적인 환경에서는 어떤 조건에서, 어떤 순서로 어떤 일들이 벌어져야 하는가?'
  • 현재 벌어지는 일을 관찰 + 관찰한 정보 및 이미 알고있는 정보 적어보기
  • "올바른 동작"을 테스트코드처럼 적어보기 given when then
  • 올바른 동작을 정의하지 못하겠다면, 그걸 정의하기 위한 추가 정보를 여러 소스에서 수집해야 함.

3. 최소 재현 환경 구축하며 관찰

  • 직접 재현하기. '문제가 있는 부분을 어떻게 핀포인트하여 격리시킬까?'
  • 문제가 발생했던 사용자의 환경과 동작을 그대로 따라함 (세션 리플레이)
  • 격리하며 패턴 관찰 (조건을 무조건 참으로 만들거나, 정상이 될 때까지 하나씩 지우거나, 빈 프로젝트에서 시작해서 비정상이 될 때까지 나아가거나...)
  • 내 환경에서 재현이 안 된다면, 재현 조건 파악을 위한 추가 정보를 여러 소스에서 수집해야 함. (로그 심기, 사용자 인터뷰)

4. 차이를 발생시키는 다양한 원인 탐색

  • 머릿속 지도 펼치기 '두 환경의 차이가 어디에서 왔을까?'
  • 추상적이든 구체적이든 떠오르는대로 적어보기
  • 도메인 경험이 많을수록 첫번째 옵션이 진실일 가능성이 높으나, 주니어는 훈련을 위해서라도 3개 정도는 적어보는 게 좋음
  • 다양한 옵션을 적기 어렵다면 추가 정보를 여러 소스에서 수집해야 함.

5. 가설 설정 및 검증 옵션을 검증

  • 가능한 가설 형태로 문장화
  • 실제로 작은 변경을 가하면서 가설대로 현상이 변하는지 관찰
  • 가설이 틀렸다면 (오히려 좋아) 무엇 때문인지 적어보고 다음 가설로 넘어감
  • 끝내 원인 파악이 안된다면, 원인 파악을 위한 추가 정보를 여러 소스에서 수집해야 함.

디버깅 고수들의 도구

  • 좋은 도구의 존재를 앎
  • 가장 중요한 실용적 도구: 상황에 맞는 디버거 (프론트의 경우 크롬 디버거)
  • 마인드셋 그 자체

디버깅 고수들의 습관

  1. TDD Toilet Driven Development <<< 화장실에서 생각할 시간을 강제로 만듦
  2. DDD (PR) Description Driven Development 의미단위로 커밋을 쪼개고, PR 제목, 내용도 잘 쓰고 (추후 검색할 수 있게) 커밋은 나중에 찾아보기 위함이다. PR은 보는 사람을 잘 이해하게
  3. IDD Issue Driven Development

3. 처음으로 기술 리더가 된 개발자를위한 안내서 - 박서진님

기술 리더가 어려운 이유 

컴퓨터<< 같은 입력, 같은 출력   정량적 지표는 승리 (실행 시간, FPS, ...)
사람<< 같은 행동, 다른 결과  정량적 지표는 패배 (PR 숫자, 근무시간, ...)

그럼에도, 모든 것의 성공률을 높이는 방법

"동료들이 당신을 좋아하나요?" 

신뢰의 차이

 Q. 이런 피드백이 들어왔는데, 이렇게 해보는 것은 어떠세요? 

신뢰관계 형성X: 아, 좋은 말씀 감사합니다...
신뢰관계 형성O: 아, 좋은 말씀 감사합니다! 해볼게요! 

팀 리더의 의사결정을 바로 수용 
솔직한 이야기를 털어놓음
인정과 피드백

이분을 어떻게 변화시킬까요? 
이분의 퍼포먼스를 어떻게 높일 수 있을까요? 

`팀원들은 나를 믿고 좋아하는가?`

팀원이 나를 신뢰하는 7가지 순간

유능, 소통, 예측, 관심, 안전, 유사, 

1. 유능함 (Capability): 얼마나 유능한가?

팀 리더가 개인 기여

Q. 리더는 역량적으로 모든 면에서 유능해야 하나요? 
역량 그 자체보다는, 팀원의 문제를 해결해주는 것이 중요하다. 

(성공한 스타트업은 진통제성 제품을 만드는 경우가 많다 -> 진통제성 문제는 풀기만해도 사람이 몰려든다)

팀원이 제일 고민하거나 귀찮아하는 일을 해결해주자 

> 팀원 사이의 갈등을 중재해서 해결, 
> 미팅이 너무 많아서 힘들어하는 팀원의 일정 조정 
> 팀 안에서 라포를 형성할 기회 형성
> 프론트엔드-백엔드 개발자 사이의 협의 조율 

2. 팀원에 대한 관심(= Benevolent Concern)

Q. 케미가 잘 맞는 팀원이 있고, 그렇지 않은 팀원이 있는데, 모든 팀원에게 다 개인적으로 관심을 가져야하나요?
Q. 팀원의 문제에 공감이 잘 안되는데, 어디까지 공감을해야 할까요?

말하기 방식에 초점을 맞출 필요가있다. 

동감이 아닌 공감 

* 동감: 상대방과 똑같이 감정 느끼기
* 공감: 상대방의 감정을 이해해주기  (T인 개발자여도 곰감은 배울 수 있다)

팀원의 고민에 대한 의식적인 관심 

1 on 1이나 커피챗에서 팀원이 고민을 
1주 뒤나 다음에 마주쳤을 때, 꼭 언급해서 
신경쓰고 있다는 '티'를 내면 신뢰의 수준이 바뀐다. 


(관심 받기를 싫어하는 사람은 없다)

3. 소통의 원활함 (Level of Communication)

양쪽이 번갈아가면서 이야기하고 있는가? 
양쪽이 말하는 길이가 비슷한가? 

티키타카가 잘되는가...? 

4. 리더와 팀원의 유사성 (Number of Similarities)

리더와 팀원이 **유사한 점을 공유**할수록 

리더와 적절한 TMI는 **대화의 마중물** 
팀원이 리더 앞에서 자신의 시시콜콜한 이야기를 먼저 꺼내기는 어렵다.

5. 심리적 안정감 (Security)

팀원이 현재 상황을 안전하다고 느낄수록 신뢰가 생긴다.

Q. 팀 리더로서 어려운 이야기를 피해야 하나요? 
Q. 팀원이 잘 할 수 있을지 걱정되는데, 팀원의 업무에 어디까지 간섭해야 하나요? 

안전하게 이야기할 수 있고, 안전하게 간섭할 수 있다고 생각함. 

  • 지배: `팀원의 경험이 부족한 경우` , 구체적인 지시 --> 지금 기어를 D로 바꾸세요.
  • 리드: `팀원의 경험이 있는 경우`, 덜 구체적인 지시 --> 고속도로를 탑시다.
  • 위임: `결과가 예측 가능한 경우` 아주 추상적인 지시 --> 잘 다녀오세요.

토스에서는 이 3가지 중 어떤 방법을 써서 지시를 내릴 것인지 공유하려고 노력하는 중.
진실된 칭찬으로 팀원의 심리적 안정감을 높일 수 있다.  (진실된이 중요하다)
모든 팀원에게는 칭찬할 부분이 있다. (팀원의 단점은 또한 장점이 된다)

신중한 팀원  <-> 우유부단한 팀원
행동이 빠른 팀원 <-> 성급한 팀원 
사교적인 팀원 <-> 말이 많은 팀원
진중한 팀원 <-> 말이 없는 팀원 

6. 예측 가능성(Predictability & Integrity)

리더의 말과 행동이 일치하고, 
팀원이 리더의 행동을 예측할 수 있을 때 신뢰가 증가한다. 


1. 상호가 동의할 수 있는 사실부터 시작
2. 기대수준에 대한 명확한 정의
3. 상호 소통

팀원의 성공이 리더의 성공이고, 
리더의 성공이 팀원의 성공일 때 신뢰가 증가한다.

7. 팀원과 리더의 목표를 일치시키기 (Alignment of Interests)

나의 목표를 팀원에게 설득하는 것이 아닌 
나와 팀원의 목표를 아우르는 **공동 목표의 설정**

4. 클린 스프링, 스프링 개발자를 위한 클린코드 전략 - 토비님

동욱님 왈

일반적인 클린 코드 인식: 구현 능력과 속도가 떨어진다 ?

클린 코드를 처음 이야기한 사람: 켄트 벡

켄트벡 왈

작동하는 깔끔한 코드(= Clean Code That Works) 론 제프리즈의 핵심을 찌르는 이 한마디가 바로 TDD의 궁극적인 목표

Clean Code That Works

작동하지 않는 클린코드 ?

  • 전 클린 코드를 추구해서 주석은 작성하지 않습니다
  • 코드가 클린하면 리팩터링할 이유가 없지요
  • 클린 코드는 버그가 적어서 테스트 코드가 없어도 되지 않나요?
  • 클린 코드를 작성해야 해서 일정을 지킬 수 없습니다.
  • 클린코드 원칙에 위배되어서 리뷰를 승인할 수 없습니다.

➡️ 코드 결벽증, 원칙 지향 개발 ?

클린 코드가 강조하는 것

  • 읽기 좋은 코드
  • 이해하기 좋은 코드
  • 확장하기 좋은 코드
  • 유지보수하기 좋은 코드 << 위의 3가지 말을 포함하는 말

클린코드가 강조하는 것은 유지보수성(maintainability)

만들면서 배우는 클린 아키텍처

  • 품질에 관한 요구사항(비 기능적 요구사항)에서 유지보수성은 특별하다
  • 유지보수하기 좋은 코드는 확장하기 좋고, 안전하고, 신뢰할 수 있고, 좋은 성능으로 발전시킬 수 있고, 상호 호환성이 뛰어나서 변경하기 쉽다.
  • 유지보수성은 코드의 변경가능성과 동의어

유지보수하기 좋은 클린 코드는

개발 생산성과 유지보수성은

유지보수성 <-- 코드 --> 생산성

유지 보수성과 개발 생산성은 서로 영향을 주는 관계이다.

부채(Dept)

기술 부채(= Technical Dept) - Ward Chunningham

  • 개발하는 소프트웨어에 대한 현재 이해를 반영하는 코드를 작성하고 빠르게 출시
  • 소프트웨어에 대해서 배우게 된 것을 리팩터링을 통해서 코드에 반영
  • 그렇지 않으면 이자가 쌓여서 점점 큰 부담

부채를 상환하는 행위를 리팩터링이라고 함.
(이 내용도 포함된다...)

  • 코드를 대충 작성하라는 게 아님
  • 부채는 나쁜 코드에 대한 변명이 될 수 없음
  • 처음부터 리팩터링하기 좋은 코드를 만들어야 함

부채가 지속적으로 효과를 발휘하려면 **리팩터링(부채상환)**이 동력이 되어야 한다

클린 코드 선순환

`유지보수성`이 좋은 코드는 변경가능성이 좋다
빠르게 변경되는 코드는 개발 생산성이 좋다
(이미 조영호님이 이에 같은 이야기를 하신적이 있음)

시작은 어떻게 할까...?

개발 시작은 빠르고 간단하게

  • 익숙한 기술로
  • 핵심 기능이
  • 동작하는
  • 가장 단순한 코드를
  • 리팩터링하기 좋게 작성

일부 기능을 완벽하게 만드는 것으로 시작 X

유지보수성과 생산성의 균형을 잡아줄 리팩터링을 잘 하려면?

테스트

그런데 테스트를 작성하면 구현 능력 구현 속도가 또...

테스트를 빠르고 효과적으로 작성하면서 개발하는 능력이 필요
테스트는 연습이 필요하다.

개발 시작은 빠르고 간단하게 ... <<

누구에게?

  • 삼체 문제(Three Body Problem): 세 개의 천체가 서로의 중력에 의해 영향을 받으며 움직이는 운동을 예측하는 문제
    • 세 개의 천체 문제는 비선형적이고 일반적인 해를 가지지 않아 예측이 매우 어렵다
    • 각 천체는 다른 두 천체의 중력의 영향을 미쳐 복잡하고 예측 불가능한 운동을 한다.

서로 영향을 주는 것이 세 가지만 있어도..

팀워크(teamwork)

코드 >> 유지보수성, 생산성, 팀워크 (풀기 어려운 문제...)

유지보수성, 생산성, 팀워크 이 3가지는 삼체 문제의 삼체와 같다.
하지만 이것을 가능하게 해주는 것은 '클린 코드'이다.

클린 코드의 많은 원칙은 팀의 동료 개발자와 관계를 두고 말한다.

나만을 위한 클린 코드는 없다

클린 코드의 많은 원칙은 상황에 따라

탐험(Exploration)

팀과 함께 결정하고 탐험하고 학습하고 성장한다 <-- 토비님 마인드

함께 탐험하는 것을 즐거워하는 팀

어떤 외국의 여성 개발자의 발표에서..

Great teams make great people.

친절

교양있는 개발자

교양: 자신의 말을 하더라도 다른 사람의 기분을 나쁘지 않게 하는 것
-> 쉽지는 않다. 교양이 저절로 생기는 것은 아니다.

함께 코드를 작성하고, 읽고, 변경할 동료 개발자들에게 친절한 코드 를 만들었으면 좋곘다.

[토비님의 당부]

항상 친절하세요.
동료에게
자신에게

 

(스프링 개발에도) 클린 코드의 선순환 구조, 삼체 균형 모두 동일하게 적용 가능

자기 책임에 충실한 오브젝트로 구분하고 의존관계를 유연하게
클린 (자동) 구성 정보

헥사고날 아키텍처

계층과 모듈 경계에는 API, 즉 인터페이스를 사용

테스트를 안 만들거면 스프링을 뭐하러?
스프링 가치의 절반은 테스트.. << 토비님의 의견

DB 테스트에는 @Transactional을 사용 (재민님, 동욱님은 반대의 의견을 내셨었고 토비님은 이에대한 생각을 SNS에 밝히신적이 있다)

클린 스프링에서는 트랜잭셔널을 사용해야한다. (ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 강하게 어필하심)

클린 코드는 항상 코드에 관심을 가지고 보살피는 사람이 작성한 것처럼 보인다.


5. 객체지향은 여전히 유용한가? - 조영호

(조영호님 발표 때는 세션 막바지에 가까워져서 체력이 바닥난터라 살짝 지쳐있어 누락된 내용이 많다 🥲)

Q. 객체지향은 여전히 유용한가요?
A. 왜 그런 생각을 하셨어요 ?

객체지향을 배울 필요는 있다. (객체지향 언어를 쓰기 때문에)
맡으시는 도메인 혹은 팀의 특성에 따라서 정말 배워야하는가? 가 궁금했을 것으로 추측

절차적인 설계 vs 객체지향 설계

가장 큰 포인트는 변경이다.

절차적인 설계

데이터와 프로세스를 별도의 클래스로 구현하는 방식

데이터를 바꾸면 프로세스도 같이 바껴야한다. (= 결합도가 높다)

객체지향 설계

캡슐화 때문에 데이터가 변경되도 하나의 클래스만 변경

  • 데이터가 바뀔 때는 객체지향 설계가 더 좋다.

객체지향 설계에서는 적합한 클래스로 분배되고, 분산된다.
객체지향 설계는 유연성을 위해서 큰 리팩터링이 필요하다. 그에반해 절차지향 설계는 국소적 리팩터링이 필요하다.

다른 코드를 수정하지 않고 데이터 변경과 타입 확장 가능
반면에 절차적인 코드는 무조건 내부 코드를 수정해야한다.

설계가 계속 발전하고 진행할 수록 코드의 규모만 커지지 일관성을 유지할 수 있다.
절차지향 설계는 그런 룰을 강제하기가 어렵다.

다형성과 기능 추가 사이의 긴장

타입 계층 전체 수정

절차적인 설계가 객체지향 설계보다 더 낫다

  • 절차적인 설계
    • 포맷 변경을 위한 데이터 변환
    • 데이터 중심
    • 데이터 노출
    • 기능 추가에 유리
  • 객체지향 설계
    • 규칙에 기반한 상태 변경
    • 행동 중심
    • 데이터 캡슐화
    • 타입 확장에 유리

내가 다루는 것이 데이터라면 절차적인 설계로 짜는 것이 좋다.

데이터의 응집도 단위로 클래스를 분리한 것이 아니라 행위 단위로 클래스를 분리했기 때문에

레이어 아키텍처

  • 프리젠테이션 레이어: 절차적, 데이터 변환
  • 서비스 레이어: 절차적, 애플리케이션 플로우 처리 (말 그대로 절차 이다!)
  • 도메인 레이어: 객체지향, 규칙 기반의 상태 변경
  • 퍼시스턴스 레이어: 절차적, 데이터 변환

특정한 목표에 맞게 절차적, 객체지향적 설계를 혼합해서 쓰고있다!

절차적인 데이터 조회

도메인 레이어가 필요없을 수 있음.

(질문을 이렇게 바꾸는게 더 적절하다! )
객체지향은 여전히 유용한가요? --> 객체지향은 언제 유용한가요? (혹은 언제 유용하지 않은가요?)

a를 배우는게 좋을까요? b를 배우는게 좋을까요? 등에 대한 질문...
일단 배워봐라

도구하나 배우라고 생각하는게 좋다.

어떤 설계도 어떤 기법도 모든 경우를 커버하지 못한다.

코드의 목적과 변경의 방향성에 따라
언제 어떤 기술을 사용할지 결정하세요

유용하지 않은 기술은 없다.
언제 어떤 경우에 유용한지를 생각하지 않는 경우가 많은 것 같음.

2024 인프콘이 끝난지 아직 하루도 안지났는데 벌써부터 2025 인프콘이 기대되는 것은 오늘 너무나도 끝내주는 발표들을 만난 탓이 아닐까 싶다. 즐거웠고 다른 세션들은 영상나오면 하나씩 챙겨볼 예정이다. 

728x90