• https://www.toptal.com/developers/gitignore
• 위 사이트에서 아래와 같이 옵션들을 추가한 뒤 생성을 클릭한다.

• 그럼 아래와 같은 gitignore 파일이 생성된다. 복사해서 본인의 gitignore에 추가하면 끝 ! 

• 아래는 이번 프로젝트때 내가 사용한 gitignore 파일 이다 : ) 

application-local.properties

# intelliJ
HELP.md
.gradle
.idea
build/
!gradle/wrapper/gradle-wrapper.jar
!**/src/main/**/build/
!**/src/test/**/build/

# User-specific stuff
.idea/**/workspace.xml
.idea/**/tasks.xml
.idea/**/usage.statistics.xml
.idea/**/dictionaries
.idea/**/shelf

# AWS User-specific
.idea/**/aws.xml

# Generated files
.idea/**/contentModel.xml

# Sensitive or high-churn files
.idea/**/dataSources/
.idea/**/dataSources.ids
.idea/**/dataSources.local.xml
.idea/**/sqlDataSources.xml
.idea/**/dynamic.xml
.idea/**/uiDesigner.xml
.idea/**/dbnavigator.xml

# Gradle
.idea/**/gradle.xml
.idea/**/libraries

# Gradle and Maven with auto-import
# When using Gradle or Maven with auto-import, you should exclude module files,
# since they will be recreated, and may cause churn.  Uncomment if using
# auto-import.
# .idea/artifacts
# .idea/compiler.xml
# .idea/jarRepositories.xml
# .idea/modules.xml
# .idea/*.iml
# .idea/modules
# *.iml
# *.ipr

# CMake
cmake-build-*/

# Mongo Explorer plugin
.idea/**/mongoSettings.xml

# File-based project format
*.iws

# IntelliJ
out/

# mpeltonen/sbt-idea plugin
.idea_modules/

# JIRA plugin
atlassian-ide-plugin.xml

# Cursive Clojure plugin
.idea/replstate.xml

# SonarLint plugin
.idea/sonarlint/

# Crashlytics plugin (for Android Studio and IntelliJ)
com_crashlytics_export_strings.xml
crashlytics.properties
crashlytics-build.properties
fabric.properties

# Editor-based Rest Client
.idea/httpRequests

# Android studio 3.1+ serialized cache file
.idea/caches/build_file_checksums.ser

### Intellij Patch ###
# Comment Reason: https://github.com/joeblau/gitignore.io/issues/186#issuecomment-215987721

# *.iml
# modules.xml
# .idea/misc.xml
# *.ipr

# Sonarlint plugin
# https://plugins.jetbrains.com/plugin/7973-sonarlint
.idea/**/sonarlint/

# SonarQube Plugin
# https://plugins.jetbrains.com/plugin/7238-sonarqube-community-plugin
.idea/**/sonarIssues.xml

# Markdown Navigator plugin
# https://plugins.jetbrains.com/plugin/7896-markdown-navigator-enhanced
.idea/**/markdown-navigator.xml
.idea/**/markdown-navigator-enh.xml
.idea/**/markdown-navigator/

# Cache file creation bug
# See https://youtrack.jetbrains.com/issue/JBR-2257
.idea/$CACHE_FILE$

# CodeStream plugin
# https://plugins.jetbrains.com/plugin/12206-codestream
.idea/codestream.xml

# Azure Toolkit for IntelliJ plugin
# https://plugins.jetbrains.com/plugin/8053-azure-toolkit-for-intellij
.idea/**/azureSettings.xml

### Java ###
# Compiled class file
*.class

# Log file
*.log

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
replay_pid*

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

### Windows ###
# Windows thumbnail cache files
Thumbs.db
Thumbs.db:encryptable
ehthumbs.db
ehthumbs_vista.db

# Dump file
*.stackdump

# Folder config file
[Dd]esktop.ini

# Recycle Bin used on file shares
$RECYCLE.BIN/

# Windows Installer files
*.cab
*.msi
*.msix
*.msm
*.msp

# Windows shortcuts
*.lnk

https://www.toptal.com/developers/gitignore

https://niceman.tistory.com/114

갑자기 팀원분이 하차하면서 어떤 곳에서 개발을 잘 배울 수 있을까 라는 의문이 들었다. 물론 항해99도 스스로 공부하는 법을 배우기에 나쁜 곳은 아니지만, 아무래도 제로베이스가 따라가기엔 너무 빠르고 벅차다고 느낄 수 있기 때문에, 개발을 시작하시는 분들이 좀 더 긴 시간동안 상주해있는 선생님과 함께 배울 수 있는 국비지원 학원을 적어보고자 한다. ( 출처는 미경님 정보 ^^) 

플러스 기술매니저님이 조언해주신 개발에 대한 태도를 정리해 보려 한다.

서울 국비지원 유명 3 곳

1. 비트캠프

https://www.bitcamp.co.kr/

2. 쌍용교육센터

https://www.sist.co.kr/index.jsp

3. KH정보교육원

https://iei.or.kr/main/main.kh

※ 출처 : 꼼꼼한 미경님

개발의 태도

1. 개발자 커뮤니티를 이용하자 - 사이드 프로젝트 최신 기술 등등을 파악 할 수 있다.

2. 좋은 공부습관 갖기 

• 좋은 공부 법 : 지금 알아야 할 부분을 구글링 할 때, 끝도 없이 팔 것이 아니라 필요한 정도까지 알고 배우는 법을 알아야 한다.
• 잘 받아들이는 습관이 중요 !  개발은 정답이 없기 때문에 회사 마다 방법이 다르고 개발법이 바뀔 수 있다. 따라서 새로운게 나왔을때 이방법이 맞네 저방법이 맞네 하면서 재미를 느껴야 한다. 호기심 생겨야하고 그런 자세가 중요.
• 정답이 없기 때문에, 스트레스 받지 않고 그냥 받아드리면서 공부하는게 중요.
• 안되거나 자꾸 오류가 뜨면 코드 한줄씩 보면서 고쳐보자 (디버깅)
• 프로그래밍은 암기력이 중요한게 아니라 문제해결력이 중요 ! 따라서 구글링을 통한 자료를 적재적소에 사용하는 게 중요하다.

🔐 스프링 시큐리티를 사용해 회원관리하는 방법을 순서도를 통해 정리해 보세요. 

<회원 가입>

1. Client -> Server : 회원가입에 필요한 정보 (username, password, email 등)

2. Server (회원가입 처리)

• 중복 회원 ID 확인
• 패스워드 암호화
• 회원 역할 설정 (USER, ADMIN)

3. Server -> DB : 회원정보 DB 에 저장

< 로그인 >

1. Client → Server : 로그인에 필요한 정보 (username, password)
2. Server (로그인 처리)
   
   • 회원 DB 에서 username 을 가진 회원정보 가져옴 (회원 정보가 없으면 에러 발생)
   • 회원 DB 의 username, password 와 Client 에서 전달받은 username, password 가 동일한지 비교
3. Server → Session : 로그인 성공 시 Session 에 저장
4. Server → Client : Session 쿠키 전달 (JSESSIONID)
5. Client : Session 쿠키 저장

< 로그인 이후 로그인 상태 유지 방법 >

• Client 에서 Server 에 API 요청할때마다 Session 쿠키를 전달

🔐 단위 테스트 코드 작성 시 장/단점을 정리해 보세요.

< 단위 테스트란? >

• 프로그램을 작은 단위로 쪼개서 각 단위가 정확하게 동작하는지 검사하고 이를 통해 문제 발생 시 정확하게 어느 부분이 잘못되었는지를 재빨리 확인할 수 있게 해준다.  
  1. 장점
     • 예상 동작과 실제 동작을 비교하여 빠르고 정확한 테스트가 가능하기 때문에 초기 개발의 디버깅이 쉬워집니다.
     • 어플리케이션이 변경(기능 확장 또는 리팩터링 등)되더라도 올바르게 작동하는 지 확인할 수 있습니다.
     • 단위 테스트 자체를 어플리케이션에 대한 문서로 사용할 수 있다. 특히 잘 만든 테스트 케이스는 API 기능을 쉽게 파악할 수 있도록 도와줍니다.
     • 여러 빌드 도구들(maven, gradle 등)은 테스트 자동화 기능을 포함하고 있습니다.
  2. 단점
     • 테스트 코드까지 작성해야하기 때문에 개발 시간이 오래 걸리게 됩니다.
     • 어플리케이션 변경 사항을 테스트 코드에도 적용해야 하기 때문에 테스트 코드를 유지보수하는 비용이 든다.

🔐 AOP(Aspect Oriented Programming)란 무엇인가?

• AOP는 스프링의 가장 중요한 세 가지 특징인 IoC(제어의 역전), DI(의존성 삽입), AOP(관점 지향 프로그래밍)중 하나. 관점 지향 프로그래밍은 흩어진 Aspect를 모듈화 할 수 있는 프로그래밍 기법.
• 관점 지향은 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어 본다는 말이고 따라서 관점을 기준으로 각각 모듈화하는 프로그래밍 기법
  • 핵심기능 : 각 API 별 수행해야 할 비즈니스 로직  ex) 상품 키워드 검색, 관심상품 등록, 회원 가입, 관심상품에 폴더 추가 등 ....
  • 부가기능 : 핵심기능을 보조하는 기능 ex) 데이터베이스 연결, 파일 입출력, 회원 패턴 분석을 위한 로그 기록, API 수행시간 저장 등
  • 모듈화 : 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것
• AOP는 OOP를 대신하는 새로운 개념이 아니라, 기존 OOP를 더욱 보완, 확장하여 OOP를 OOP답게 사용할 수 있도록 도와주는 개념 (OOP(Object-oriented Programming란 객체 지향 프로그래밍)과 나란히 하는, 서로 보완관계에 있는 기술)

🔐 @Transactional이란 무엇인가?

• 여러 작업을 진행하다가 문제가 생겼을 경우 이전 상태로 롤백하기 위해 사용되는 것이 트랜잭션(Transaction) 이다.
• 트랜잭션은 더 이상 쪼갤 수 없는 최소 작업 단위를 의미한다. 그래서 트랜잭션은 commit으로 성공 하거나 rollback으로 실패 이후 취소되어야 한다. 하지만 모든 트랜잭션이 동일한 것은 아니고 속성에 따라 동작 방식을 다르게 해줄 수 있다.
• 위에서 설명한 것과 마찬가지로 트랜잭션의 마무리 작업으로는 크게 2가지가 있다.
  • 트랜잭션 커밋: 작업이 마무리 됨
  • 트랜잭션 롤백: 작업을 취소하고 이전의 상태로 돌림
• 만약 여러 작업이 모두 마무리 되었다면 트랜잭션 커밋을 통해 작업이 마무리되었음을 알려주어 반영해야 하며, 만약 문제가 생겼다면 작업 취소를 위해 트랜잭션 롤백 처리를 해주어야 한다.

🔐 WAS란 무엇인가? Web Server와 차이점은 무엇인가?

Web Server

• 하드웨어 : Web 서버가 설치되어 있는 컴퓨터
• 소프트웨어 : 웹 브라우저 클라이언트로부터 HTTP 요청을 받아 정적인 컨텐츠(.html .jpeg .css 등)를 제공하는 컴퓨터 프로그
• Web Server의 기능 : HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스 하는 기능을 담당한다. 요청에 따라 아래의 두 가지 기능 중 적절하게 선택하여 수행한다.
  • 정적인 컨텐츠 제공 : WAS를 거치지 않고 바로 자원을 제공한다.
  • 동적인 컨텐츠 제공을 위한 요청 전달 : 클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다. 클라이언트는 일반적으로 웹 브라우저를 의미한다. Web Server의 예 Ex) Apache Server, Nginx, IIS(Windows 전용 Web 서버) 등

WAS

WAS의 개념

• DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)이다.
• “웹 컨테이너(Web Container)” 혹은 “서블릿 컨테이너(Servlet Container)”라고도 불린다.
• Container란 JSP, Servlet을 실행시킬 수 있는 소프트웨어를 말한다. 즉, WAS는 JSP, Servlet 구동 환경을 제공한다.

WAS의 역할

• WAS = Web Server + Web Container Web Server 기능들을 구조적으로 분리하여 처리하고자하는 목적으로 제시되었다.
• 분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용된다.
• 주로 DB 서버와 같이 수행된다.
• 현재는 WAS가 가지고 있는 Web Server도 정적인 컨텐츠를 처리하는 데 있어서 성능상 큰 차이가 없다.

WAS의 주요 기능

• 프로그램 실행 환경과 DB 접속 기능 제공
• 여러 개의 트랜잭션(논리적인 작업 단위) 관리 기능
• 업무를 처리하는 비즈니스 로직 수행
• WAS의 예 Ex) Tomcat, JBoss, Jeus, Web Sphere 등

Q1. JPA 연관관계 매핑

• JPA에서 객체와 관계형 데이터베이스 테이블이 어떻게 매핑되는지를 이해하는 것은 매우 중요! JPA의 목적인 객체 지향 프로그래밍과 데이터베이스 사이의 패러다임 불일치를 해결이라는 것과 가장 직접적으로 연관되어 있기 때문.
• 연관 관계 매핑은 비즈니스 로직, 비즈니스 요구사항에 따라 개발자가 적절한 관계 설정 방법을 선택해야 함
• 연관 관계 매핑시 고려사항
  • 1.방향 : 단방향, 양방향 (객체 참조)
  • 2.연관 관계의 주인 : 양방향일 때, 연관 관계에서 관리 주체
  • 3.다중성 : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M)

 Q2. 순환참조 정의/이유/해결방법

<순환참조 정의>

• 서로 다른 두 개의 클래스가 서로 참조하고 있는 상태를 말한다.
• JPA 순환 참조는 1:N , N:1, 양방향 관계에서 일어날 수 있다.

<순환참조 이유>

• 스프링에서 DI를 통해 생성자 주입을 할 경우 순환 참조 문제가 발생할 수 있다.
• 생성자 주입은 객체를 생성할 때 주입되기 때문에 객체가 반드시 존재해야 한다.
• A가 B에 의존하고 B가 C에 의존한다면
• A -> B -> C
• 스프링 컨테이너는 C -B - A 순으로 객체를 생성하게 됩니다.
• 그러나 A가 B에 의존하고 B가 A에 의존적이라면 어떠한 객체를 먼저 만들어야 하는지 문제가 생깁니다.

<해결 방법>

@jsonignore (지양함)

• 간단하게 순환참조를 해결할 수 있지만, 연관관계 복잡하게 얽혀있으면 문제가 많음 (사용해야할 떄, 사용하지 못하기도 함)
• 어노테이션이 붙은 객체를 Json 직렬화를 하지 않음

DTO (지향)

• 무한 순환 참조는 객체를 JSON 형태로 변환하는 직렬화 과정에서 발생
• JSON으로 직렬화 할 객체에 연관 관계의 필드를 넣지 않음으로 문제 해결 가능
• 즉, DTO에, 필요한 필드만 만들어서 담아, 순환참조가 일어나지 않도록 하자

 Q3. Exception 예외처리를 따로 다루는 이유?

1. 웹 어플리케이션에서의 에러를 프론트엔드와 백엔드 모두가 잘 알지 못하면, 서비스하는 환경에서 발생하는 에러에 대해서 제대로 대응 할 수 없습니다.
2. 에러를 처리하는 것 역시 관심사를 분리해서 더 효율적으로 처리 할 수 있지 않을까 고민해보는 시간이 필요해서 입니다.

 Q4. Spring Security 동작 원리

일반적인 Form Login 절차

 1. 요청 수신

• 사용자가 form을 통해 로그인 정보가 담긴 Request를 보낸다.

2. 토큰 생성

• AuthenticationFilter가 요청을 받아서 UsernamePasswordAuthenticationToken토큰(인증용 객체)을 생성
• UsernamePasswordAuthenticationToken은 해당 요청을 처리할 수 있는 Provider을 찾는데 사용

3. AuthenticationFilter로 부터 인증용 객체를 전달 받는다.

• Authentication Manager에게 처리 위임
• Authentication Manager는 List형태로 Provider들을 갖고 있다.

4. Token을 처리할 수 있는 Authentication Provider 선택

• 실제 인증을 할 AuthenticationProvider에게 인증용 객체를 다시 전달한다.

5. 인증 절차

• 인증 절차가 시작되면 AuthenticationProvider 인터페이스가 실행되고 DB에 있는 사용자의 정보와 화면에서 입력한 로그인 정보를 비교

6. UserDetailsService의 loadUserByUsername메소드 수행

• AuthenticationProvider 인터페이스에서는 authenticate() 메소드를 오버라이딩 하게 되는데 이 메소드의 파라미터인 인증용 객체로 화면에서 입력한 로그인 정보를 가져올 수 있다.

7. AuthenticationProvider 인터페이스에서 DB에 있는 사용자의 정보를 가져오려면, UserDetailsService 인터페이스를 사용한다.

8. UserDetailsService 인터페이스는 화면에서 입력한 사용자의 username으로 loadUserByUsername() 메소드를 호출하여 DB에 있는 사용자의 정보를 UserDetails 형으로 가져온다. 만약 사용자가 존재하지 않으면 예외를 던진다. 이렇게 DB에서 가져온 이용자의 정보와 화면에서 입력한 로그인 정보를 비교하게 되고, 일치하면 Authentication 참조를 리턴하고, 일치 하지 않으면 예외를 던진다.

9. 인증이 완료되면 사용자 정보를 가진 Authentication 객체를 SecurityContextHolder에 담은 이후 AuthenticationSuccessHandle를 실행한다.(실패시 AuthenticationFailureHandler를 실행한다.)

 Q5. TDD란?

TDD란? Test-Driven Development의 약자

• 테스트 코드를 먼저 작성하고 실제 동작하는 코드를 개발하는 순서로 개발하는 개발 방법론
• 설계 → 개발 → 테스트에서
• 설계 → 테스트 → 개발 순서로 하는 것을 말함

 Q6. 싱글톤 사용 이유

• 변경되면 안되는 사항 예를 들면 암호화된 비밀번호, 같은 객체가 변하면 안되기 때문에 선언해야한다. 
• 스프링 구조 자체가, 스프링 컨테이너에 내부 빈으로 등록하다는 것 자체가 싱글톤으로 등록 된다는 것.
• -> 스프링 컨테이너, 빈을 공부하자

이번주는 미경님과 유리님과 한 조가 되서 다른것 걱정없이 코딩에만 집중할 수 있는 한 주 였다.

비전공자에 제로베이스인 우리 셋이 팀이라 오류가 터질때마다 사실 백지장을 맞들면서 해결해야 했기에 다른 팀들보다 더 힘들었을 수 있었는데, 서로 도와주려하고 우리 나름의 방식대로 코드의 흐름을 이해하려 노력한 한 주라 지금까지 항해99 기간 중에 가장 기억에 남을 주간이 될 것 같다. 같이 팀원이 되어주셔서 너무 감사하다는 말을 미경님과 유리님한테 전하며 마지막 정리하는 글을 작성해 보려 한다. 

1. 회원 탈퇴 인가 부분 (config)

일단 과제2에 구현해야 할 부분은 완성이 되어서 추가로 회원탈퇴 기능 구현을 시도했다.

회원 탈퇴는 토큰값이 유효하거나 관리자만 할 수 있도록 코드를 작성했는데, 다른 회원으로 로그인을 해도 탈퇴를 시킬 수 있는 오류가 발생했다. 이 부분은 미경님의 예리한 눈으로 문제점을 발견했는데 바로 config 클래스의 인가부분에서 아래와 같이 모든 "/api/user/**" URL 이 permit 받았기 때문이다. 참고로 회원 탈퇴의 경로가 "/api/user/delete/{id}" 로 되어있었기 때문에 이런 오류가 발생하였다.

위의 코드를 아래와 같이 세부적으로 "/api/user/login", "/api/user/signup" 만 permit 되도록 설정해주었더니 오류 해결 !

2. Github merge 왜 안되지?

① 상황

우리조는 각자 기능 파트를 맡긴 했지만, ( 유리님 - 댓글 CRUD , 미경님 - 게시글 CRUD / 예외처리,  나 - 댓글/게시글 좋아요 + 회원탈퇴 ) 어쨌든 모든 기능을 각장 구현해보고 싶은 마음에 각자의 파일로 작업을 하고 있었다. 과제제출 마지막날 부랴부랴 깃헙을 합치려고 했더니 세명의 파일이 모두 달라서 머지를 하면 다른 사람의 파일이 원래 올려진 파일을 통째로 덮어버리는 상황이 발생했다. 

② 문제 발생 이유

깃헙에 대한 지식이 무지했기 때문에, 먼저 root 파일을 만들고 그걸 clone받은 후에 작업을 해야 merge 하는 과정에서 한 파일이 될 수 있다는 것을 몰랐다.

③ 해결 방법

일단 다시 처음부터 root 파일을 만들고 시작하기엔 시간이 너무 없었기 때문에 일단 내가 만든 전체 파일을 미경님이 clone 받고, 거기에 미경님이 예외처리 부분을 다시 덧붙여서 업로드 하는 방안으로 제출을 완료했다.

이번에 깃헙으로 협업하는 연습까지 했으면 너무 좋았겠지만, 우리는 일단 각자 CRUD를 더 견고히 해보자는 생각으로 코드구현에 더 신경을 썼다. 그래서 이슈를 생성하고 PR을 날리는 그러한 작업은 하지 못한 아쉬움이 있다. 다음 프로젝트에는 깃헙으로 협업하는 연습을 해야겠다고 생각 

3. 추가로 수정해야할 부분 (시간상 해결 못함)

반환타입을 아래와 같이 ResponseEntity<MsgResponseDto>로 통일했더니 위와 같이 모든 게시글에 mgs : "성공"이 반환된다. 설계대로라면 이 메시지가 모든 게시글에 뜰게 아니라 게시글 리스트 상위에 위치 해야한다.

기술 매니저님이 주신 해결방안 키워드 : ApiResult

다음 프로젝트때 사용해 보는 걸로 ! 

4. 마지막 받은 피드백

① Restful API

기술매니저님이 API 명세서를 보시고, 더  Restful 한 API 를 위해 URL 부분을 점층적으로 다시 작성해 보도록 제안해 주셨다.

예를들어, 이전에 작성된 게시판과 댓글의 URL 은 "/api/posts/{id}", "/api/commnets/{id}" 이런 식이었는데, 이 분에서 해당 게시글에 달린 댓글의 경우 "/api/posts/{postId}/comments/{commnetsId}" 이런식으로 계단식/ 점층적인 방법으로 설계하라고 피드백을 주셨다. 추가로 동사를 지양하고 복수형 명사로 작성해야 된다고도 알려주셨다. 지난번에 공부해서 알고는 있었는데, 회원 탈퇴의 경우 어떻게 작명을 해야할지 고민이 되긴 했다.

② common package

전역적으로 사용되는 파일들 (예를 들면, 예외처리, Jwt, ApiResult 등) 은 common 이라는 package를 만들어서 사용하기. 

그리하여 수정된 사항은 아래 노션 링크 참조 ! 

과제 노션 링크 : https://www.notion.so/10-df14faf0f7ed43d2ae1d41d478b8b5f3

5. 프로젝트를 마치며

지난 3주를 돌이켜보면, Spring 에 대한 벽이 너무나 높게만 느껴지고 내가 과연 할 수 있을까라는 생각이 오조오억번은 들었던 주특기 주차였다. 아무래도 점점더 실력차도 실감하게 되고, 내가 직접 강의를 보고 이해하기보다 다른 사람의 코드를 보고 재작성 하다보니 자괴감이 들기도하고, 만약 현업에서 이런 참고 레퍼런스가 없다면 내가 스스로 작성할 수 있을까? 라는 생각도 드는 마음이 복잡한 한 주 였다. 

그래서 일단 남의 코드를 보고 작성하더라도 완성된 코드를 계속 보면서 어떤식으로 돌아가는지 이해하려고 했고, 첫주에 봐도 모르겠다는 생각이 그래도 이제는 내 코드를 가지고 응용은 할 수 있겠다라는 상태로 바뀌게 되었다. 아무래도 이 3주가 나와 같이 기본기가 없는 사람들에겐 많이 힘들었던 기간이었던 것 같다. 그래서 무려 5명의 스프링 반 사람들이 하차를 하기도 했다. 

아직 많이 부족하지만, 다음주 부터 시작되는 프로젝트에서 팀에 피해없이 1인분을 할 수 있도록 열심히 해야겠다.

1. 어려웠던 부분 : 지난주에 배운 게시판 CRUD를 바탕으로 프론트엔드 분들과 협업하는 미니프로젝트 기간이 시작되었다. 협업하는 연습을 할 수 있는 주차가 되어야 하는데 시작 기획부터 삐그덕 되는 상황이 발생했다. 일단 프론트엔드 팀원 3분 중 2분은 지난 주특기 주차에서 배웠던 내용이 완전히 숙지가 되지 않은 분들이라 CRUD 기능 구현을 할 수 있는 상황이 아니고, 심지어 html로 화면을 만드는 것도 힘들어 하시는 분들이 배정이 되었다. 그래서 백엔드에서 하려고하는 기능을 축소해줬으면 좋겠다는 의견을 주셨다. 

그런데 백엔드 입장에선, 당연히 주특기주차때 배운 기능정도 까지는 즉, 추가기능이 아니더라도 CRUD는 하실 줄 알아야 하는게 아닌가 하는 생각이 들었다. 하, 이래서 커뮤니케이션이 힘들다는 거구나 라는 생각이 들었다. 그리고 팀 배정을 형평성 없게 이렇게 한 팀에 또 시련을 몰아넣은 항해99가 너무 원망스러웠다. 

일단, 두 분이 너무 의지가 약해지신 상태라 이걸 어떻게 해야하나 머리가 깨질 것 같았는데 팀 회의를 통해 최대한 그분들에게 할 수 있다는 마음을 드리려고 노력했다. 언제까지 못하다고 하시면 앞으로 프로젝트도 똑같은 문제가 발생할 것이라고, 일단 한번 시도해 보시라고 설득을 했다. 일단 html css 는 다른 팀에 비해 안예뻐도 괜찮으니 이 분들이 CRUD만큼은 이번주차때 할 수 있다는 마음으로 시도를 해주셨으면 좋겠다는 생각이 들었다.

다행히도 해보겠다고 말씀은 해주셔서, 앞으로 어떻게 될진 모르겠지만 일단 그분들을 응원하기로 ! 나도 못하는 입장이기 때문에 어떤 마음이실지 이해가 안되는 건 아니다. 어제부터 마음이 안잡혀서 머리가 너무 아픈 하루였는데, 일단 주어진 기능부터 일인분 몫을 해보자.

2. 느낀 점 : 예쁜말로 소통하자. 다른 사람한테 상처주지 않도록 노력하자.

3. 새로 알게 된 내용 : 커뮤니케이션이 참 중요하다는 것을 다시한번 느꼈다. 프론트엔드와 백엔드 뿐만 아니라 백엔드 사이에서도 어떤 부분을 담당할지 계속해서 업데이트 해주는게 중요하다는 것을 다시 한번 알게 되었다. 

4. 셀프칭찬 (오늘 잘한 일) : 미니프로젝트 기획을 하는데, 아무래도 프론트 엔드분들이 최대한 html css 부분을 간소화 할 수 있는 주제가 뭘까 생각하다가 항해99 10기 b반 롤링페이퍼 커뮤니티라는 아이디어를 생각해봤다. 형식은 항해 출석체크 페이지 처럼 메인을 만들고 개인의 이름을 클릭했을 때 팬명록 프로젝트와 비슷하게 작성하는 걸로 생각을 해봤다. 이번주에 5분이나 하차하시는 걸 보면서 뭔가 제대로 인사도 못하고 헤어진 분들이 있는 것 같아 아쉬운 마음에, 연말이기도 하고 서로에게 용기가 되는 말을 전할 수 있는 그런 프로젝트를 기획하고 싶었는데, 이런 아이디어를 고안한 나 자신을 칭찬하고 싶다 ! 

5. 내일 할 일 : 맡은 기능 구현 완료하기. 깃헙에 백엔드 부분 합치기.

[오늘 공부한 부분]

• 프로젝트 기획 (아이디어 회의 , ERD 고안, API 명세서 작성, 파트 나누기)

기획 노션 링크 : https://www.notion.so/4-SA-9745b27d341a428a90d777bd7db5bfc3

피드백 대시보드 : https://docs.google.com/spreadsheets/d/1UtMWWFFJIf5k9q_s7LGm0feO0770wqZNT8lM7ZNa8j4/edit#gid=349344983