감사히도 2023 인프콘에 당첨돼서 다녀왔습니다.
아래는 제가 들었던 세션을 정리한 내용입니다.
[인프콘 링크] https://www.inflearn.com/conf/infcon-2023
<코프링 프로젝트 투입 일주일 전: 주니어 개발자의 코틀린 도입 이야기>
0. 코틀린 학습 방법
- 코틀린 코리안스 kotlin koreans (http://kotlin.kr/)
- 이펙티브 코틀린 책 ( 기본 문법 숙지하고 도전 )
- 코틀린 공식 문서
- 개인기술 블로그(안드로이드)
1. 왜 코틀린인가
- 자바 대비 상대적으로 간결한 문법
- 지속적인 업데이트 및 활발한 커뮤니티
- IDE 레벨에서의 강력한 지원
- 언어 레벨에서 지원하는 다양한 기능 -> 널 세이프티
2. 코프링 도입하기
- 팀원들이 이미 여러 경로로 코프링에 노출 되어 있었음
- mock 서버에서 코프링을 사용하고 있었음
- 새로운 그렇지만 안정적인 기술 스택이라는 암묵적인 동의를 얻음
3. 도입하기 전 고려사항
ex) MVC vs web flex
Web Flex R2DBC 와 MySql 호환성 조사
R2DBC: 관계형 DB에서 리액티브 프로그래밍을 가능하게 해주는 DB 접근 API
- R2dbc driver for mysql
- 공식벤더가 관리하지 않는 서드 파티 오픈 소스 => 병목 우려
- 상대적으로 아직어린 R2dbc 프로젝트
-공식벤더에서 관리하고 있는 마리아디비 드라이버를 아이에스큐엘과 사용하기 …를 고려했으나 배보다 배꼽이 더 큰 상황
- 그래도 해 볼 수 없을까 했으나 웹플럭스가 필요할 정도로 높은 처리량이 필요하지 않을 것으로 예상
- 비즈니스를 위한 기술이 되어야 한다
4. 사용 기술
Kotest, Mockk
5. 유용한 도구
- Kotlin-logging
slf4j와 유사한 방식으로 사용 가능
- refreshVersions
그래들 프로젝트에서 사용하는 의존성 버전 관리 플로그인
의존성 버전 정보를 단일 파일에서 관리할 수 있음
-Ktlint-gradle
테스트가 통과 못하면 커밋할 수 없도록 훅걸기 가능
-Fixture Monkey
테스트 객체를 편하게 자동으로 생성해주는 라이브러리
6. 강연자의 코프링 샘플 프로젝트
https://github.com/doljae/kopring-starter
GitHub - doljae/kopring-starter
Contribute to doljae/kopring-starter development by creating an account on GitHub.
github.com
<커뮤니케이션을 잘하는 개발자의 4가지 습관>
1.개발자의 커뮤니케이션에 관심을 갖게 된 이유
좋은 개발자가 되고 싶다.
사내에 다른 직군과 협업할 수 있는 스킬을 원하는 사람들이 제일 많았음
2.’커뮤니케이션을 잘하는 개발자’가 뭐지
우선 반대로 커뮤니케이션이 안되는 개발자란
오늘도 개발자가 안 된다고 말했다.. 라는 책이 있음
이유를 말해야하는데 개발 구조상 그냥 안된다고 해서 그런듯
화면 로그 정의 전달드립니다
=> 이건 스트림에서 비동기로 받아오는 거라서
에이피아이 구조를 바꾸지 않으면 안돼요
라고 대답함
=>스펙을 구현하는게 자기 일이라고 정의하기 때문이다.
그럼 커뮤니케이션을 잘하는 개발자는?
안된다 라는 말을 그냥 하지 않는다
버튼 옮기는 건 어떤 문제를 풀려고 하는 걸까요?
버튼을 옮기는 건 ~~한 이유때문에 어려우니,
~~한 방법은 어떠세요? =>문제 해결형 개발자
3. 변화를 만들려면 습관이 필요하다.
문제 해결형 개발자가 되려면 어떻게 해야하지?
아는 것 만으로는 충분하지 않다
앉는 자세와 같은 습관이라서
첫째, 해결하는 문제와 의도에 대해 묻는다
둘째, 상대방의 말을 듣고 내가 이해한 바를 공유한다
셋째, 안 된다고 말할 때는 상대방의 관점에서 대안을 제시한다.
대부분 상대방이 궁극적으로 원하는 것은 왜 기술적으로 어려운지 이해하는게 아니다.
넷째, 문제를 해결할 또 다른 방법은 없을지 고민해 본다.
예시) 회원 인증을 하는 데 14초 로딩,
이걸 단축 시키긴 위해서 6개월 동안 작업을 해야했음
그래서 다음 단계를 실행시키고 백그라운드로 인증을 진행함.
<어느 날 고민 많은 주니어 개발자가 찾아왔다 2탄: 주니어 시절 성장과 고민들>
1.개발에 대해서
기술 공부를 안하는 개발자
- 기술적인 근본 원인을 파악해서 문제 해결 어려움
-기술에 대한 깊은 이해 없이 개발 업무 반복
- 팀에서 동작하는 코드를 보고 이렇게 비슷하게 짜면 되는구나!
기술 트렌드 찍먹 개발자
- 기술 공부를 하기는 하는데...
-팀에서 사용하는 기술도 제대로 이해하지 못한 상태
- 새로운 기술을 도입하자고 한다면?
-기술의 깊이가 만들어지기 어렵다
팀 기술을 잘 이해하는 개발자
- 팀에서 사용하는 기술 역량을 잘 쌓아둠
- 기술을 잘 이해해서 팀 업무를 원할하게 진행
-팀에 기술 문제가 발생했을 때 원인을 정확히 파악해서 해결
-신뢰와 기술 포인트
-팀에서 점점 중요한 업무를 맡게 됨
- 결과적으로 평가와 연봉에 반영
팀기술의 장점
-동기부여: 사람은 당장 본인에게 필요한 것을 더 빠르게 학습
-학습 사이클: 학습-> 업무에 학습한 내용을 활용 -> 활용하면서 고민되는 부분 학습 -> ..., 이론과 실습의 완벽한 조화
기술을 학습한다는 것
-기술을 업무에 사용할 줄 안다고 그 기술을 잘 아는 것은 아니다. 1년 차의 경험 10번 반복
- 기술의 기본 원리를 이해하고 깊이있게 학습
- 그 기술이 왜 필요한지 이해
- 해당 기술을 사용해서 밑바닥부터 스스로 학습
- 문제가 발생했을 때 해당 기술에 대한 해결사 역할
경기와 훈련
-운동 선수가 평소에 훈련하지 않느다면?
-개발자도 꾸준한 훈련의 시간이 필요하다.
- 경기 = 회사업무
- 훈련 = 업무 외 학습의 시간
2. 비즈니스의 이해
-비즈니스와 개발이 어떻게 연결되어 있는지 이해하는 큰 지도를 그리는 것
큰지도 만들기
비즈니스 이해
- 인터뷰: 비즈니스에 대해서 듣고 이해하라, 기획자, 팀장, 문서 등등
- 어드민의 기능 하나하나 다 사용하기 + 사용자의 기능 사용해보기
비즈니스의 구현 이해
- 데이터: 핵심 테이블(엔티티), 핵심 필드 정리
- 핵심 업무 프로세스 정리
비즈니스 이해가 약한 개발자
-큰 그림에서 전체 상황을 이해하지 못함
- 지도가 없으므로 어디까지 질문해야 할 지를 잘 모름
- 작업의 영향 범위가 어디까지 영향을 미치는지 파악이 어려움
- 요구사항을 제대로 처리하지 못함
- 중요한 메인 업무가 있을 때, 영향 범위를 잘 모르기 때문에 실패 할 가능성이 높음
- 더 큰 업무를 맡기기는 어려움
좋은 시스템을 설계하려면?
- 개발을 잘 하기 위해서는 비즈니스 이해가 필수
- 비즈니스를 이해해야 좋은 아키텍처 설계 가능
- 애플리케이션 아키텍처의 선택은 변경 가능성의 영향이 큼
- 그런데 이게 변할지 안 변할지 선택이 필요 - 비즈니스를 알아야 가능
WHY
-근본적인 이유를 알아야 본질적인 답을 찾을 수 있다.
- 기술이든 비즈니스든, 근본적인 이유를 알아야 올바른 대안을 찾을 수 있다.
- 동기부여, 기술역량성장, 제대로 된 비즈니스 이해, 제대로 된 기술 검증
커뮤니케이션
공격조심, 기획자에게, 개발자에게
"고민이 있습니다"라고 서두 꺼내기
내가 리더라면
-리더는 백번 질문해도 백번 대답할 준비가 되어 있어야 한다.
- 왜 이 일을 해야 하는지 잘 풀어서 설명(내가 알고 있는 문맥의 양과 상대의 문맥 양을 확연히 다르다.)
- 팀장만 리더가 아니다. 모두가 리더다.
-기술, 비즈니스 모두
성장과 환경
좋은 환경
안좋은 환경
지금 좋다기 보다는 일하기 좋은 방향으로 바꾸어 나가려고 노력하는 조직
마치면서
조민규 님의 <우리는 이렇게 모듈을 나눴어요> 세션도 들었지만 시간 남을 때 학습하면서 정리하고 싶어서 남겨두도록 하겠습니다.
처음으로 오프라인 컨퍼런스를 가 봤는데 북적북적하고 좋더라고요.
개발자들 보면서 동기부여도 받고!
제일 좋은 점은 qna를 직접 실시간으로 할 수 있다는 점인데, 저는 코린이라서 질문을 찾지 못 했습니다..
열심히 학습해야겠다고 다시금 결심할 수 있는 좋은 경험이였습니다.
내년에는 더 성장해서 갈 수 있길 바라며 마치도록 해 보겠습니다.
감사합니다.
'컨퍼런스' 카테고리의 다른 글
| 2022 프로그래머스 컨퍼런스 (2) | 2022.11.27 |
|---|