꽤 늦은 인프콘 이야기 (8/2)
첫번째 세션
지속 성장 가능한 설계를 만들어가는 방법
토스 페이먼츠 - 김재민
https://www.inflearn.com/conf/infcon-2024/session-detail/877/
설계를 잘하는 방법
오늘 이걸 들으면 설계를 잘할 수 있다고 함
그 방법은 설계를 하지 않는 것이라고 하넹?
실제로 이야기 하고 싶은 것은 구현
개념, 격벽
개념 :
특정 도메인에 기준으로 생각을 했을 때 여러 연관된 정보들이 떠오르는데, 이때부터 어느 정도 그룹화 시켜 개념들을 묶기 시작한다.
이렇게 개념을 묶어서 생각하다보면 그룹이 많아질 수 있다.
이렇게 되면 개념의 흐름이나 경계가 잘 구분되지 않는다.
이럴 경우 개념 그룹을 명확하게 경계를 구분한다.
격벽
개념들 사이에 격벽을 세우고 경계를 만들어야 한다.
이런 구분을 짓지 않으면 경계가 허물어져서 문제가 발생할 수 있다.
코드 구조 예제
개념이 잘 나뉘어져 있는지 확인하는 방법은 그룹화 시킨 것들 중 하나의 클래스를 수정했을 때 영향이 있는 클래스들을 살펴보면 잘 개념과 격벽을 세웠는지 확인할 수 있다.
하나의 개념이 많이 쓰이면 분리를 검토하자
- 코드를 작성한 내용을 확인했을 때에도 거대해지는 것을 방지하는 것이 좋다
상태에 의해 개념이 생기면 격벽을 세워보자
상태나 행위를 개념으로 착각할 수 있다.
- 면밀히 살펴보고 올바르게 행위인지 상태인지 구분이 필요하다.
스스로 비즈니스를 제어할 수 있는 곳을 개념으로 규정한다.
개념에도 계층이 있다?
모두 같은 수준의 개념이 아니라는 것.
모든 것이 개념이 되지 않는다.
개념 영역을 분리할 수 있다
설계
어느 정도 숙성이 된 설계에 대해서는 설계 변경은 어려운 것이다.
소프트웨어는유연해야하고 변경 가능해야 한다.
아래 내용을 명심해야 한다.
- 요구사항은 계혹 변한다.
- 완벽한 설계란 없다.
- Software는 Soft 해야한다.
하지 말아야 되는 말
- 요구사항이 완벽해야 설계 가능해요
- 우리 설계에서 그건 개발 못해요
- 설계해 봐야 개발 일정이 나옵니다.
이런 말을 안하도록 해야 한다.
그리고 다시 한번 생각해야될 것은
- 성급한 설계는 모든 것을 망가트린다.
- 과도한 설계는 모든 것을 망가트린다.
- 설계는 필요한 만큼만 하자
기존 개발 과정
분석 -> 설계 ->구현
세션에서 이야기 하는 것
구현부터 해라
개념 + 격벽
Test code
증명 + 피드백
이런 구조로 진행하면 자연스럽게 설계가 나오게 된다.
그래서 세션 마지막에 하는 말
설계를 하지 않는 것 이란 마지막에 말한 개념 + 격벽 + 테스트 코드 + 증명 + 피드백 = 설계 이기 때문이다.
———————————————
두번째 세션
디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기
- 배휘동 XL8
https://www.inflearn.com/conf/infcon-2024/session-detail/862/
실리콘밸리 팀에서 프론트엔드 팀 리더로 일하고 계신다고 함
Media cat 서비스를 담당하고 있다.
Front end 위주의 내용을 이야기 함
Gary Klein
인지작업 분석 CDM 관련 내용도 일부 함
디버깅 행동들을 나열하고
디버깅을 잘하는 사람과 못하는 사람의 차이를 위의 행동에서 선택해서 확인한다.
디버깅 3단계
- 원인 파악
- 문제 해결
- 사후 처리
3단계로 나뉘어지지만 비중은 서로 다르다.
원인 파일이 크거나, 문제 해결이 크거나 사후처리가 크거나
디버깅 고수들은 원인 파악에 비중이 매우 크다(7정도) 3은 문제해결, 사후처리 1정도
원인 파익은 디버깅 전문가들의 핵심 역량이다.
디버깅 의도대로 동작하지 않은 무언가를 정상화 하는 행위
정상적인 환경에서는 어떤 조건에서 어떤 순서로 어떤 일들이 벌어져야 하는가?
이게 심적 표상이라고 하네
마음 속에 존재하는 지식 구조
정보를 이해, 기억, 분석, 활용해 올바른 결정을 내리도록 도와줌
패턴 인식과 의사 결정을 위한 Decision Tree가 매우 선명하게 있다.
고수들의 디버깅은 양과 질이 좋다.
5단계 가이드
- 문제정의
- 정상 동작 정의
- 최소 재현 환경 구축하며 관찰
- 차이를 발생시키는 다양한 원인 탐색
- 가설 설정 및 검증
이게 디버깅 훈련법이다.
들어가기 전에
사전 : 작업을 위한 계획 세우기 (시간 분배 등) -> 적절하게 멈추고 회고하기
- 문제정의
- 정상 동작 정의
- 최소 재현 환경 구축하며 관찰
- 차이를 발생시키는 다양한 원인 탐색
- 가설 설정 및 검증
사후 : 해결법 설계, ROI 파악, 우선순위 결정
원인 파악이 거의 핵심이라 생각한다.
맞는 말이지
이정표를 잘 만들어야 한다.
정상적인 환경에서 어떤 조건에서 어떤 순서로 어떤 일들이 벌어져야 하는가?
- 현재 벌어지는 일 관찰 관찰한 정보를 기록
- Given, when then 형태로 정리
차이를 발생시키는 다양한 원인 탐색
추상적이든 구체적이든 떠오르는대로 적어보기
도메인 경험이 많을수록 첫번째 옵션이 진실일 가능성이 높으나, 주니어는 훈련을 위해서라도 3개 정도는 적어보는게 좋음
가설 설정 및 검증
- 옵션을 ‘검증 가능한 가설’ 형태로 문장화
- 실제로 작은 변경을 가하면서 가설대로 현상이 변하는지 관찰(이 과정에서 다른 문제가 발생된다면 1단계부터 재시작)
- 가설이 틀렸다면 무엇 때문인지 적어보고 다음 가설로 넘어감
사후 해결법 설계, ROI 파악, 우선순위 결정 등 정리하는 것이 중요하다.
디버깅 고수들 의 도구는 마인드셋이 가장 중요했다.
크롬 디버거를 잘 활용하면 꽤 괜찮은 경험을 할 수 있다.
Google 교육 자료를 신청해서 들어보면 도움이 된다.
고수의 습관
TDD
Toilet Driven Development
DDD
Description Driven Development
커밋은 나중에 찾아보기 위한 것, PR은 리뷰를 하는 사람을 위한 것
IDD
Issue Driven Development
최소 재현 코드를 먼저 만들고, 다음작업을 만들어가는 방석이 많다고 함
내용은 결국 훔치기 기술 이전에 읽었던 책 내용임
- 인류가 되는
세번째 세션
사이드 프로젝트로 커리어 레벨업!
조현우
하이퍼커넥트
https://www.inflearn.com/conf/infcon-2024/session-detail/876/
관심 있는 분야에 연관된 프로젝트를 사이드 프로젝트로 진행했다.
포지션 연계
내가 원하는 포지션으로 옮겨갈 수 있도록 사이드 프로젝트를 이용해서 기술 역량을 키워서 이직을 진행함
사이드 프로젝트 포트폴리오
gitbook을 이용해서 이력서, 경력기술서 등을 정ㄹ리 해봄
사이드 프로젝트 잘하는 방법
크기를 2~3일 내에 끝낼 수 있는 규모가 좋다.
중요한건 몰입
시작한 프로젝트를 끝내는 것이 중요했기 때문에 규모를 조정한다.
일정은 개인차가 있으니, 알아서 조절
관심 있는 분야에 맞춰서 간단한 프로젝트를 진행함
몰입이 중요한데, 이걸 잘 끝내기 위해서는 흥미가 유지될 수 있어야 한다고 생각한다.
(너무 의미 있는걸 할려고 했낭..)
사이드 프로젝트 진행시 안써봤던 기술은 딱 1개만 도입하자
비용을 아까워하지말자
비용 측정을 하는데 도움이 됨
돈을 써봐야 ㅋㅋ
이왕 할 거라면
팀 프로젝트 «** 개인 프로젝트**
일단 해보쟈
———————————————————————
세션 4
목적 조직 구조 안에서 개발팀이 일하는 법
김경백, 신유나, 오준상, 이재석, 이동욱(모더레이터)
인프랩 패널토크
https://www.inflearn.com/conf/infcon-2024/session-detail/904/
기존에 기능 조직으로 조직되었다. 디자인, 개발, 프론트 등등
최근에는 목적조직으로 진행하는 것이라 생각한다.
목적조직을 구성하고 나서 혼란한 상황을 해소한 내용을 공유한다.
목적조직
PM
Design
Backend
Frontend
목적조직을 cell이라고 한다.
같은 직군끼리는 Part로 되어 있다.
Cell에서 비즈니스 성과
Part에서 기술적 성장
Code gen 이라는 걸 이용해서 api 응답을 만들어주는 것이 있다.
MSW라는 api mocking 라이브러리가 있다.
https://oliveyoung.tech/blog/2024-01-23/msw-frontend/
https://www.daleseo.com/mock-service-worker/
API 스펙을 정하는 방법
기획 문서 기반으로 API를 도출, confluence로 작성해둠
이걸 기반으로 FE팀에 전달
이후에는 스웨거를 통해서 전달 함
기술 용어들을 어려워하는 경우 어떻게 진행하는가?
프로젝트 회고시 점검해봤는데 큰 이슈가 없었다.
주 2회 직군별 미팅 진행
- 이슈 되었던 상황 공유
- 공유할만한 내용 공유
세션5
클린 스프링: 스프링 개발자를 위한 클린코드 전략
이일민(토비)
Epril
https://www.inflearn.com/conf/infcon-2024/session-detail/880/
기술을 통한 성장
이게 인프콘의 주제라고 함
클린코드
이걸 하면 구현 능력이 떨어지고, 구현 속도가 떨어진다??
클린 코드나 DDD 나 이런 걸 이력서에 작성하면 주의 딱지를 붙인다고 함 ㅋㅋ
클린 스프링
작동하지 않는 클린 코드?
- 클린 코드를 추구해서 주석을 작성하지 않음
- 코드가 클린하면 리팩터링 할 이유가 없다
- 클린 코드는 버그가 적어서 테스트 코드가 없어도 되지 않나?
- 클린 코드를 작성해야되서 일정이 부족하다.
- 클린 코드 원칙에 위배되어서 리뷰를 승인할 수 없습니다.
개웃기네 진짜 ㅋㅋㅋ
클린코드가 강조하는 것
- 읽기 좋은 코드
- 이해하기 좋은 코드
- 확장하기 좋은 코드
- 유지보수하기 좋은 코드
유지보수성(maintainability)
결국 이게 핵심이지
클린 아키텍처
- 품질에 관한 요구사항(비 기능적 요구사항)에서 유지보수성은 특별하다.
- 유지보수하기 좋은 코드는 확장하기 좋고, 안전하고, 신뢰할 수 있고, 좋은 성능으로 발전시킬 수 있고, 상호 호환성이 뛰어나서 변경하기 쉽다
- 유지보수성은 코드의 변경가능성과 동의어 이다
유지보수하기 좋은 클린 코드는 개발 생산성이 떨어지는가?
-> 놉
유지보수성에 집착하면?
개발 생산성과 유지보수성은 서로 영향을 주는 관계이다.
부채 (Dept)
기술 부채
Technical Dept
부채 은유 (Dept Metaphor)
- 개발 하는 소프트웨어에 대한 현재 이해를 반영하는 코드를 작성하고 빠르게 출시
- 소프트웨어에 대해서 배우게 된 것을 리팩터링을 통해서 코드에 반영
- 그러지 않으면 이자가 쌓여서 점점 큰 부담
Ward Cunningham 최초 언급
최근 ward는 기존에 부채의 의미를 다른 것으로 오용하는 것이 있다. 고 말함
- 코드를 대충 작성하라는 게 아님
- 부채는 나쁜 코드에 대한 변경이 될 수 없음
- 처음부터 리팩터링하기 좋은 코드를 만들어야 함
부채가 지속적으로 효과를 발휘하려면 리팩터링(부채상황)이 필요하다?
유지보수성이 좋은 코드는 변경가능성이 좋다.
- 리팩터링 (클린코드 선순환)
빠르게 변경되는 코드는 개발 생산성이 좋다.
시작은 어떻게 해야 하는가?
개발 시작은 빠르고 간단하게
- 익숙한 기술로
- 핵심 기능이
- 동작하는
- 가장 단순한 코드를
- 리팩터링 하기 좋게 작성
일부 기능을 완벽하게 만드는 것으로 시작하지 마세요.
기술 아키텍처를 검증할 수 있는 버티컬 슬라이서가 있다고 하네?
유지보수성과 생산성의 균형을 잡아줄 리팩터링을 잘 하려면?
테스트!
이걸 만들어야 되는데..
그런데 테스트를 작성하면 구현 능력과 구현 속도가 또…
테스트를 빠르고 효과적으로 작성하면서 개발하는 능력이 필요
- 동의, 어려움, 가능하다고 함..
- 익숙한 기술로
- 핵심 기능이
- 동작하는
- 가장 단순한 코드를
- 리팩터링 하기 좋게 작성
누구에게??
대상이 중요하다 같이 일하는 동료 등
삼체 문제
Three Body Problem
팀워크(teamwork) 가 필요하다
유지보수성 생산성
\ / 코드 | 팀워크
클린 코드의 많은 원칙은 팀의 동료 개발자와 관련된 것이다.
나만을 위한 클린 코드는 없다.
클린 코드의 많은 원칙은 상황에 따라 다른 기준을 가지고 있다.
기준을 잡는 방법을 탐험(Exploration) 이라고 하자
팀과 함께 결정하고 탐험하고 학습하고 성장한다.
결정은 주니어가 했으면 좋겠다.
장단점과 트레이드오프를 포함해서 이야기 하면서
이런 과정을 탐험하는 과정이라고 할 수 있다.
이 과정 속에서 팀 구성원들이 배우는 점이 있었으면 한다.
함께 탐험하는 것을 즐거워 하는 팀
Great Teams make great people
친절(Kind)
교양있는 개발자
자신의 말을 하더라도 다른 사람의 기분을 나쁘지 않게 하는 것
자기의 이야기를 해야 됨, 부정적인 피드백이라도 해야 됨 다만 다른 사람의 기분을 나쁘지 않게 하는 것이다
이걸 훈련해야 함
함께 코드를 작성하고, 읽고, 변경할 동료 개발자들에게 친절한 코드
항상 친절하세요
동료에게
자신에게
클린 스프링 원칙
자기 책임에 충실한 오브젝트로 구분하고 의존관계를 유연하게
클린 (자동) 구성 정보
헥사고날 아키텍처
- 토비님은 좋아 함
계층과 모듈 경계에는 API, 즉 인터페이스를 사용
테스트를 안 만들 거면 스프링을 뭐하러?
- 정말 스프링만큼 테스트의 중요성을 알려주고 도구를 제공해주는 것이 없다.
DB 테스트에는 @Transactional을 사용!
ㅋㅋㅋㅋ
토비의 클린 스프링의 강좌를 만들려고 하신다고 함
- 강의 홍보하는 시간이 됨
- 올 가을부터 나온다고 함
클린 코드는 항상 코드에 관심을 가지고 보살피는 사람이 작성한 것처럼 보인다
나도 나중에 이렇게 재미나게 할 수 있을까 ㅋㅋ
———————
5번째 세션
객체지향은 여전히 유용한가?
조영호
지식공유자
https://www.inflearn.com/conf/infcon-2024/session-detail/881/
객체지향은 여전히 유용한가에 대해서 질문이 있다.
왜 이런 질문이 있는지 알아봄
장바구니 코드
절차적인 설계
데이터와 프로세스를 구분해서 작성하는 것이라 설명한다.
절차적인 설계와 객체지향적인 설계는 언제 사용하는가?
역할과 책임을 나눌 수 있도록,
객체지향적인 설계는 담당하고 있는 부분이 변경되면 다른 클래스들에게 영향을 주지 않는다.
객체지향의 큰 장점은 구현에 관련된 규칙을 제한할 수 있다.
기능에 대한 추가가 많은지, 규칙의 추가가 많은지에 따라 선택적으로 절차적으로 할지 객체지향적으로 할지 결정한다.
절차적인 설계
포멧 변경을 위한 데이터 변환
데이터 중심
데이터 노출
기능 추가에 유리
객체지향 설계
규칙에 기반한 상태 변경
행동 중심
데이터 캡슐화
타입 확장에 유리
조영호님꺼는 너무 졸리넹 ㅋㄷㅋㄷ
프리젠테이션 레이어는 절차적으로 작성
서비스 레이어는 절차적으로 작성
도메인 레이어는 객체지향적으로 작성
퍼시스턴스 레이어는 절차적으로 작성
객체지향은 언제 유용한가요?
적합한 컨텍스트에 맞게 이미 사용하고 있다.
어떤 기술이나 패러다임을 이야기할 때 언제 유용한지 고민 하고 학습한 다음에 필요할 때 사용해라 정도
코드의 목적과 변경의 방향성에 따라 언제 어떤 기술을 사용할지 결정하세요.
**—- **
https://www.inflearn.com/course/%EC%9D%B8%ED%94%84%EC%BD%982024-%EB%8B%A4%EC%8B%9C%EB%B3%B4%EA%B8%B0
[**[지금 무료] 인프콘 2024 다시보기 강의 인프런 - 인프런**](https://www.inflearn.com/course/%EC%9D%B8%ED%94%84%EC%BD%982024-%EB%8B%A4%EC%8B%9C%EB%B3%B4%EA%B8%B0)
인프런 성장하는 IT인들의 축제, 인프콘 2024에서 진행된 오프닝 및 발표 세션을 영상으로 다시 보실 수 있습니다., ✅ 확인해주세요이 콘텐츠는 2024년 8월 2일 금요일 진행된 인프콘 2024 발표 녹화 영상입니다. 강의 관련 질문/답변을 제공하지 않는 점 양해