BIcOding

API 유저(/users) 번호 기능명 API명 권한 설명 1 회원가입(유저 추가) 일반 OAuth2 네이버를 이용할 예정 2 유저 조회(개별) selectUserOne 관리자 특정 유저 상세 정보 조회 3 유저 조회(전체) selectUserAll 관리자 모든 유저를 조회, 페이지네이션, 카테고리별 검색(optional), 키워드 검색(optional) 4 유저 수정 updateUser 관리자 특정 유저의 권한 혹은 상태를 변경, 유저 삭제는 존재하지 않고 상태 변경만 존재 광고(/ads) 번호 기능명 API명 권한 설명 1 광고 추가 postAd 관리자 광고 엔티티의 모든 속성 필수 2 광고 노출 exposeAd 일반, 관리자 1.자동 순차별 조회 2.노출 횟수 조절(optional) 3 광고 조회(..

git fetch와 pull의 차이 git fetch 원격 저장소의 메타 데이터를 확인하고, 변경 사항의 유무를 파악함. 변경된 데이터를 실제로 가져오진 않는다.git pull 원격 저장소의 메타 데이터를 확인하고, 변경 사항의 유무를 파악한 후 변경된 데이터가 있으면 로컬 git에 복사한다. git fetch와 git merge가 동시에 이루어지는 느낌

23.06.20 엔티티 연관 관계; JPA User : Ad = 1 : N User : Web_Info = 1 : N User : Web_Like = 1 : N User : Web_View = 1 : N Web_Info : Web_Eps = 1 : N Web_Info : Web_Like = 1 : N Web_Info : Web_View = 1 : N Web_Eps : Web_View = 1 : 1 User 유저(일반) 유저가 여러 개의 관심 웹툰을 지정할 수 있음 유저가 웹툰을 조회한 경우도 DB에 저장 유저가 여러 웹툰을 조회할 수 있음 웹툰을 조회할 땐, 웹툰의 여러 회차 중 하나의 회차만이 가장 최근 조회 데이터가 될 예정 유저(작가) 유저가 여러 개의 웹툰을 제작할 수 있음 유저(기업) 유저가 여..

application.property .yml로 변경 기능 기반 패키지 구조 package 구조 advertisement user web_details web_info각 package 별 내부 구조 controller dto entity mapper repository service 각 계층 파일 기본 틀 Controller Class Annotation @RestController @RequestMapping("{url}") @Validate @Slf4j @RequiredArgsConstructorHandler Methods Annotation @~Mapping @Valid @RequestBody @RequestParam @PathVariable

Tools ERD Clouds 목표 데이터 모델링 엔터티 도출 및 관계 분석 유저 권한에 따른 애플리케이션 사용 범위 분석 Entity 유저 웹툰 정보 웹툰 만화 광고 메모 모든 관계는 식별 관계보다는 비식별 관계로 진행할 예정. 식별 관계일 경우, 복합키로 설정될 경우도 많고 때문에 기본키의 변경이 일어나는 경우가 많음. 이를 방지하기 위해서 비식별을 선호 하지만 비식별 관계를 사용함으로써 인조키를 생성해야하고, 조회 시 join이 발생하여 성능 저하를 초래할 수 있음 TODO Entity 추가 도출 Entity 속성 분석 정규화 실시 ERD(1차) ERD(2차)

**소프트웨어 개발 단계 >기획 단계 1. RFP(Request For Proposal) : 제안 요청 2. 프로젝트 계약 완료 3. SRS(Software requirements specification) : 프로젝트 큰 그림 설계 >분석 단계 : 사용자 요구사항 정의서 : 유스 케이스 명세서, 요구사항 추적표 >설계 단계 : 화면 정의서 : 테이블 설계서 : API 명세서 >구현 단계 **사용자 요구사항 정의서 >정의 : 고객의 요청 사항을 기반으로 SRS의 협의 내용을 적용하고 실제 개발에 적용할 수 있는 수준으로 요구사항을 재정의 한 것. : 표 형태로 시각화 : 기능적 요구사항과 비기능적 요구사항을 나누어 작성 //기능적 요구사항 : 실제 애플리케이션 동작을 수행하는 작업 //비기능적 요구사항 ..

**SRS >SRS 정의 : Software requirements specification : 프로그램 종합 설계도 >SRS Template 1. 소개 1.1 목적(Purpose) // 해당 애플리케이션 혹은 설명하고자 하는 부분의 시스템을 안내 1.2 문서 규칙 (Document Convention) // 텍스트, 주석 등 문서의 모든 표기 규칙을 안내 1.3 독자대상과 읽는 방법 (Intend Audience and Reading Suggestion) 1.4 프로젝트 범위 (Project Scope) 1.5 참조 (Reference) 2. 전체 설명 (Overall Description) 2.1 제품조망 (Product Perspective) 2.2 제품 기능 (Project Feature) 2.3..

**git flow >Git flow : 대규모 프로젝트에 적용하기 적합 //링크 //따로 추가로 정리할 예정이지만, 아래 링크가 아주 기똥차기 때문에 우선은 참고할 것. https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5 >merge -rebase and merge : 이건 커밋 기록이 다 남음 -squash and merge : 커밋 기록이 안남고 깔끔하게 다 합쳐지는?느낌 //링크 인텔리제이 깃 다루기 https://ddoriya.tistory.com/entry/Intellij-Git-%EC%82%AC%EC%9A..

**프로젝트 과정 >1. Github repo에 필요한 파일 -README.md : Markdown 양식의 파일 : 프로젝트 이름, 프로젝트 핵심 기능 소개, 팀원 소개와 같은 해당 Github repo의 안내서와 같은 역할을 함. -.gitignore : 말 그대로 git이 관리하지 않도록 무시하는 파일의 목록을 설정하는 파일 : 해당 파일에 설정된 파일 혹은 디렉토리 경로는 local repo에서 git으로 관리되지 않으며, push를 해도 github repo에 push되지 않는다. -LICENSE : 해당 코드의 라이센스를 표기 : 해당 코드를 public으로 공개할 경우에도 저작권은 존재하기 때문에 이를 라이센스로 표기하는 것임. : 오픈 소스 사용 및 배포 시, 지켜야할 규칙, 이용 방법, 조..

**팀 프로그래밍 >목적 -효율성 향상 -창의성 향상 -강력한 혁신 >성공적인 프로젝트 -Hard Skill : 사용한 개발 스택들이 현업에서 사용할 만한지 : 취업 시 경쟁력이 될 만한 가치가 있는지 : 매일 팀과 개인의 실패 혹은 성공 로그를 남겼는지 -Soft Skill : 프로젝트 도중 동료를 신뢰했는지 : 실패 혹은 성공 경험에서 무엇을 느꼈는지 : 프로젝트 중 본인이 충분한 노력을 했는지 >Soft Skill Details : 내가 먼저 신뢰할 수 있는 동료가 되자 : 경험에서 얻은 교훈을 발판삼아야 한다. 꼭 기록해라 : 노력을 해보고, 안해보고의 차이는 크다. 해봐라 **커뮤니케이션 >서로의 차이(존재) 인정 : 본인이 팀에 피해를 주려는 사람은 없다. : 모두 도움이 되려하지만 기여하려는..