git 사용법-3 (브랜치를 사용한 협업 방법) git branch 관련 git branch 브랜치명 (협업 시 유용) => 브랜치 생성 브랜치란? => 새로운 기능을 추가할 때 프로젝트의 복사본을 만들어서 거기에 먼저 개발할 수 있게 하는 복사 git checkout -b 브랜치명 => 브랜치 생성 후 그 브랜치로 이동 git checkout 브랜치명 => 브랜치로 이동 ( checkout은 branch를 변경하거나 파일을 복원하는데 사용하는데, checkout에 너무 많은 기능이 몰려있어 checkout의 기능을 나눈 switch/restore를 사용하는 것을 권장한다) git switch 브랜치명 => 브랜치로 이동 git merge 브랜치명 => 메인 브랜치로 이동해서 명령어 입력시 브랜치와 합칠 수 있음 => 메인 브랜치와 합칠 브랜치가 같은.. git 사용법-2 (git 되돌리는 방법) 코드를 짜다가 실수해서 되돌아가야 할 때 git restore 파일명 => 파일을 최근 commit으로 되돌려 줌 git restore --source 커밋아이디 파일명 => 입력한 파일이 특정 커밋아이디 시점으로 복구된다. git restore --staged 파일명 => 복구와 상관없지만 특정파일을 staging 취소 할 수 있다. git revert 커밋아이디 => commit을 되돌려줌, (commit을 지우는 것이 아닌 commit 하나를 취소한 commit을 하나 생성해줌) git revert HEAD => 최근 했던 commit 1개만 revert 해줌 git reset --hard 커밋아이디 => 커밋이 생성될 때로 시간을 되돌려준다. git reset --soft 커밋아이디 => 커밋한 .. git 사용법-1 (git commit, git log, git stash) git commit 관련 작업 폴더에서 git을 사용하고 싶을 때 git init 부터 입력 (터미널 -> 새 터미널에 입력) => .git repository를 만들어야 함 git add blabla.txt => 내가 기록할 파일 고르기 git add one.txt two.txt => 두개를 기록하고 싶을 때 git add . => 모든 파일을 기록 git commit -m 'any message' => 파일 현재 상태 기록 - 나중에도 파일 상태 그대로 되돌리거나 파일 변경 히스토리를 열람 가능하게 함 git은 작업폴더, staging area와 repository(저장)로 나뉘는데 git add을 하게 되면 staging area로 넘어가고 (staging) git commit을 하게 되면 repo.. 디미터 법칙 디미터 법칙 : 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다.(최소한의 지식 원칙) 객체는 자료를 숨기고 함수를 공개한다, 즉 객체는 조회 함수로 내부 구조를 공개하면 안된다는 의미이다. 클라이언트 객체가 서버 객체를 사용할 때 서버 구조에 대해 가능한 적게 알아야 한다. 서버의 속성과 모양은 클라이언트에 의해 완전히 알려지지 않은 상태로 유지되어야 한다. 클라이언트는 서버에 접근하여 내부를 묻고 해당 내부에게 명령을 내려서는 안된다. 클라이언트가 서버의 내부에 의해 렌더링되는 서비스가 필요한 경우, 클라이언트는 반드시 서버 내부의 접근 권한을 부여받으면 안된다. 대신 서버 객체는 오직 표면 인터페이스(surface interface)를 제공해야한다. 디미터 법칙의 기본적인 요약은 다음과 같다. .. 하나의 메서드가 하나의 기능을 수행해야 하는 이유 1. 메서드 명만 보더라도 어떤 기능을 수행하는 메서드인지 명확하게 알 수 있다. - 기능의 단위가 짧고 명확할 수록 기능을 대변하는 이름 짓기도 수월하다 - 잘 지은 메서드 명은 코드의 가독성을 증가시키고 유지보수를 수월하게 해준다. 2. 코드의 재사용이 증가하여 유지보수가 용이해진다. - 메서드를 작은 단위로 쪼갤수록 여러곳에서 쉽게 가져다 재사용할 수 있다. 3. 단위 테스트가 수월해진다. 4. 전체적인 가독성이 높아진다. - 메서드를 작성할 때 가장 좋은 라인 수 : 5~10 의미 있는 이름 의미 있는 이름 - 의도를 분명히 밝히기 - 의도를 분명히 하는 변수명을 짓는 것이 오래걸려도 그 이름을 지어 절약하는 시간이 더 많기 때문 - 그릇된 정보를 피하자 - 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하지 말자 (최대한 약어 피하기) - List와 Collection 구분 - 변수명에 List를 넣으려면 진짜 타입이 List인 경우에만 넣고 Collection인 경우 s를 붙혀준다. - 있는 사람이 차이를 알도록 의미 있게 구분하자 ex) productInfo vs productData => 어떤 차이가 있는지 알기 힘듬- 변수명에 타입을 넣지 말자 - 클래스 이름은 명사나 명사구가 적합하다 - 메서드 이름은 동사나 동사구가 적합하다. - 한 개념에 한 단어를 사용하라 ex) get f.. 이전 1 다음
