Dev-dotoli TIL

inno 50



Sparta coding



Innovation Camp


w8 day50



theme

해리포터 기숙사 고르기

20일까지 테스트문항 각자 찾아오기

view할당 / 저녁까지?
1/5 태권님
2/4 무제님
3/6 준하님

3: done
6:

README 수정해놓기

도트글씨

19 14:00 git특강

개론설명 ?

project에서 쓸 수 있는 resource

  • 시간

  • 일정 / 데드라인(중간발표/최종발표/이력서전면접전)

  • 인간 human resource
  • 현재실력 / 팀원 - 얼마나작업(man hour/불확실)
    • MVP
      • 로그인/회원가입 : 3일
      • 커뮤니티 기능 : 1주일 등
    • 정보가 없기 때문
      • 계획을 수립해도 안될가능성 up
        • 1980년대 waterfall
          • 기능을 잘게 쪼개서
        • 요즘은 에자일?
          • 최소한의 주요기능(user반응 - product실험)
            > 설계하고 - 구현 - user test - beta
          • 루프1 > 루프2 > 루프3 > 비즈니스 임팩트
          • 서비스 (b2b / 사용자) - 솔루션 - 커스터마이징(고객회사의 요구)

  • 중요기능 빠르게 확인

    • “detect early” : 빨리 발견

      • 버그(베타 리리즈 발견 )
        • 콘솔 : 인간
        • 커뮤니케이션 : 상사의 눈빛 / FE-BE(협업)
        • 빨간글씨 도구?
      • 공유 > 카톡,화면,소리친다
        • 공유 > 오래걸림 > 다른사람에게 도움
    • pivot(? 우리 기능 통하기 않을때 바꾸기) / 사용자 반응
    • 일정 늦어지는지, 빨라지는지 > 계약최종 발표까지
      • v1 뼈대
      • v2 심화
    • 인간 > 얼마나 개발할 수 있는지 배우기 > 러닝커브(난이도,시간) - 대안

  • feedback / adapt

    • 일정 늦어지는지 / 빨라지는지 -> 지표를 정하고 확인(헬스체크)
  • 버그 : 내가원하는대로 동작되지 않은 것?
  • 에러 : 아예 돌아가지 않는 것?

리소스를 관리하고
issue를 만들고 관리하고
(issue로 task를 관리할 수 도 있음)

code review :
github을 사용해서 / 참여하지 않은사람도 확인가능하게 노출

  • issue사용할 때 제목만 적어놓고 쓰지않으면 안됨
    구두보다는 기록으로 남길 수 있게 댓글 남겨놓을 것?
    심지어 퇴사한 사람들의 history도 보면서 확인 가능
  • issue안에 내가 할 task 명시할수있고
    그 tast를 보고 다른사람이 첨언
    해결된 문제는 issue를 수정하면서 반영

  • issue에 label 붙이고 label별로 구분해서 관리

    • question, bug, feature:user, discussion, document,
      issue templet이 있음 참고 / checklist 등등 다양
    • commit할때 issue를 명시해서 연동 가능
      commit 말고도 pr단위로 연동해서 관리할 수 있음
      • commit이나 pr body(messege)에 issue번호 남겨서 연동
    • review기능 code by code에 다 coment를 남길 수 있음

  • 실제 code작업과 docs가 투명하게 연결되어있는지 신경쓰기

    • 나중에 관리할 때 다 일이 됨 / human error > 최대한 줄이자
      • milestone(이정표, 거리표시돌)
        • ~개발을 할거고 / ~까지 할거고 / ~issue가 있고
        • Goal : ~목표 등등 milestone을 촘촘하게 잡는게 처음엔 유리함
        • issue 등록하면서 milestone선택해서 연동가능
          • #code review / 이번에 집중할 등 추가해서 씀

  • 처음부터 완벽하게 할 수 없을거야
    작은 것부터 할 수 있는 것 부터 시도해

  • git의 장점 형상관리
    branch > delet X / close O

  • 프로젝트를 한줄로 설명하기(연습해)
  • 길어지는항목
    convention문서는 따로 관리(링크로 대체)
  • 기획의도 > noise가 될 수 있음
  • FE는 library등 언어 나 stack은 간단하게
    code만봐도 파악이 됨
  • projeck의 맥락 / 설계를 전달하도록 노력
  • 성능 test 했을겅우 포함하면 좋음
면접때 튜텨님의 경우는
내가 하는말을 이해할까?
알아서 학습할 수 있을까?
못알아 들으면 어떻게 해나갈까?

협업 history로 확인 / 개인면접시 contribute 수 확인
실제작업과 커뮤니케이션을 어떻게 하는지 등

  • url에 대문자 없이(WEB표준을 알긴하나? 의문가짐)
    REAME.md / api로 볼륨 / ERD / trouble shooting / 성능test시나리오 /
    branch전략 / issue / pr 등 관리
  • link를 타고가는 정보는 optional하게 판단하고 덜보게됨
    꼭 보여줄것은direct로
  • 나를 빠르게 파악할 수 있게 정보를 집약

개발자가 다른 사람의 작업을 살펴볼 때(or면접볼 때)

  • readme를 보고 api명세서 / 의미있는 commit
    description 꼭 채워놓기(대부분 비워놓는데 X)
    repo하나하나 들어가기보단 전체를 보려고 할 가능성 높음

  • 내가 얼마나 성장할지? 어떻게 성장해나갈지 확인하는
  • 그 기반이 되는 base에대한 공부
  • 잘하는 사람 뽑고싶으면 경력자 뽑지
  • 언어에대한 깊은이해 / 문제에 대처하는 방법
  • WEB개발자인데 WEB을 잘몰라 / arkitecture 구조를 읽지 못해
    등등 기본에 가까운
  • 오버엔지니어링 : 별로임
  • 이력서는 프린팅해서 보는경우 많음(링크길면 안봄)
  • 채용공고를 자주 확인 : Goal을 확인할 수 있음

  • 내가 가고싶은회사의 면접이 첫번째 면접이 되지 않도록
    면접 가능한 자주 해볼 것

  • 조엘test? 회사에 적용중인지(근데 10~20년됨)

  • CS보다는 WEB을 아는것이 더 도움이 됨(도서추천)
  • 프로가 되기 위한 웹 기술 입문

  • 웹 개발자를 위한 웹을 지탱하는 기술

  • community openSource contibutor활동 많이해서
    추천 받아서 취직한 적 있음

react 커뮤니티그룹(slack같은?)