Intro 동시성과 깔끔한 코드는 양립하기 어렵다. 스레드를 하나만 실행하는 코드는 짜기가 쉽다. 간략히 알아보자. 동시성이 필요한 이유? 동시성은 결합(coupling) 을 없애는 전략이다. 즉, 무엇(what) 과 언제(when) 를 분리하는 전략이다. 그래서 디버깅을 할 때 **정지점(breakpoint)**을 정한 후 어느 정지점에 걸렸는지 살펴본다. 서블릿은 EJB컨테이너 안에서 돌아가는데, 이들은 동시성을 부분적으로 관리한다. 각 서블릿 스레드는 다른 서블릿과 무관하게 돌아간다. 서블릿 모델이 제공하는 구조적 이점이 아주 크다. 하지만 작업 처리량(throughput) 개선이라는 요구로 인해 직접적인 동시성을 구현해야 한다. 미신과 오해 동시성은 향상 성능을 높여준다. 동시성은 때로 성능을 높여준다. 동시성을 구현해도 설계는 변하지 않는다. 무엇 과 언제 를 분리하면 시스템 구조가 크게 달라진다. 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. 어떻게 …

Intro 창발적? 이라는 단어를 처음 들었다. 구글에 검색해보니, 뜻은 다음과 같다. 창발적 설계로 깔끔한 코드를 구현하자 켄트 벡이 제시한 를 적용하면 SRP나 DIP와 같은 원칙을 적용하기 쉬워진다. 켄트 벡은 다음 규칙을 따르면 설계는 ‘단순하다’고 말한다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 어떠한 프로그램을 만들었을 때, 검증되지 않으면 무용지물이다. 검증되지 않은 프로그램은 절대 출시해서는 안 된다. 그렇기에 모든 테스트를 만들어야 하는데, SRP를 준수하면 단순해진다. 결합도가 높으면 테스트 케이스를 작성하기 어렵다. DIP를 적용하고 DI, 인터페이스, 추상화 등과 같은 도구로 결합도를 낮춘다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다. 단순한 설계 규칙 2 ~ 4: 리팩터링 리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 방법이라면 뭐…

Intro 도시를 세운다면? 도시는 적절한 추상화와 묘율화로 돌아간다. 그래서 큰 그림을 이해하지 않아도 개인과 개인이 관리하는 는 효율적으로 돌아간다. 소프트웨어도 똑같다. 깨끗한 코드는 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 이번엔 높은 추상화 수준, 즉 시스템 수준에서도 꺠끗함을 유지하는 방법을 알아보자! 시스템 제작과 시스템 사용을 분리하라 를 분리해야한다. 위와 같은 방법이 초기화 지연(Lazy Initialization) 혹은 계산 지연(Lazy Evaluation) 기법이다. 장점 실제로 필요할 때까지 객체를 생성하지 않으므로 불필요한 부하가 걸리지 않는다. 따라서 애플리케이션을 시작하는 시간이 빨라진다. 어떤 경우에도 null 포인터를 반환하지 않는다. 단점 getService 메서드가 MyServiceImpl과 생성자 인수에 명시적으로 의존한다. 의존성을 해결하지 않으면 컴파일이 안된다. MyServiceImpl이 무거운 객체라면 테스트 전용 객체(TES…

Intro 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 클래스 체계 표준 자바 관례에 따르면, 변수 목록이 가장 먼저 나온다. : , 상수 -> -> 비공개 인스턴스 변수 -> -> 즉, 추상화 단계가 순차적으로 내려간다. 그래서 신문처럼 읽힌다. 캡슐화 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 로 선언하거나 패키지 전체로 공개한다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. 클래스는 작아야 한다! 함수는 로 크기를 측정했다면, 클래스는 을 센다. 클래스 이름에 , , 등과 같이 모호한 단어가 있다면 클래스에다 여러 책임을 떠 안겼다는 증거다. 또한 클래스 설명을 , , , 을 사용하지 않고서 25단어 내외로 가능해야 한다. 단일 책임 원칙 은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. 큰 …

Intro 이 장에서는 단위 테스트에 대해 다룬다. 과거엔 드라이버 코드를 급조해 결과물이 나오는 것을 팀원들에게 보여줘야 했다. 그리고 버렸다. 하지만 현재는 애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 많아졌다. 그러던 중 많은 프로그래머들이 놓친 미묘한 사실을 알아가보자. TDD 법칙 세 가지 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세 가지 법칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다. 또한 매일 많은 양에 달하는 테스트 케이스가 나온다. 사실상 전부 테스트하는 테스트 케이스가 나온다. 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기 저자는 테스트 코드에 팀원들간 규칙…

Intro 우리가 시스템을 개발할 때 모두 직접 개발하지 않고, 패키지를 사던지 오픈소스를 이용한다. 또는 사내 다른 팀이 제공하는 컴포넌트를 사용한다. 이렇게 외부 환경과의 상호작용 방식을 정의하는 것이 라고 생각한다. 외부 코드 사용하기 인터페이스 제공자는 적용성을 최대한 넓히려 애쓴다. 인터페이스 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 여기서는 예시로 을 들고 있다. Sensor라는 객체를 담는 Map을 생성하고, Seonsor 객체가 필요한 코드는 Sensor 객체를 가져온다. 이 코드는 깨끗한 코드가 아니고, 의도도 분명히 드러나지 않는다. 를 사용하면 코드 가독성이 크게 높아진다. 하지만 이 방법도 ”Map가 사용자에게 필요하지 않은 기능까지 제공한다.“는 문제를 해결하지 못한다. 이렇게 하면 사용자는 제네릭스가 사용되었는지 여부를 신경 쓸 필요가 없다. Sensor 클래스 안에서 객체 유형을 관리하고 변환하기 때문이다. 이…

Intro 깨끗한 코드와 오류 처리는 확실히 연관성이 있다. 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 거의 불가능하다. 오류 코드보다 예외를 사용하라 예전에는 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였다. 이런 방법을 사용하면 호출자 코드가 복잡해진다. 그래서 오류가 발생하면 예외를 던지는 편이 낫다. 논리가 오류 처리 코드와 뒤섞이지 않으니까 말이다. 뒤섞였던 개념을 알고리즘에 따라 분리함으로써 각 개념을 독립적으로 살펴보고 이해할 수 있다. Try-Catch-Finally 문부터 작성하라 try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다. 여기서 생성자가 던지는 을 잡아낼 수 있다. 강제로 예외를 일으키는 테스트 케이스 작성 테스트를 통과하게 코드 작성 -> try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. 미확인(Unchecked) 예외를 …

Intro 변수를 으로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들기 위해서다. 그렇다면 왜 많은 개발자들이 함수와 함수를 당연하게 해 변수를 외부에 노출할까? 자료 추상화 더 나은 예시 변수를 private으로 선언하더라도 각 값마다 get함수와 set함수를 제공한다면 구현을 외부로 노출하는 셈이다. 구현을 감추려면 추상화가 필요하다. 더 나은 예시 인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다. 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 자료/객체 비대칭 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 제공한다. 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다. 절차 지향 코드의 장단점 객체 지향 코드의 장단점 객체 지향 코드에서 어려운 변경은 절차 지향 코드에서 쉬우며, 절차 지향 코드에서 어려운 변경은 객체 지향 코드에서 쉽다! 디미터 법칙 디미터 법칙은 잘 알려진 휴리스틱으로, 모듈은 자신…

Intro 깔끔하게 형식을 맞춰 코드를 짜야한다. 간단한 규칙을 정하고, 그 규칙을 착실히 따라야 한다. 팀으로 일한다면 팀 규칙을 따라야 한다. 필요하다면 도구도 활용하자. 형식을 맞추는 목적 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 맨 처음 잡아놓는 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. 적절한 행 길이를 유지하라 소스 코드는 얼마나 길어야 적당할까? 라는 질문에 이렇게 답한다. 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 신문 기사처럼 작성하라 이름은 간단하면서도 설명이 가능하게 짓는다. 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다. 개념은 빈 행으로 분리하라 생각 사이는 빈 행을 넣어 분리하자. 행 묶음…

Intro 코드로 의도를 표현하지 못했을 때, 즉 실패했을 때 우리는 주석을 사용한다. 하지만 주석은 프로그래머들이 유지보수하기는 현실적으로 불가능하다. 따라서 우리는 주석이(간혹 필요할지라도) 필요 없는 방향으로 애너지를 쏟아야 한다. 주석은 나쁜 코드를 보완하지 못한다 코드로 의도를 표현하라! 주석으로 의도를 표현한 경우 코드로 의도를 표현한 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다. 좋은 주석 1) 법적인 주석 2) 정보를 제공하는 주석 이왕이면 시각과 날짜를 변환하는 클래스를 만들어 코드를 옮겨주면 더 좋고 더 깔끔하겠다. 3) 의도를 설명하는 주석 구현을 이해하게 도와주는 선을 넘어 결정에 깔린 의도까지 설명할 수 있다. 4) 의미를 명료하게 밝히는 주석 테스트 코드에서 사용할 수 있다. 5) 결과를 경고하는 주석 프로그램 효율을 높이기 위해 정적 초기화 함수를 사용하려던 열성적인 프로그래머가 주석 때문에 실수를 면한다. 6) TODO 주석 앞으로 할 …

Intro 추상화 수준이 너무 다양하고 코드가 길다. 두 겹으로 중첩된 if문은 이상한 플래그를 확인하고, 이상한 문자열을 사용하며, 이상한 함수를 호출한다. 코드를 이해하기가 어렵다. 하지만 매서드 몇 개를 추출하고, 이름 몇 개를 변경하고, 구조를 조금 변경하면 파악하기 어려웠던 정보가 쉽게 드러난다. 작게 만들어라 100줄 ~ 300줄 함수도 있고 20줄 ~ 30줄 함수도 있다. 최대한 작으면 작을 수록 좋다. 심지어 2줄 ~ 4줄인 함수도 있다. 줄일 수 있다면 줄이는게 좋다. 블록과 들여쓰기 if문 / else문 / while 문 등에 들어가는 블록은 한 줄이어야 한다. -> 대개 여기서 함수를 호출한다 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 한 가지만 해라! 우리가 함수를 만드는 이유는 큰 개념을 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서이다. 그렇기 때문에 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면, …

Intro 나는 평소에 네이밍을 하는데 어려움이 있었다. 여러 컨벤션들이 있었지만, 내가 옆에 두고 하지 않는 이상 좋은 네이밍을 하기엔 어려웠다. 아직은 경험이 없고 익숙하지 않아서 일까?… 그래서 더더욱 이번 챕터를 재미있게 봤다. 의도를 분명히 밝혀라 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. 여기서 d는 아무 의미도 드러나지 않는다. 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다. 그러면서도 영어 동사의 표현을 잘 알아야겠다는 생각이 든다. 다음 코드가 무엇을 하는지 살펴보자. 복잡한 문장은 없다. 공백과 들여쓰기도 적당하다. 변수는 세개, 상수는 두 개뿐이다. 문제는 코드의 단순성이 아니라 코드의 함축성이다. 즉, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다. theList에 무엇이 들었는가? theList에서 0번째 값이 어째서 중요한가? 값 4는 무슨 의미인가? 함수가 반환하는 리스트 list1을 어떻게 사용하는가? 그렇다면 …

Intro 회사에서 유지보수를 하다가 끔찍한 프로젝트를 보게 되었다. 변수명과 클래스 명은 모두 1,2,3 혹은 A, B, C로 구분되어 있었다. 이런 이유 때문에 유지보수 하는 일이 너무 힘들었다. 그래서 어떻게 하면 나는 이런 코드를 짜지 않을 수 있을까? 어떻게 하면 이 코드를 좋은 코드로 바꿀 수 있을까?라는 의문점이 생겼다. 그래서 미루고 미뤄왔던 클린코드를 읽어보려고 한다. 코드가 존재하리라 요즘 기술이 발전함에 따라 코드를 자동으로 생성해주는 기술들이 생겨나기 시작했다. 그럼에도 저자는 코드가 사라질 가망이 없다고 한다. 나쁜 코드 80년대 후반 킬러 앱 하나를 구현한 회사를 이야기하면서 시작한다. 회사가 망했는데, 그 원인은 바로 나쁜 코드 탓이었다. 나쁜 코드에 발목이 잡혀 고생하는 것을 고행(Wading)이라 부른다. 나쁜 코드로 치르는 대가 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다 팀은 재설계를 요구한다. 새로운 프로젝트를 시작하기 때문에 모두가 합류…

Intro 스마트해썹 공정 프로그램을 개발하다가 보고서 조회 속도가 너무 느리다는 걸 발견했다. 조회 조건을 해와서 그런가 싶었지만, 단순히 조회하려는 내용 자체를 가져오는데 오래 걸렸다. 로 분석한 결과 다음과 같았다. 쿼리 부분이 포함되어 있어서 중간은 생략했다. 여기서 가장 중요하게 봐야할 부분은 이다. 이렇게 때문에 조회 속도가 나오지 않았던 것이다. 그래서 나는 서브쿼리를 조인으로 풀어가고, 필요없는 컬럼은 조회하지 않았다. 또한 이미 걸려있는 인덱스를 적절히 활용했다. 내가 쿼리를 수정하고 난 다음 성능을 분석한 결과는 다음과 같다. 부분을 보면 어떤가? 119.416 ms 정도 소요됐다. 단순히 나누기 연산을 해봐도 17배 정도 빨라진 셈이다. 여러번 성능 테스트를 해본 결과 약 20배 정도 빨라졌다는 것을 알 수 있었다. 그러면서 의심이 들었다… 내가 잘 짰나..? SQL을 보니 연산 작업으로 인해 코드가 길고 복잡했다. 이렇게 가져가면 너무나 …

Intro 코드를 보다가 Redirect Strategy 부분의 코드를 보게 되었다. 평소에 알던 리다이렉트는 그저 서버가 어떤 URL로 강제로 View를 보여주는 것이라고만 생각해왔다. 하지만 이번 공부를 통해 조금 다른 부분까지 알게 되어서 정리해보고자 한다. 멱등성 PRG패턴을 이야기하는데 있어서 가장 먼저 이야기해야하는 것은 멱등성이다. 멱등성이란, 연산을 여러번 적용하더라도 결과가 달라지지 않는 성질을 의미한다. 그렇다면 웹에서는 , , , 는 멱등성을 가진다라고 말할 수 있다. 하지만 는 멱등성을 가지지 않는다. 예를 들어보면, 은 얼마든지 자주 호출해도 같은 결과를 나타내지만, 게시글을 등록하는 를 연달아 호출하면 호출한 횟수만큼 게시글이 등록된다. 하지만 REDIRECT가 아니라 FORWARD로 처리할 경우 새로고침 시 게시글 작성/주문이 중복해서 처리될 수 있다. PRG 패턴 위와 같은 이유로 PSG 패턴은 꼭 필요하다. 그렇다면 더 자세히 알아보자. 은 웹 개발 …

Intro 저번 Google Sheets API에 이어서, 이번엔 Google Apps Script이다. 난 시트 내에서 계산식이 자동으로 다음줄에도 계산이 되어야한다는 요구사항을 받았다. 그래서 여러 방법을 고민하기 시작했다… Google Sheets 내의 함수나 기능 활용하기 Java/Javascript 로 가져와서 계산식을 적용하고 다시 뿌려주기 Apps Script 활용하기 1번은 찾지 못했다. 2번은 작성해야 하는 코드가 많아서 번거로웠다. 그래서 나는 3번인 Apps Script를 활용하기로 결정했다. 앱 스크립트(App Script) 는 구글 워크스페이스 플랫폼에서 가벼운 애플리케이션 개발을 위해 구글이 개발한 스크립팅 플랫폼이다. 난 이걸 활용하여 자동으로 계산식에 이어서 계산이 되는 기능을 구현하고자 한다. 하지만 난 Apps Script가 처음이기 때문에 어떻게 접근해야할 지 몰랐다. 그러다 팀장님이 귀뜸해주신 말씀에 도움을 얻어서 매크로를 활용했다. 매크로를 기…

Intro 회사에서 수습사원을 떼고, 첫 업무가 주어졌다!!! 유관부서에서 Google Sheets로 대시보드처럼 사용하고 있었는데, Google Sheets에서 편집한게 우리가 사용하는 웹 사이트에도 보였으면 좋겠다는 요구였다. 정리해보자! Google Sheets가 DB에 연동이 되어야한다. Google Sheets에서 계산식이 자동으로 적용되어야 한다. Google Sheets에서 변경된 내용은 웹사이트에도 반영되어야 한다. 웹사이트에서 변경한 내용이 Google Sheets에 반영되어야 한다. 적용된 계산식은 Google Sheets에만 보여야 한다. 많은 고민이 있었다. 어떻게 해야 Google Sheets를 내 프로젝트에 가져올 수 있을까? 그리고 그걸 DB에 연동할 수 있을까? 나는 비용을 발생시켜서도 안되고, 그렇다고 제대로 만들지 않을 수 없다. 내가 고민한 방법은 다음과 같다. PI를 활용하기 -> 비용이 나갈 수 있기에 후 순위에 두었다. 크롤링 - 시트 열람하…

앞서서 저희 회사에서 api 개발하는 것을 보며, 저도 언젠가 저렇게 멋진 API를 만들겠다고 다짐했습니다. 그러기 위해서 RESTful API에 대해서 공부를 시작했습니다. 먼저 API 명세서를 작성하는 방법에 대해서 알아보았습니다. 찾아본 여러 방법 중에서 가장 자료가 많았던 것은 Swagger와 Spring REST Docs입니다. 둘이 어떻게 다르고 어떤 특징이 있는지 알아보겠습니다. 그 전에! OAS가 뭔지는 알아야 합니다. 블로그를 볼 때마다 나와서 찾아봐야 했거든요.. OAS(Open API Specification) OAS는 “개발자가 RESTful API를 쉽게 관리하고 사용할 수 있게 도와주는 표준 명세 작성 방식”이라고 이해하면 됩니다. JSON, YAML 형식으로 작성된다는 것을 알고 다음 코드를 봅시다. 자세한 형식은 공식 문서를 참고해주세요. Swagger Swagger는 Controller에 몇 가지의 어노테이션을 달기만 해도 API 문서가 만들어집…

Intro 최근 들어보면 다들 MSA MSA MSA 하는 것 같다. 도대체 MSA가 뭘까? 강의를 들어보려니, 너무나 가격대가 비쌌다. 다양한 시스템을 각자가 만들어서 합쳐버리는건가? 난 잘 몰랐다. 그러다 우리 회사에서 미팅을 했을 때, 난 호기심이 생겼다. 우리 회사는 MA도 MSA도 아닌 SOA를 도입하려고 한다. 이 세 아키텍처의 차이점은 무엇이고, 왜 우리는 SOA를 도입하려고 하는가? SOA(Service Oriented Architecture) 서비스 지향 아키텍처란? 기업의 소프트웨어 인프라인 정보시스템을 공유와 재사용이 가능한 서비스 단위나 컴포넌트 중심으로 구축하는 정보기술 아키텍처이다. ESB(엔터프라이즈 서비스 버스)로 중앙 집권식이다. 장점 비즈니스 민첩성 향상, 시장 출시 속도 개선 요구사항 반영이 수월하고 대응이 신속해진다. 신규 시장에서 레거시 기능을 활용하는 능력 기존 기능을 사용할 수 있고 이를 신규 환경과 시장으로 확장할 수 있다. 하나의 DB…