백엔드가 이정도는.. (실무)

프로젝트 이해하기

• 내가 프로젝트를 제대로 이해해야 내가 재미가 있고,

• 기획자를 도와줄 수가 있음

구현이 어렵거나 오래 걸리는 기능

• 기획자와 논의하여 기능의 가성비를 높여야 함(중요도는 높고 일정은 적게 걸리는 식으로)

• 딱 봤을 때, 오래걸리는 작업인데 중요성이 떨어지면 기획자에게 이야기하기

Validation에 대하여

문자열

• 최소/최대 길이

• 포맷(e.g 이메일 포맷..)

• Enum(값을 입력하는 게 아니라, 선택하게 만들기)

• 사용가능한 문자 범위 제한

• 이메일 username 뒤에 +문자 붙여서 aliasing 할 수 있음

기타

• 멀티미디어 용량, 개수 제한 걸어두는게 좋음

• 시간이 지나면 의미없는 데이터(나이. 시간지나면 바뀌어야하는데? 그래서 생년월일 받는게 나음)

보안상 위험한 UX > ID가 틀렸다/ 비밀번호가 틀렸다

• ID 또는 비밀번호가 올바르지 않다 라고 실패원인 detail하게 알려주지 않는것

• 비밀번호 강도 검사 하지 않는 경우. zxcvbn이라는 라이브러리를 알려주고 level을 정하게 만들자(기획자에게)

• 로그인을 무한정 시도할 수 있는 경우 → brute forcing이 가능하니, 시도횟수 제한 걸기

의사결정의 원칙

• 팀에 익숙하거나 숙련도가 있는지

• 팀의 요구사항을 충족하는지

• 비용 부담을 감당할 수 있는지

• 보편적인 기술인지
• 나중에 사람 뽑을때나 구글링할 때 영향이 있을 수 있음

• 프로덕트에 어울리는 기술인지

• 오버엔지니어링이 아닌지

작업 관리

• Trello

• Monday

• JIRA
• 관리자 계층이 확실한 조직이거나 개발자 외의 사람들에게 작업관리가 필요하다면 사용

• GitHub Projects + Issues
• 개발자 위주의 조직에서 주로 씀

예외처리