소스코드를 저장할 개념으로 학생때부터 git과 github을 꾸준히 사용했는데, 어느덧 거의 10년차가 되었다. 그렇다보니 주변에 git 에 대한 내용을 설명하는 경우가 많았는데, 사람들이 항상 혼란스러워 하는 부분을 이번 포스트 (어쩌면 시리즈)로 정리하고자 한다. Git vs. GitHub 가장 중요한 것은 git 과 github 의 차이부터 아는 것이다. 특히 수많은 IDE가 git의 기능을 지원하면서 github(또는 다른 서버)와의 연동 역시 당연하게 지원하다보니, 둘을 구분하지 못한 채 개발하는 경우가 많이 있었다. git 먼저, git은 온전히 "버전 관리 시스템(VCS; Version Control System)"이고 하나의 프로그램이다. 파일들의 변경 히스토리들을 기록하고 관리하는 것이 ..

1. 실제로 현재 git config 에 origin 이 없어서 발생하는 오류일 수 있다. 아래 명령어로 remote.origin 주소가 올바르게 설정되어있는 지 확인하고, git remote -v 없다면 아래와 같이 배포하고자 하는 git repository의 주소를 추가한다. git remote set-url origin https://.... 2. origin 설정은 분명 잘 되어있는데 안되는 경우 Failed to get remote.origin.url (task must either be run in a git repository with a configured origin remote or must be configured with the "repo" option). npm 과 관련한 모듈과 ..

정의 Dependency Inversion Principle (DIP; 의존관계 역전 원칙) 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 더 자세히는 이렇게 말한다. 상위 계층(정책 결정)이 하위 계층(세부 사항)에 의존하는 전통적인 의존관계를 반전(역전)시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다. 1. 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 2. 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다. 의존 관계가 많을수록 코드의 변경이 잦아지는 것은 당연하다. 변경할 곳이 많다는 의미는 코드를 파악하고 수정하는 일이 무척 어렵다는 뜻이다. 의존 관계에 신경을 쓰는 이유는 이런 부분..

정의 Interface Segregation Principle (ISP; 인터페이스 분리 원칙) 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 위반 사례 이 ATM기는 총 3개의 모듈을 가지고 있는데, 어떤 거래(transaction)에 대해서 입금(Deposit), 출금(Withdrawal), 송금(Transfer) 모듈을 각자 만들었다. 각 모듈은 전문화된 기능을 가지기 위해 분리되었지만, 무언가 이상하다. 입금 거래 모듈은 입금만 하면 되는데, 위 구조와 같다면 코드가 이럴것이다. public class DepositTransaction extends Transaction implements UI { @Override public void requestDepositAm..

정의 Liskov Substitution principle (LSP; 리스코프 치환 원칙) 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 어떤 모듈 S가 모듈 T의 하위 모듈이라면, 속성의 변경없이 T를 S(상위)로 교체할 수 있어야 한다고 한다. 즉, 부모 클래스와 자식 클래스가 일관되어야 한다는 뜻이다. 위반 사례 이를 위반하는 대표적인 사례로는 원-타원 문제 (또는 사각형-정사각형 문제)가 있다. class Rectangle { private int width; private int height; public void setWidth(int width){ this.width = width; } public void setHeight(int he..

SOLID 원칙들은, 소프트웨어 작업에서 프로그래머가 소스 코드를 읽기 쉽고 확장하기 쉽게 될 때 까지 리팩토링하여 코드 냄새를 없애기 위해 쓰기 좋은 지침이다. 정의 Open/Closed Principle (OCP; 개방-폐쇄 원칙) 소프트웨어 요소는 확장에는 열려 있으나, 변경에는 단혀 있어야 하다. 모듈 중 하나를 수정했는데, 그 모듈을 사용하는 모든 모듈의 코드를 수정하는 일이 있으면 안된다는 뜻이다. 조금만 떠올려봐도 얼마나 끔찍한 일인 지 알 수 있다. 확장에 대해 열려 있다. 이것은 모듈의 동작을 확장할 수 있다는 것을 의미한다. 애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있다. 즉, 모듈이 하는 일을 변경할 수 있다. 수정에 대해 닫혀 있..

SOLID 원칙들은, 소프트웨어 작업에서 프로그래머가 소스 코드를 읽기 쉽고 확장하기 쉽게 될 때 까지 리팩토링하여 코드 냄새를 없애기 위해 쓰기 좋은 지침이다. 정의 Single Responsibility Principle (SRP; 단일 책임 원칙) 하나의 클래스나 모듈은 단 하나의 책임만 가져야 한다. 하나의 함수가 여러 개의 일을 한다는 뜻은 예측 불가능하다는 의미이다. 예시 아주 단적인 예시로, 끝 원소를 제거를 하는 함수가 삭제되는 원소를 반환할 이유는 없다. 제거만 하면 된다. Element pop() { if (size < 1) throw "Empty"; size = size - 1; return array[size + 1]; // ? } 삭제되는 값을 얻고 싶다면, pop 하기 전에 끝자..

참고한 원문 Put your Android Studio on a diet How to make a deep clean of your Android Studio & Gradle junk files to fix up the mess. engineering.backmarket.com aar 내에 있는 클래스를 자꾸 인덱싱을 못 하길래 검색하다가 찾은 방법인데, 생각보다 유용해서 블로그로 옮긴다. 참고로 위 문제는 해결 못 했다. 🤔 요약 1) "Build -> Clean Project" 로 먼저 빌드된 파일들 삭제 2) "File -> Invalidate Chaces / Restart" 로 캐시 제거 (안드로이드 스튜디오가 다시 시작되면 gradle을 다시 읽고 처리하는 데 일단은 무시) 3) .gradle ..