"woowa-techcamp" 태그로 연결된 6개 게시물개의 게시물이 있습니다.

1. 현장 이해하고 대응하기#

2. 프로젝트를 통해서 JS익히기#

3. 향상된 UX를 목표로 개발하기#

4. 함께 자라기#

• 함께 학습하기

• 간단한 프로젝트 함께 만들어보기

• 피드백

• 피곤하지만 함께 맞춰복

• 업무를 분석하고 github issue/project로 일감 만들어서 관리하기

• PR 보내기

• 코드리뷰 하기

• git branch 전략세워보기

5. 기초는 튼튼하게#

• 지속가능한 공부

• TCP/IP를 포함한 HTTP 중심 네트워크 공부

• 백엔드 접해보기

6. HTML CSS에서 FE엔지니어로#

코드리뷰#

node 로 백엔드를 하다보면 shared 폴더를 만들고 환경을 잘 갖추고 백과 프론트가 공유하기도 한다.

• HTML은 구조

  • p 태그를 쓸 때는 paragraph인지

  • 글자를 크게하자 하고 h3를 쓰면 안된다.

  • list 태그 → 다음 홈페이지의 뉴스 리스트

• CSS는 스타일

프로젝트 구조#

CSS, JS를 분리하는 경향

현대의 프레임워크는 컴포넌트 별로, 다른 방식으로 모으기도 함.

개발할 땐 항상 나눠서

소프트웨어가 항상 변경된다는 가정을 하고 개발하라. 서비스 코드가 변경이 된다.

좋은 코드를 만드는 방법, 변경이 용이한 코드. 변경을 했을 때 다른 코드에 영향을주지 않는 코드

변경될 때 영향을 덜 주고 수정도 쉽게 되고 기능도 추가되고 ...

나눠서 역할별로

CSS 공통 부분 > Global, common ...

모든 리팩토링은 중복부터

• JS 파일 자체는 모듈이기 때문에, is 등이 들어가면 어색해보일 수 있다.

매직넘버를 없애라 - 코드에서 숫자, 문자열을 쓸 때 분리해라.

JS에서 CSS를 조작할 일이 있을 때 → classList에 remove, add, toggle 등으로 조작한다. 스타일을 직접 조작하지 않음.

• 유지보수가 가능한 코드

• 가독성이 좋은 코드

• 테스트가 쉬운 코드

• 역할이 명확한 함수

• 접근할 일이 많으면 변수에 담아서

• 이벤트를 어디서 등록해야 할까?

• 조건도 함수로 나눠라

캠프의 목적#

• 어떻게 모듈화를 잘할까

• 어떻게 변경이 용이한 코드를 만들까

• 프레임워크를 써도 모듈화가 자동으로 되는게 아니다

변수명#

• 오픈소스를 자주 보면 도움이 된다.

• 좋은 회사면 동작하는 서비스 소스를 볼 수 있다

나만의 유틸리티를 만들어가는 걸 해보세요.

• 함수를 범용적으로

• 인풋이 있고 아웃풋이 있는 것이 테스트가 편한 코드

찾아보기#

• setInterval 단점

• 왜 setTimeout을 재귀적으로 사용하는지

• ES 모듈

• 렌더링을 자주 일으키지 말아라

• 함수가 짧아서 좋다

• 과도할 정도로 나누는게 낫다

ES 모듈#

• 프론트에서도 import export를 사용할 수 있다.

• 모듈 관리는 의존성 관리이다.

util은 범용성 있는 것, 비즈니스 로직과 무관한

백엔드에서 매직넘버를 사용하면 크리티컬한 이슈가 생긴다.

회원가입 로그인

→ 클라이언트에서 validation, 서버에서 validation을 해줘야 한다.

도구를 이해하고 써야한다.

aspective-oriented programming#

실제로 중요한건 유지 보수, hotfix가 자주 일어난다.

팀 프로젝트에 대해...#

스프린트 회의#

• 팀의 목표 수립, 위키 등록

• 개발해야 할 내용을 feature 단위로 추리고 issue 항목에 등록

스크럼#

• 상태, 어제 한 일, 오늘 한 일을 5분 내로 짧게 이야기

• 서로의 건강, 심리, 개발 진행 상태를 나누고 이해하기 위함

• 결과를 위키에 매일 작성

데모#

미니 세미나#

팀 주간 회고#

• 서로 격려하고 피드백 나누며 함께 성장하기

• 이번 주에 잘한 점, 아쉬운 점

배민상회 로그인/회원가입 페이지 구현#

그라운드 룰#

깃 셋업#

브랜치#

케밥 케이스

• master

• develop

• frontend

• backend

• feature/issue-#

• document

파일명 / 폴더명#

케밥 케이스

• 커밋 - 타입별 커밋 메시지 머릿말 붙이기

• git add . , git commit -m "" 최대한 자제해보기

ex) [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test]

컨벤셔널 커밋을 참조함.

Conventional Commits

PR 방식#

• 내가 보낸 PR은 상대방이 Squash and Merge 하기

이슈로 나누기#

GitHub로 프로젝트 관리하기 Part1 - 이슈 발급 부터 코드리뷰까지 | Popit

위키#

기능 명세화#

프로젝트 진행 방법#

월요일

화요일 - 몽촌토성역 큰집 11층, 9시

수요일, 목요일 - 범계역 스타벅스, 9시

목요일 완성을 목표로, 금요일 오전에는 문서 정리나, 리팩토링 정도만

금요일 오전 11시까지

배민상회 회원가입/로그인#

1. 아이디 input

공부는 어떻게?#

구글링#

• 영어 vs 한국어

  한국어는 컨텐츠가 부족하다. 공식 사이트를 보자.

MDN#

stackoverflow#

• 질문을 남기고 답변을 달아라

디버깅#

• 인생의 절반 이상을 디버깅에 쏟는다

• 디버깅하면서 학습하라

• this , closure 등등 어려운 개념은 디버깅 창을 띄우고 콜 스택에 쌓인 지역변수의 값이 뭔지 보면서 학습

• 디버깅 주도 학습

• 에러 메시지 무시하지 마라

  에러 메시지를 자주 봐야지 다음 번에 에러 메시지만 보고 상황을 판단할 수 있음

JS의 표준#

• ECMAScript

• ES 2015 == ES6

• prototype 몰라도 개발할 순 있지만, JS의 핵심이 prototype 이다. 꼭 이해해야한다.

객체지향 프로그래밍#

현실 세계에 있는 사물. 실존하는 것.

객체지향 프로그래밍의 핵심은 역할

역할을 나누는 것이 중요하다.

new 키워드 생성자, 속성을 파라미터로 넣어서 객체를 만든다.

스타벅스 커피, 바리스타의 예시

의존성이 낮은 연결고리를 만들어 주어야 한다.

연결을 느슨하게 하는 것이 중요하다. → 디자인 패턴

의존성이 낮아서 수정이 되도 연결된 다른 객체는 영향을 받지 않음

코딩보다 디자인

메소드 vs 프로토타입#

메소드는 메모리 공간을 차지

프로토타입은 각 객체가 메모리 공간을 쉐어 함.

module vs import#

즉시실행함수와 private#

비동기 프로그래밍#

JavaScript는 싱글스레드로 동작

then이 실행된 게 아니라 then에 등록된 콜백 함수가 실행 되는 것이다.

• 클로저

• 이벤트 루프

Github 위키와 이슈#

Milestone (지점)

Javascript#

Type#

숫자 → 부동소수점 방식

함수#

콜백#

회고#

I have done#

feeling#

나의 각오/계획#

1. 우아한테크캠프 끝나고 함께 프로젝트할 사람들 만나기

2. 다른 사람 의견 잘 듣기

3. 내가 아는 것은 친절히 알려주기

4. 모르는 것은 잘 질문하기

5. 배운 것은 개인적으로 써먹어 보기

6. 오늘 배운 내용은 오늘 복습하기

Git / Github#

Git에 관하여#

Git은 리누스 토발즈(Linus Torvalds)가 리눅스(Linux) 커널을 관리하기 위해서 만든소스관리 툴이다. (ㄷㄷ) Git 이전의 형상관리 툴은 SVN, CVS 등이 있었음.

간단한 소규모 프로젝트에 Git을 사용하는 것은 난이도를 높이지만, 복잡한 대규모프로젝트에서는 프로젝트의 난이도를 상당히 낮출 수 있기 때문에 필수적이다.

안티 패턴#

• git add . : 변경사항이 있는 모든 파일을 한번에 스테이징 하지 말아라. 한 파일한 파일 씩 변경사항을 확인하면서 커밋해라.

• git commit -m "" : 커밋은 git commit 으로 제목과 함께 간단한 설명까지 덧붙여서 작성하는 것이 정석이다.

이러한 안티 패턴이 만연해 있음. 좋은 커밋 습관을 기르는 것이 중요하다.

Git flow#

Git-flow, Github flow, Gitlab flow 각각이 다른 형상 관리 전략이다. 이 외에도 수많은 flow 들이 존재. 하지만 Git-flow 라는 이름 때문에 Git flow가 정석, 표준이라는 오해를 하기 쉽다. 하지만 Git flow가 복잡하고 어렵기 때문에 이를 사용하는 것이바람직하지 않은 조직, 팀이 있을 수 있다. Git flow 외에도 훌륭한 flow 전략들이 많기 때문에 Git flow에 대해 공부하는 것은 좋지만 무조건 GIt flow를 적용하는 것이표준인 것은 아니다.

Understanding the GitHub flow

우린 Git-flow를 사용하고 있어요 - 우아한형제들 기술 블로그

하루에 1000번 배포하는 조직 되기 | 뱅크샐러드

커밋 메시지에 대해#

• 메시지는 한글도 가능하다.

  커밋 메시지는 팀원 뿐만 아니라 미래의 나를 위해 남기는 것이다. 적당한 단어를찾지 못한 어색한 커밋 메시지를 남기는 것보다 한글로 명확하게 작성하는 것이 훨씬낫다.

  우리 프로젝트는 오픈 소스가 아니니까

  하이브리드로 커밋 메시지 제목을 영어로 남기고 설명을 한글로 작성하는 방법도 있다.

  실제로 TDD를 잘하는 팀에선 테스트 코드의 메소드 명을 한글로 하는 경우가 있다. 훨씬 명확한 메소드 명으로 인해 좋은 효과가 있다.

• fork 후 PR과 branch 후 PR의 차이

  기본적으로 fork는 내가 이 저장소에 권한이 없을 때 하는 것이다. 오픈 소스에 기여하는 경우 등등..

Git 명령어와 동작 원리#

Git 동작 원리를 제대로 배운 것은 처음이었고 기존 알고 있던 개념이 잘못되었다는것을 깨닫고 개인적으로 충격을 받았다.

Learn Git Branching

• git init : 숨겨진 폴더가 하나 생김

  • .git : 로컬 저장소

    • git의 저장 단위는 커밋

      • Working directory → Stage → Commit

  • GitHub or GitLab ... - 원격 저장소

  • git reset → 날아가지 않음.

  • 워킹 디렉토리의 변경사항에 대한 스냅샷

  • 커밋은 내부적으로 트리로 구성되어 있음 트리에 오브젝트들이 달려서 하나의 커밋을 구성함

  • git cat-file -t ce013

  • git cat-file blob ce013

  • git cat-file -t HEAD

  • git log -n1

  • git cat-file -t 7da33cf4

  • git cat-file commit 7da33cf4

  • git ls-tree aaa96ced2d9a1c8e ...

  • branch는 헤드에 대한 참조일 뿐

  • 커밋은 부모 커밋이 있다

  • git checkout C4 vs git checkout hello

  • git은 diff를 저장하는 것이 아니라 전체를 저장한다.

  • svn은 diff를 저장한다

  • tree .git

  • 브랜치를 많이 만들어도 용량이 증가하지 않는다.

  • git status

  • git checkout master

  • 브랜치는 커밋에 대한 참조일 뿐 아무것도 아니다.

  • 깃에는 커밋밖에 없다. 태그, 브랜치, 어쩌고는 다 참조 변수일 뿐이다 실제 존재하는 객체는 아무것도 없다.

  • git reset —hard Head~1 시에 복원하는 법

  • git branch test 체크섬

  • git reflog 모든 참조 변수들의 로그를 보는 명령

  • git push 로컬 저장소에 있는 것을 원격 저장소로 보냄