1월 17일 (금)

오늘 배운 것

• 깊은 복사 / 얕은 복사 차이점 알기

• 프로세스와 스레드 공부.

• 미션의 입력창부터 만들고 싶어서 readline과 정규식표현 샛길로 빠져서 공부... -> 정규식 성공해서 기분 좋았다

• 피곤하다. 운동하고, 저녁먹고 집가서 푹 쉬고. 주말에 프로세스 공부와 코드 다시 짜보는거로 해야지

• 성장하는 법: Comfort Zone을 벗어나기. 근육운동의 무게를 약간씩 증가시키는 것처럼.

  점진적 과부하

• 문제가 어려우면 내 수준으로 낮추고, 너무 쉬우면 Comfort Zone에서 머물지 말기.

git을 잘해야 하는 이유

• 100점 만점 중 90점쯤 되는 어려운 툴

• 그럼에도 불구하고 git을 못하면 파일을 관리하는데 애로사항이 생김

• git은 원리를 모르면 사용 자체가 힘들다

• 좋은 코딩을 하려면 많이 공부하고 많이 구현해야 한다.

• 다른 사람의 소스코드, 오픈소스의 소스코드를 많이 읽어보기

• 둘 사이에 밸런스를 잘 조절해야 한다.

• 도구는 여러가지를 쓰는게 좋다.

커밋할 때는 꼭 자세히 커밋 메세지를 작성하기. 내 머리속을 정리하면서

의심하기

• 문제가 제대로 된 것인가?

• 자연스러운가?

• 효율적인가?

해설

• commit : 팀원 누군가의 로컬 컴퓨터의 세이브 포인트.

• checkout : 로컬 저장소에 있는 파일들에 대한 커밋들을 꺼내서, 내 작업 디렉토리에 반영시키는 것.

• 항상 커밋은 메세지만 적어준다. 내용은 스테이지에 있는 내용 전체로 고정된다.

• add로 스테이지에 뭘 올릴지 정해주는 것

• 일반 유저에게는 '내 작업 폴더'가 '최종 저장소'다. git에게는 그렇지 않다. git에게는 '내 작업 폴더'는 아무것도 아니고, '커밋'이 실제 최종 저장소다.

• init : 로컬 저장소를 만든다.

• 커밋할 사항이 없다 -> 작업 폴더 / 스테이지 / 커밋 이 모두 같은 상황이다.

• 스테이지에 있는 내용을 커밋해도, 스테이지는 비워지지 않는다.

• git에선 내용이 완벽하게 같은 파일은 하나만 허용한다.

• HEAD -> master branch -> commit 순서로 가르키는 게 정상적이다.

• git은 변경사항이 아니라 항상 전체를 저장한다. 이에는 분명히 저장공간에 손해가 있다. 하지만 일일히 변경사항을 체크할 필요가 없기 때문에 체크아웃할 때 속도가 훨씬 빠르다.

• git은 원래부터 local 저장소와 remote 저장소의 차이가 전혀 없다. url만 다를 뿐

설계에서 고려해야 할 것들

• 클래스들의 관계: 클래스 다이어그램

• 실제 동작 시나리오: 시퀀스 다이어그램