보편적 실무 개발 사이클
작업자, 기획자, 디자이너, 퍼블리셔, 프론트개발자, 백엔드개발자, DB관리자 등
작업순서
1.
기획자 혹은 PM이 클라이언트나 작업 요청자에게 요구사항과 의견을 파악
2.
내용을 바탕으로 기획자와 구성원들이 참여해 스토리 보드를 작성, 액션아이템을 리스트업
3.
기획자가 프론트/백엔드 개발자와 함께 기능리스트업과 목업 기획 작성
4.
기획자가 목업 기획을 바탕으로 디자이너/퍼블리셔와 상세 프론트 디자인을 정의
5.
퍼블리셔가 프론트 디자인을 바탕으로 HTML 작성
6.
기획자와 프론트개발자가 HTML 검수, 필요시 피드백
7.
기획자, 백엔드개발자, DB관리자가 기획을 바탕으로 데이터 DB모델링
8.
기획자, 프론트개발자, 백엔드개발자가 api와 데이터 매개변수를 정의
9.
1)백엔드개발자와 DB관리자가 ERD와 DB스키마를 정의하고 DB를 구축
2)프론트 개발자는 HTML에 정의된 프론트 기능을 구현
3)백엔드개발자는 정의된 API와 비지니스로직을 구현
4) 기획자는 DB, 프론트, 백엔드의 구현과정을 모니터링하며 클라이언트와 작업 산출물들을 정리하여 피드백을 주고받아 지속적인 피드백, 디자인/퍼블리싱 변경점도 지속적으로 소통, 일정관리
10.
구현 완료 시 DB, 프론트, 백엔드 간 통합 테스트 및 개선, 피드백
11.
클라이언트에게 산출물 공개, 최종 피드백
12.
기획자는 향후 추가 개선내역을 정리하고 운영 담당자에게 산출물 인계
FrontEnd
컨텐츠별 소스 분리
•
레이아웃 페이지에 컨텐츠 페이지를 import해서 붙여넣는 방식으로 자식페이지를 다른 페이지에 재사용 이점
공통 소스 분리
•
공통기능을 가진 모듈(ex. 버튼, 필터, 헤더, 풋터같은 페이지마다 공통으로 사용하는 성격의 모듈)을 분리해 다른페이지에 재사용에 이점
패스워드 마스킹
•
마스킹이 없을 경우 패스워드 노출
BackEnd
•
디펜던시
◦
Gradle/Maven, MavenCentral, .m2/setting.xml, gradle.build/pom.xml 라이브러리 리파지터리 사용법
검증된 디펜던시만 사용, 가능하면 최근버전 스프링부트/스프링/자바표준에 내장된 디펜던시를 사용할 것(ex. Unirest, Jackon, joda-time etc...와 같은 오픈소스 라이브러리는 사용하기는 쉽지만 더이상 업데이트되지 않아 현재 고버전 스프링부트와 호환이 되지않아 버그가 발생함)
◦
최소한 사용하려는 디펜던시 라이브러리의 버전별 특이사항을 확인할 것
◦
오픈소스 라이센스를 사용할 때는 라이센스별 정책을 확인하고 사용 - GNU(상업적 이용시 소스공개의무와 기타 사회적 책임이 따름), MIT(소스공개나 다른 책임이 없음)
◦
기본적으로 오픈API는 사용시 오류발생에 대한 보장이 되지 않기때문에 항상 신중하게 사용해야 하며 어쩔수 없이 사용해야 할 경우에는 최대한 많은 사용자들이 사용하고 구글링 시 이슈검색이 되지 않는 라이브러리를 사용
•
프로젝트 관리
◦
ReadMe.md - 해당파일만 보고도 컴포넌트에 대해 파악할 수 있도록 구성하는 것이 가장 좋음, 이외 배포방법과 환경설정 정보, 특이사항 등도 포함, ReadMe.md는 컴포넌트의 얼굴, 웹의 표준작성법 참고
◦
주석 - 로깅이나 ReadMe.md보다 자유롭게 사용이 가능하기 때문에 복잡한로직이나 함수에 대해 분석하지 않고도 기능을 명시하고 input/output을 표시해 놓으면 분석에 시간을 절약할 수 있음
◦
버전관리 - 컴포넌트의 x.x.x(앞자리부터 메이저, 미들, 마이너) 버전을 명확하게 관리해서 소스가 꼬이거나 누락되는 상황이 없도록 항상 버전을 높일 때 어떤게 변경됬는지 릴리즈노트와 함께 정리하는 습관이 좋음, 마이너는 소스변경이 하나라도 있으면 올리고, 미들은 기능적인 변경점이 있을 경우, 메이저는 프레임워크 버전이나 대격변이 있을 경우 변경
•
배포, 형상관리
◦
Git 사용법 숙지, Git을 기본으로 GitLab, GitHub의 활용, 웹의 Git 표준 사용법 참고
◦
브랜치 및 커밋순서(개발브랜치에서 개발, 개발완료 후 크로스/코드 리뷰, release브랜치로 Merge Request로 관리자 검수, 검수이후 stg, prod 환경에 배포, 배포 완료 후 Master 브랜치에 병합, hotfix 브랜치 사용) https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/
◦
Git Commit 메시지 포맷(Git template 애드온 활용 추천, 날짜, 작업목적, 내용, 작업자, Change Point, 영향도)
•
application.yml
◦
yml 포맷 사용법 - 중복 뎁스가 없도록, 표준 설정일 수록 위쪽에, 사이드 설정일수록 아래에 작성
◦
application.yml에 명기하는 계정, 패스워드, 대외비 변수값은 무조건 암호화해서 사용, 필요시 복호화 해서 확인할 것
◦
db커넥션설정 미존재, 스레드풀 무한증가 가능성 존재 - 목적에 따른 DB설정, 커넥션 풀 설정법 스터디
◦
db접근 계정이나 외부시스템 사용은 개인계정이 아닌 서비스계정 사용, 운영목적으로 필요시에는 운영공통계정 사용
•
테스트
◦
회귀테스트(기능의 모든 발생할 수 있는 케이스에 대해 확인하는 테스트), 퍼포먼스테스트(부하와 속도가 적합한지 여부에 대한 테스트) 등 여러 테스트 방법에 대해 스터디
◦
테스트 시나리오 - 테스트는 발생할 수 있는 해피케이스, 오류케이스와 같은 모든 예상값에 대해 시나리오가 정리되어 있어야 추후 수정 시 영향도 파악과 추가 테스트에 용이
◦
host 파일 변경으로 다중호스트에 대한 개별 단위 테스트 방법 숙지 - 웹 검색
◦
Junit, Postman 사용법, 주요 실무버전은 4,5버전 사용, JUnit, Postman 사용법 스터디
◦
단위테스트 - 로직, 함수 작성 시 테스트
◦
모듈테스트 - 여러 함수가 동시에 작동해야하는 api개발이나 주요 모듈 개발 시 테스트
◦
통합테스트 - 컴포넌트 개발 시 모든 대상에 대해 테스트
◦
TDD 디자인 - 테스트 주도 개발 디자인 패턴, 도서나 웹강의를 통한 스터디 추천
•
정적분석
◦
정적 분석 - 정적분석은 소스레벨에서 정합성에 이상이 없는지 확인하는 테스트, 정적분석은 올바른 코딩습관을 기르고 오류발생 가능성과 보안취약점에 미리 대응할 수 있음
◦
SonarLint, SonarQuebe 사용법 - 최대한 정적분석에 걸리지 않도록 코딩하는 습관, 중앙화된 정적분석을 통해 코드퀄리티 관리, 웹검색 추천
•
프로필
◦
개발, 테스트, stg, prod별 다중프로필 이용과 이용에 따른 설정방법, 프로필별 내용 작성법 구분 스터디
•
로깅
◦
로그포맷(호스트네임, api이름, 파라미터, 내부함수이름, 엑세스테이블(칼럼데이터), 호출딜레이)
◦
로그레벨 - 배포환경별로 로그레벨을 달리 구성(DEBUG, INFO, ERROR, WARNING 등)
◦
로깅포인트 및 내용 - 보안에 민감한 내용(개인정보나 대외비)을 로깅을 하지않거나 암호화시킨 후 출력, 복호화 후 확인하는 식으로 구성, 알아보기 쉽게 최대한 간결하게 작성
•
JPA
◦
엔티티 구성
◦
DTO와의 차이점 - 데이터 전달용 객체와 엔티티는 형태는 비슷해도 사용목적은 확연히 다르며 사용도 구분해서 달리해야 함
•
Annotation
◦
@Transactional - 인터셉트 할 Exception을 정확히 표기, 최소한 Exception 전체를 잡아 Transaction 자체가 작동하도록 구성
◦
@EnableScheduling - 스케쥴링은 배포 시 영향을 받기 때문에 보통 배치시간별 별도 컴포넌트로 구성 및 이중화
◦
@Lombok, @AllArgsConstructor - Injection 주입을 자동화, 간결하고 편하게 사용하는데는 좋으나 Spring의 기본구조를 설명하는데 풀어서 설명하는것이 도움이 되고 기본구조를 모르면 어노테이션을 남발해 로직오류의 원인이됨
•
소스
◦
폴더구조와 소스가 JPA구조에 매우 높게 Aggregate되어 있음, 일반적인 폴더구조로 설명하는것이 적응력을 높이고 JPA가 아닌 프로젝트를 만낫을때 대응하기 좋을것으로 보이며, 현업에서 JPA는 경직된 db접근과 사용때문에 기피되는 기술, 가장 기초적인 PreparedStatement를 먼저 공부하고 그다음 보편적인 db프레임워크인 Mybatis를 기준으로 학습 하는것이 DB와의 통신을 이해하는데 도움이 될것으로 보이며 JPA는 차후 필요에 의해 학습하는것이 나을 것으로 보임
◦
유틸소스 용도별 분리 - 직관성 증가, 유틸 재사용과 확장성에 도움이됨
◦
단일 트랜잭션에 @Transactional 어노테이션은 불필요
◦
클래스레벨에서 Repo가 ReadOnly인데 함수레벨에서 insert가 동작하는가? 그럴거면 클래스레벨에 ReadOnly는 무슨의미가 있는가?
◦
extends(재사용), implemnt(interface의 구현체, 재사용과 필수구현), inferface(골격제공, 재사용)의 기능과 용도
◦
api파라미터의 종류(PathVariable, RequestParam(queryString), RequestHeader, RequestBody)
◦
api 메소드, 미디어타입, 헤더의 종류와 내용에 대한 스터디
•
API
◦
표준 REST API 설계 방식을 따를것
◦
강사님의 코드가 전체적인 모던자바 코딩스타일을 많이 따랐으며 가독성이 좋고 로직의 복잡도를 줄이고 DB처리에 직관적인 실무 입장에서 봐도 품질이 높은 매우 참고할 만한 좋은 코드, 다만 모던자바 스타일의 실제 구동원리를 이해하고 사용하는 것이 중요
•
예외처리
◦
로직별 try-catch-finally를 통해 오류 발생시에 어떻게 동작시킬 지를 명확하게 정의, 이를 위해서 작성 로직별에서 발생할 수 있는 예외의 종류를 미리 파악하고 예외의 종류마다 별개의 예외처리를 해 주는것이 올바른 예외처리
◦
예외처리 목록화 - Enum으로 예외들을 전부 걸러서 내부목록화 후 사용자에게 보여줄 형태를 정의, 보통 4~5자릿수를 동일한 종류의 오류를 묶어 하나의 대분류로 구성하고 개별 오류별로 넘버링한 뒤 메세지를 붙여 FrontEnd에 날것 그대로의 오류를 전달하면 오류대응이 불가능, 오류대응이 가능하도록 넘버링과 메시지를 전달할 것
◦
인터셉터 - 오류발생 시 목록화 시킨 예외처리에 비는 오류가 없도록 구간별로 예외처리
•
모니터링
◦
Spring Acuator, 그라파나, 스택드라이버, 이외 서드파티를 활용한 리소스, 프로세스 모니터링과 서비스메시 - 로그가 많고 호스트가 많을 경우엔 모니터링에 한계가 있기때문에 별도 모니터링시스템 구축이 필요하며 모니터링이 되지 않으면 시스템의 개선이 불가능하고 오류발생시 트러블슈팅이 어려우며 최악의 경우 트러블슈팅 자체가 불가능할 수 있음
◦
알람 시스템 구성을 통해 오류 발생시 SMS, 메시징시스템과 연동해 발빠른 대응이 가능한 운영환경 구축
•
보안
◦
FrontEnd와 BackEnd 구간 통신 시에는 항상 urlencode/decode 과정을 통해 통신과정에서 발생하는 데이터 변조를 예방
apiKey - 소스가 유출되더라도 apiKey를 구성해 해당 key를 알지 못하면 FrontEnd에서 BackEnd 컴포넌트의 API를 활용할 수 없도록 구성
◦
개인정보, 대외비 - DB에 암호화 시켜 적재하되 일정주기별로 암호화키를 변경, 가장 좋은건 클라우드 key순환 서비스를 사용, 인가된 관리자만 개인정보에 접근하도록 롤 관리와 별도보안망/서버 구성
◦
로그인 횟수 제한 및 락 정책필요
