산 넘어 산 개발일지

창발성 : 창발또는 떠오름 현상은 하위 계층에는 없는 특성이나 행동이 상위 계층에서 자발적으로 돌연히 출현하는 현상이다. 왜 이번 챕터의 제목이 창발성인지는 잘 모르겠다. 전체적으로 내용은 코드를 단순하게 하기 위한 내용을 요약한 것이었다. 주로 지금까지 한 내용을 다시 간결하게 되짚어 보는 단계인 것 같다. 굳이 창발성과 관련이 있는 것이라면 TEMPLATE METHOD 정도가 아닌가 싶다. 단순한 코드 법칙 모든 테스트를 실행한다. "테스트가 가능한 시스템" 테스트가 가능한 시스템을 만드는 과정 속에서 자연스럽게 소프트웨어의 품질도 높아진다. 테스트가 가능해야 검증이 가능하다. 낮은 결합도 + 높은 응집도 결합도는 낮춤으로써 테스트와 유지보수에 용이하도록 설계하고, 응집도는 높인다. SRP 지키기, ..

시스템에서 가장 중요한 것은 유지보수이다. 유지보수에 가장 중요한 것은 영역(도메인)간의 분리이다. 따라서 우리는 코딩을 할 때 각 모듈들이 서로에게 끼치는 영향을 최소화 할 수 있도록 코드를 짜야 하고, 이를 위해서 등장한 여러 기법들을 알 필요가 있다. 주요 내용 관심사 분리 애플리케이션이나 클래스와 같은 모듈이 하나의 관심사만 가지도록 분리하는 것(SRP와 비슷) 이 관심사의 영역을 뚜렷하게 나누면 서로의 영역에 영향을 주지 않으므로 내가 원하는 부분만 수정할 수 있어서 Main 분리 객체나 모듈의 생성과 관련된 코드는 모두 main 혹은 main에서 호출하는 모듈이 담당한다. 즉 시스템의 다른 모듈에서는 모든 객체가 이미 생성되었고 의존성이 연결되어 있다고 가정하는 것이다. 추상 팩터리 패턴 나머..

객체지향 프로그래밍의 중심은 당연히 클래스이다. 클래스를 얼마나 체계적으로, 그리고 깔끔하게 설계하느냐에 따라서 코드의 품질을 따질 수 있다고 생각한다. 객체지향에서, 특히 자바에서 클래스 설계 방식은 굉장히 다양하다. 그 중 이번 챕터에서 나온 것들만 지키려고 노력해도 충분히 깔끔한 코드가 나올 것 같다. 클래스 구성 구성 순서 static -> non-static public -> private 캡슐화 변수와 유틸리티 함수는 최대한 공개하지 않는 것이 좋다. 이 캡슐화를 깨는 것은 어디까지나 도저히 방법이 없을 때 최후의 수단으로 사용해야 한다. 다만 테스트 코드를 위해서는 protected 로 공개해줄 수도 있다. 책임 단일책임원칙 (SRP, Single Responsibility Principle..

TDD는 이미 자주 사용하는 개발 방식이라고 한다. 그만큼 그 가치를 사람들에게 인정 받았고, 개발자라면 항상 TDD로 개발하지는 않더라도 한 번쯤은 사용해봐야 한다고 생각한다. 그러나 Clean Code책에서 다룬 TDD 내용은 극소수에 불과했다. TDD를 따로 사용한 적이 없어 코드 리뷰는 생략했다. 올해 여름에 TDD책을 읽고 따로 정리를 할 예정이다. 포인트 TDD 법칙 실패하는 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 통과하면서 실행은 실패하는 정도로만 작성한다. 실제 코드는 현재 테스트를 통과할 정도로만 작성한다. 장점 실제 코드를 변경할 때 버그에 대한 두려움을 없애주므로 더 자유롭고 유연한 재사용성을 보장한다. 방식 given-when-then 형식 given : 테스..

외부 API는 내가 필요한 기능을 쉽고 빠르게 만들 수 있도록 도와주기 때문에 안쓰이는 곳을 찾아보기 힘들다. 그러나 무분별한 사용은 내 프로그램을 외부 API에 지나치게 의존하도록 만들 여지가 있다. 그렇다고 아예 사용을 안할 순 없으니 정말 필요한 부분만 사용하되, 사용하는 부분도 내 프로그램과 호환이 잘 되도록 사용할 필요가 있다. 경계(혹은 경계 인터페이스)란 구현된 클래스 중 외부 API나 다른 클래스에서 사용하면서 그 내부 구조가 바뀌어 시스템 전체에 영향을 미칠 수 있는 부분을 말한다. 내 코드 돌아보기 학습 테스트의 부재 외부 API를 가져오면서 단순히 메서드에 대해서만 조사를 하고 그대로 사용했다. 외부 API에 대한 어떠한 학습 테스트도 거치지 않았으므로 이에 대한 높은 이해를 바탕으로..

프로그래밍 초기 시절에는 간단한 연산을 위해 프로그램을 사용했으므로 절자 지향 프로그래밍이 대세였다. 그러나 점차 기업이나 정부와 같이 규모가 큰 영역에서도 프로그래밍이 사용되기 시작하자 절차 지향 프로그래밍만으로는 유지보수가 어려웠다. 이를 용이하게 하고자 객체별로 체계화한 것이 객체지향 프로그래밍이다. 그러나 단순히 객체만 사용한다고 해서 객체 지향 프로그래밍이라고 하기에는 무리가 있다. 객체간의 역할을 분명히 하고, 이후 유지보수가 쉽도록 코드를 짜는 것이 중요하다. 내 코드 돌아보기 1. get/set 함수 자료구조이므로 get/set함수 없이 그저 변수만 공개했다. 코틀린의 좋은 점인 것 같다. data class를 따로 제공함으로써 철저한 자료구조 클래스로만 사용하는 것을 강제한다. 2. 디미..

코드에도 지켜야 할 형식이 있다. 형식은 어떻게 하면 타인이 보기에 이해하기 쉬울지에 대한 고민에서 시작된다. 아마 클린 코드에 대한 모든 시작점이 이 고민일 것이다. 클린 코드에서의 형식은 보통 위에서 아래로 읽을 때 고차원 -> 저차원 으로 흘러가고, 비슷한 개념을 공유하는 부분끼리는 최대한 붙어 있다. 내 코드 돌아보기 1. 세로 밀집도 onCreateView()라는 함수가 두 함수를 호출하여 사용하는데, 호출하는 함수 다음에 호출을 당하는 함수들이 차례대로 배치가 되어서 쉽게 읽힌다. (종속 함수) 2. 고차원 -> 저차원 밑으로 갈 수록 저차원 함수를 정의하여 세부 동작을 정의했지만 맨 위에서 좀 더 고차원적인 추상화로 설명을 넣어줬으면 좋았을 것 같다. 이 클래스가 어떤 클래스인지 알기 위해서..

코드를 하나의 이야기로 풀어간다는 관점에서 봤을 때 함수는 그 이야기 속 하나의 문장이 될 수 있겠다. 즉 클래스, 변수라는 단어들에 대해 함수는 구체적으로 어떤 동작이 이루어지는지를 나타내는 것이다. 따라서 함수를 읽기 쉽게 쓰는 것, 즉 가독성이 높게 쓰는 것이 클린 코드의 첫 걸음일 것이다. 내 코드 돌아보기 함수의 크기 및 추상화 onClick()에서는 추상화 수준을 유지하려는 노력은 보여지진다. 그러나 마지막 if문을 하나의 함수로 표현했다면 더 좋았을 것 같다. checkBlankException() : if문 안을 함수로 표현할 수 있었을 것 같다. function 이름은 checkBlankException이지만 그 안에 구체적으로 View의 내용을 바꾸는 내용이 들어가있으므로 이를 다른 함..