taetae98

창발적 설계로 깔끔한 코드를 구현하자 우리들 대다수는 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위 목록은 중요도 순이다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 문서로는 시스템을 완벽하게 설계했지만, 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면, 문서 작성을 위해 투자한 노력에 대한 가치는 인정받기 힘들다. 놀랍게도 "테스트 케이스를 만들고 계속 돌려라"라는 간단하고 단순한 규칙을 따르면 낮은 결합도, 높은 응집력, 객체 지향 방법론이 지향하는 목표를 저절히 달성하게 된다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진..

도시를 세운다면? 도시가 잘 돌아가는 이유. 수도 관리 팀, 전려 관리 팀, 교통 관리 팀 등 각 분야를 관리하는 팀이 있기 때문이다. 도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다. 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다. 소프트웨어 팀도 도시처럼 구성한다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 이 장에서는 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다. 시스템 제작과 시스템 사용을 분리하라 우선 제작은 사용과 아주 다르다는 사실을 명심하라. 소프트웨어 시스템은 준비 과정(애플리케이션 객체를 제작하고 의존성을 서로 연결하는) 런타임 로직(준비 과정 이후에 이어지는)을 분리해야 한다. 시..

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 깨끗한 클래스가 필요하다. 클래스 체계 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다. 정적 공개 상수 정적 비공개 변수 비공개 인스턴스 변수 공개 변수가 필요한 경우는 거의 없다. 변수 다음에는 공개 함수가 나오고, 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근 을 허용한..

1997년만 해도 TDD라는 개념을 몰랐다. 대다수가 단위 테스트란 프로그램이 '돌아간다'는 사실만 확인하는 일회성 코드에 불과했다. 직접 수동으로 테스트를 수행하고, 그로고 나서는 테스트 코드를 버렸다. 우리 분야는 지금까지 눈부신 성장을 이뤘지만 앞으로 갈 길은 여전히 멀다. 에자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 늘어나는 추세다. 하지만 테스트를 추가하려고 급하게 서두르는 와중에 제대로된 테스트 케이스를 작성해야 한다는 사실을 놓쳐버렸다. TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 ..

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 패키지를 사고, 오픈 소스를 이용하고, 사내 다른 팀이 제공하는 컴포넌트를 사용한다. 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 외부 코드 사용하기 패키지 제공자는 적용성을 최대한 넓히려 애쓴다. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하니까. 반면, 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이런 긴장으로 인해 시스템 경계에서 문제가 생긴다. 대표적인 예로 java.util.Map을 살펴보자. Map은 다양한 인터페이스로 많은 기능을 제공한다. Map이 제공하는 기능과 유연성은 확실히 유용하지만 그만큼 위험도 크다. Map에는 clear, set, remove 함수를 제공하기 때문에 Map을 ..

signingConfigs Android에서 Build를 할 때 Sining Key는 필수 사항이다. 물론 debug 모드로 빌드를 진행하면 Android Studio 내부에서 기본으로 제공하는 Key로 빌드를 하지만 앱을 배포하거나 BuildVariant를 release로 바꾸면 Key를 요구하며 때로는 debug Key를 개발자가 수정하는 경우가 생긴다. build.gradle 설정 signingConfigs 프로젝트에서 사용할 키를 signingConfig 함수를 통해 설정한다. build.gradle에 Key에 대한 정보를 바로 기입할 수 있지만, properties에 변수로 선언하여 사용할 수 있다. android { signingConfigs { debugKey { storeFile file(..

Build Variant 프로젝트를 진행할 때 테스트, SDK 지원 등 다양한 이유로 앱을 분기해서 관리할 경우가 있습니다. 여러 프로젝트를 만들고 코드를 공유해도 되지만 Gradle 설정으로 하나의 프로젝트에서 쉽게 관리할 수 있습니다. defaultConfig 다양한 BuildVariant에서 공통된 설정을 추가할 수 있습니다. android { defaultConfig { applicationId "com.taetae98.build" minSdk 31 targetSdk 32 versionCode 10000 versionName "1.00.00" buildConfigField "String", "BASE_URL", '"www.naver.com"' manifestPlaceholders["appLabel..

SourceSets 프로젝트를 진행하면 빌드 유형(debug, relase...), 제품 버전(유료, 무료...) 등 다양한 이유로 특정 부분의 소스 코드를 여러 버전으로 관리할 경우가 생깁니다. 간단하게 파일 복사나 Git Branch로 관리할 수 있지만 SourceSets을 사용하면 쉽게 관리할 수 있습니다. src/main 기본적으로 src/main에 코드를 작성하고 있습니다. main에는 모든 유형에 대해 공통적인 코드를 작성합니다. SourceSet 생성 app/src에 새로운 유형을 생성합니다. Gradle은 개발자가 src/main과 비슷한 방식으로 디렉토리를 구성할 것으로 예상합니다. 그렇기 때문에 다른 SourceSet을 생성할 때 src/main 같은 형식으로 디렉토리를 구성해야 합니다..