프로젝트 리뷰

: 데이터 설계의 중요성

• 데이터의 설계가 코드의 설계를 좌우함
• 포트폴리오, 면접에서 어필하기 좋은 포인트(BE 개발)

: 코드 구조 및 설계

• 코드를 작성하는 것보다 중요
• 코드를 작성하는 개발자보다 하나의 구조물을 만들어가는 개발자

: 프로젝트 일정

• 일정 준수
• 현업에서의 일정이란

: 테스트 코드

• 사용자에 대한 최소한의 예의
• 자동화를 통한 리소스 절감

: 더 나은 방향

• 서비스 측면의 고민
• 기술적 측면보다 사용성 측면을 고려

---

확장

: Advanced

• 현재의 프로젝트를 확장
• 범위를 키웠을 때 현재 설계/구조가 이슈가 되는 부분
• 확장성을 가진 개발

: 도서관 어드민

• 도서/사용자를 관리
• 도서 카테고리, 재고 수량 관리
• 사용자 관리(탈퇴, 중복, 재가입 등의 처리)

: 도서관 통합 관리

• 도서관 별 관리 X
• 하나의 시스템 안에 도서관으로 분류
• 사용자 통합, 도서 관리 통합

: 글로벌 도서관 체인

• 서비스 구성에 차이?
• 인프라 구성(API 서버, DB 서버, FE 처리)

---

백엔드 개발자와 인프라

: 개발자가 인프라도?

• 개발자의 역할범위가 어디냐에 대한 논쟁은 여전히 지속 중
• 개발자 또한 서비스를 만드는 사람이라는 마인드가 중요
• 코딩 능력도 중요하지만 더 중요한 것은 서비스 구성 능력
• 인프라를 설계하는 것이 개발자 커리어에 많은 도움

+. 지표: TPS, DB관련: 조회, READ&WRITE

---

포트폴리오

: 필수

• 제목, 개요(간략 설명), 기술 스택, 기간, 역할(비중)
• 어필 포인트
• 스토리

: 고려사항

• 기술 자랑 X
• 생각 & 고민
• 어려웠던 부분 & 해결 & 반전

: with 미니 프로젝트

• 도서관리 API 프로젝트
  : 도서관 이용자가 도서를 조회하고 대출/반납 처리하도록 하는 API 서버 개발
  사용기술 : Java, Spring Boot, JPA, JUnit, DB-MySQL
  기간 : 5일
  역할 : 프로젝트 기획/설계/개발/테스트 100%

• (DB) 사용자가 도서를 대출하는 액션에 대해서 사용자/도서 테이블 간의 N:N 관계 해소를 위해 대출이력 테입즐 추가 생성 -> DB 스키마

• (구조) exception에 대해서 사용자/시스템 측면의 에러 발생을 공통 처리 -> Class 다이어그램

• (테스트) JUnit을 통한 테스트 코드 작성, 최소한의 품질 보장 -> 테스트 코드 구성(세분화 된 코드)

: with 미니 프로젝트 + 확장

• DB, 코드 구조, 테스트에 대한 기본적인 정리로 지원자가 어떤 부분에 초점을 맞추고 있는지 어필

• 프로젝트 마다 중점적으로 어필할 부분을 달리하여 하나의 큰 그림을 완성

• BE 개발자에게 기대하는 항목(코드 설계, DB, 인프라, + 개발)

• 도서관 통합, 도서관 어드민, 글로벌 체인 구성
  => 실제 개발을 하면 더 좋지만, 개발을 하지 않았더라도 이러한 부분들에 대한 간략한 언급

---

포트폴리오 + 면접

: 포트폴리오 확인의 시간

• 모든 프로젝트를 포트폴리오에 넣지 X
• 면접은 포트폴리오 확인
• 작성한 프로젝트, 기술에 대해서는 명확히 인지
• CS지식

: 성장가능성

• 현재의 수준보다 중요한 부분
• 면접의 태도(모른다와 알고자 하는 것)
• 배움과 열정

---

개발자 성장

: 성장하고자 한다면

• 서비스를 생각하는 개발자
• 배우는 습관
• 글쓰기
• 환경
• 투자

: 서비스를 생각하는 개발자

• 개발자로서의 고집 내려놓기
• 대의(?)를 생각하기
• 나와 다른 생각에 귀를 기울이기

: 글쓰기

• 생각의 정리
• 나에게 남기는 각인
• 코드도 글쓰기

: 투자

• Output은 Input이 있어야 가능
• 무엇을? 어떻게?

---

Wrap up

누구나 개발자가 될 수 있다.

어떤 개발자로 남느냐...