코드

import java.util.*;
import java.util.stream.IntStream;

class 격자판최대합 {	
	public static void main(String[] args){
		int max = Integer.MIN_VALUE;
		int n = 10;
		
		int[][] arr = IntStream.range(0, n)
				               .mapToObj(index->{
			    	               return new Random().ints(n, 1, 100)
			    			                          .toArray();
			                   }).toArray(int[][]::new);
		prettyPrint(arr);
		
		int rowSum, colSum, cSum1=0,cSum2=0;
		
		for(int i= 0; i<n; i++) {
			rowSum=0;
			colSum=0;
			//핵심 같은 반복문이라도 구조가 유사하니
			//j , i 위치만 바꾸면 한방에 해결
			//구조 i==j , i+j == length-1 , [고정][순회], [순회],[고정]
			for(int j= 0; j<n ;j++) {
				rowSum += arr[i][j]; //같은 행 합
				colSum += arr[j][i]; //같은 열 합
			}
			cSum1+=arr[i][i];     //좌상우하 대각선 for문 1개만 필요
			cSum2+=arr[i][n-1-i]; //우상좌하 대각선
			
			// 내가 틀린 부분 기존 값이 신규 값보다 더 클 수 있다는 것을 간과
//			max = rowSum<colSum ? colSum : rowSum;
			max = max < rowSum ? rowSum 
			    : max < colSum ? colSum : max ;
		}
		max = max < cSum1 ? cSum1 
			: max < cSum2 ? cSum2 : max;
		
		System.out.println(max);
		
	}
	static void prettyPrint(int[][] arr, boolean isIndex) {
		for(int i=0;i<arr.length;i++) {
			for(int j=0;j<arr[i].length;j++) {
				if(isIndex) System.out.printf("%2d,%2d ", i,j);
				else System.out.printf("%2d" + (j==arr[i].length-1? "":",") ,arr[i][j]);
			}
			System.out.println(isIndex?"\n":"");
		}
	}
	static void prettyPrint(int[][] arr) {
		prettyPrint(arr, false);
	}
}

결과

 

92,70,45,49,49,56,60,93,58,72
20,49,49,71,50,25,41,70,86,89
29,33,69,31,11,33,57, 4,90,75
74,14,22,60,33,42,14,94,37,15
70,64,12,17, 6,23,90,52,65,45
96,90, 5,53,84,50,32,61,70,68
84,74,80,79,83,92, 6,32, 2,22
95,14,81,26,84, 9,25,55,89,93
51,84,84,66,11,46,20,33,92,87
97,12,89,13, 9,10,16,11,72,32
661

정사각형 배열의 경우 i, j 길이가 같기 때문에 [i][j] ,  [j][i] 이렇게 바꿔주면 행 합, 열 합을 구할 수 있다.

대각선의 경우, 인덱스가 같으면 좌상우하 대각선이다.

우상좌하 대각선의 경우 j 자리에  "크기-1-i" 를 하면 값을 쓰면 된다.

다른 방법으론 "i+j == 크기-1"   식을 사용하면 된다

 
 

import java.util.*;
import java.util.stream.IntStream;

class 격자판최대합 {
public static void main(String[] args){
int max = Integer.MIN_VALUE;
int n = 10;

int[][] arr = IntStream.range(0, n)
.mapToObj(index->{
return new Random().ints(n, 1, 100)
.toArray();
}).toArray(int[][]::new);
prettyPrint(arr);

int rowSum, colSum, cSum1=0,cSum2=0;

for(int i= 0; i<n; i++) {
rowSum=0;
colSum=0;
//핵심 같은 반복문이라도 구조가 유사하니
//j , i 위치만 바꾸면 한방에 해결
//구조 i==j , i+j == length-1 , [고정][순회], [순회],[고정]
for(int j= 0; j<n ;j++) {
rowSum += arr[i][j]; //같은 행 합
colSum += arr[j][i]; //같은 열 합
}
cSum1+=arr[i][i]; //좌상우하 대각선 for문 1개만 필요
cSum2+=arr[i][n-1-i]; //우상좌하 대각선

// 내가 틀린 부분 기존 값이 신규 값보다 더 클 수 있다는 것을 간과
// max = rowSum<colSum ? colSum : rowSum;
max = max < rowSum ? rowSum
: max < colSum ? colSum : max ;
}
max = max < cSum1 ? cSum1
: max < cSum2 ? cSum2 : max;

System.out.println(max);

}
static void prettyPrint(int[][] arr, boolean isIndex) {
for(int i=0;i<arr.length;i++) {
for(int j=0;j<arr[i].length;j++) {
if(isIndex) System.out.printf("%2d,%2d ", i,j);
else System.out.printf("%2d" + (j==arr[i].length-1? "":",") ,arr[i][j]);
}
System.out.println(isIndex?"\n":"");
}
}
static void prettyPrint(int[][] arr) {
prettyPrint(arr, false);
}
}

 

'자료구조&알고리즘 > 자바(Java) 알고리즘 문제풀이 : 코딩테스트 대비' 카테고리의 다른 글

두배열합치기  (0) 2022.11.17
중복문자제거  (0) 2022.11.14
숫자뒤집기  (0) 2022.11.10
봉우리  (0) 2022.11.09
등수구하기  (0) 2022.11.05

동기화하는 메서드 사이에 존재하는 의존성을 이해하라

동기화하는 메서드 사이에 의존성이 존재하면 동시성 코드에 찾아내기 어려운 버그가 생긴다.

자바는 개별 메서드를 보호하는 synchronized라는 개념을 지원한다. 하지만 공유 클래스 하나에 동기화된 메서드가 여럿이라면 구현이 올바른지 확인해야 한다.

 

권장사항: 공유 객체 하나에 메서드 하나만 사용하기

 

  • 공유 객체 하나에 여러 메서드가 필요한 상황은 다음 세 가지 방법을 고려

클라이언트에서 잠금 - 클라이언트에서 번째 메서드 호출하기 전에 서버를 잠근다. 마지막 메서드를 호출할 때까지 잠금을 유지한다.

서버에서 잠금 - 서버에다 "서버를 잠그고 모든 메서드를 호출한 잠금을 해제하는" 메서드를 구현한다. 클라이언트는 메서드를 호출한다.

연결(Adapted)서버 - 잠금을 수행하는 중간 단계를 생성한다. '서버에서 잠금' 방식과 유사하지만 원래 서버는 변경하지 않는다.

동기화하는 부분을 작게 만들어라

synchronized 키워드를 사용하면 락을 설정한다. 같은 락으로 감싼 모든 코드 영역은 번에 스레드만 실행이 가능하다. 락은 스레드를 지연시키고 부하를 가중시킨다. 따라서 남발하면 안된다.

반면, 임계 영역은 반드시 보호해야반드시 한다. 코드를 때 임계 영역 수를 최대한 줄여야 한다.

거대한 임계영역 하나로 구현하라는 말이 아니다. 작고 적게.

올바른 종료 코드는 구현하기 어렵다

영구적으로 돌아가는 시스템 구현 방법과 잠시 돌다 깔끔하게 종료하는 시스템 구현하는 방법은 다르다

깔끔하게 종료하는 코드는 구현이 어렵다. 가장 흔한 이유는 데드락이다. 스레드가 절대 오지 않을 시그널을 기다린다.

부모 스레드가 자식 스레드 여러 만든 모두가 끝나기를 기다렸다 자원을 해제하고 종료한다고 하면, 자식 스레드 하나가 데드락에 걸렸다면? 부모 스레드는 영원히 기다린다.

 

이번에는 유사한 시스템이 사용자에게서 종료하라는 지시를 받았다고 가정. 부모 스레드는 모든 자식 스레드에게 작업을 멈추고 종료하라는 시그널을 전달한다. 그런데 자식 스레드 개가 생상자/소비자 관계라면? 생산자 자식 스레드는 금세 종료하지만 소비자 자식 스레드는 생상자 스레드에서 오는 메시지를 기다린다면? 생산자에서 메시지를 기다리는 소비자 스레드는 차단 상태에 있으므로 종료하라는 시그널을시그널을 못 받는다. 소비자 스레드는 생산자 스레드를 영원히 기다리고, 소비자 스레드 부모 스레드는 영원히 기다린다.

 

권장사항: 종료 코드를 개발 초기부터 고민하고 동작하게 초기부터 구현하라. 생각보다 오래 걸린다. 생각보다 어려우므로 이미 나온 알고리즘을 검토하라

 

스레드 코드 테스트하기

현실적으로 불가능. 테스트가 정확성을 보장하지 않는다. 그럼에도 충분한 테스트는 위험을 낮춘다.

 

권장사항: 문제를 노출하는 테스트 케이스를 작성하라. 프로그램 설정과 시스템 설정과 부하를 바꿔가며 자주 돌려라. 테스트가 실패하면 원인을 추적하라. 다시 돌렸더니 통과하더라는 이유로 그냥 넘어가면 절대로 안된다.

 

고려할 사항이 아주 많다는 뜻이다. 아래에 가지 구체적인 지침을 제시한다.

  • 말이 되는 실패는 잠정적인 스레드 문제로 취급하라
  • 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자.
  • 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 있도록 스레드 코드를 구현하라
  • 다중 스레드를 쓰는 코드 부분을 상황에 맞춰 조정할 있게 작성하라
  • 프로세서 수보다 많은 스레드를 돌려보라
  • 다른 플랫폼에서 돌려보라
  • 코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해 보라

말이 되는 실패는 잠정적인 스레드 문제로 취급하라

다중 스레드 코드는 때때로 말이 안 되는 오류를 일으키기 때문이다.

저자들을 포함해서 대다수 개발자는 스레드가 다른 코드와 교류하는 방식을 직관적으로 이해하지 못한다. 이유는 스레드 코드에 잠입한 버그는 수천~수백만 번에 번씩 드러나, 도저히 실패를 재현하기 어렵기 때문이다. 다만, 이런 문제를 일회성 문제로 취급하면취급하면 안 된다. 그냥 일회성 문제는 존재하지 않는 개념이라 생각하라. 계속 일회성 문제를 무시하면 잘못된 코 드위에 코드가 계속 쌓인다.

 

권장사항: 시스템 실패를 '일회성'이라 치부하지 마라.

다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자

당연한 소리지만 다시 한번 강조한다. 스레드 환경 밖에서 코드가 제대로 도는지 반드시 확인한다. 일반적인 방법으로, 스레드가 호출하는 POJO 만든다. POJO 스레드를 모른다. 따라서 스레드 환경 밖에서 테스트가 가능하다.

 

, 순차 코드도 검증 안된 상태에서 다중 스레드를 동시에 테스트하면 가뜩이나 어려운 어려워진다.

 

권장사항: 스레드 환경 밖에서 생기는 버그와 스레드 환경에서 생기는 버그를 동시에 디버깅하지 마라. 먼저 스레드 환경 밖에서 코드를 올바로 돌려라.

 

다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 있게 작성하라

적절한 스레드 개수 파악은 상당한 시행착오가 필요. 그래서 처음부터 다양한 설정으로 프로그램의 성능 측정 방법을 강구해야 한다. 스레드 개수를 조율하기 쉽게 코드를 구현해 프로그램이 돌아가는 도중에 스레드 개수를 변경할 방법도 고려한다. 나아가 프로그램 처리율과 효율에 따라 스스로 스레드 개수를 조율하는 코드도 고민한다

프로세서 수보다 많은 스레드를 돌려보라

시스템이 스레드를 스와핑 할 때도 문제가 발생한다. 스와핑을 일으키려면 프로세서 수보다 많은 스레드를 돌린다. 스와핑이 잦을수록 임계 영역을 빼먹은 코드나 데드락을 일으키는 코드를 찾기 쉬워진다

 

 

다른 플랫폼에서 돌려보라

단지 운영체제마다 스레드를 처리하는 정책이 달라 결과가 달라질 있다. 다중 스레드 코드는 플랫폼에 따라 다르게 돌아간다. 따라서 코드가 돌아갈 가능성이 있는 플랫폼 전부에서 테스트를 수행해야 한다.

 

권장사항 : 처음부터 그리고 자주 모든 목표 플랫폼에서 코드를 돌려라

코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해 보라

스레드 코드는 오류를 찾기 쉽지 않다. 간단한 테스트로는 버그가 드러나지 않는다. 버그가 달만에 나타날 수도 있다.

스레드 버그가 산발적이고 우발적이고 재현이 어려운 이유는 코드가 실행되는 수천 가지 경로 중에 아주 소수만 실패하기 때문이다.

드물게 발생하는 오류를 자주 일으킬 방법은 없을까? 보조 코드를 추가해 코드가 실행되는 순서를 바꿔준다.

예를 들어 Object.wait(), Object.sleep(), Object.yield(), Object.priority() 등과 같은 메서드를 추가해 코드를 다양한 순서로 실행한다.

메서드는 스레드가 실행되는 순서에 영향을 미친다. 따라서 버그가 드러날 가능성도 높아진다.

  • 코드에 보조 코드를 추가하는 방법은 두 가지

직접 구현하기

자동화

직접 구현하기

코드에다 직접 wait(), sleep(), yield(), priority() 함수를 추가

특별히 까다로운 코드를 테스트할 적합

yield() 삽입하면 코드가 실행되는 경로가 바뀐다. 그래서 버그를 발견할 확률이 증가한다. , yield()때문이 아니라 원래 있던 버그가 발견된 것이다.

 

방법의 문제점

  • 보조 코드 삽입할 적정 위치 선정
  • 어떤 함수를 어디서 호출해야 적당한지
  • 배포 환경에 보조 코드를 그대로 남겨두면 프로그램 성능 저하
  • 무작위적, 버그 발견이 확률임

 

스레드를 전혀 모르는 POJO 스레드를 제어하는 클래스로 프로그램을 분할하면 보조 코드를 추가할 위치 찾기가 쉬워진다.

자동화

AOF(Aspect-Oriented Framework), CGLIB, ASM 등과 같은 도구를 사용

ThreadJigglePoint.jiggle() 호출은 무작위로 sleep이나 yield 호출한다. 때론 아무 동작도 하지 않는다

ThreadJigglePoint클래스를 가지로 구현하면 편리하다

하나 jiggle() 메서드를 비워두고비워두고 배포 환경에서 사용

무작위로 nop(무동작), sleep, yield 등을 테스트 환경에서 수행

테스트 환경에서 두 번째 방법으로 수천번 통과했다면 나름 만큼 했다고 말해도 된다. 복잡한 방법이 있지만, 어렵다면 방법이 합리적인 대안이다

 

IBM 개발한 ConTest라는 도구가 있다. 위와 같은 방식의 테스트를 지원하지만 복잡하다

 

코드를 흔드는 이유는 스레드를 매번 다른 순서로 실행하기 위해서다. 좋은 테스트 케이스와 흔들기 기법은 오류가 드러날 확률을 크게 높여준다.

 

권장사항: 흔들기 기법을 사용해 오류를 찾아내라.

결론

다중 스레드 코드는 올바로 구현하기 어렵다. 간단한 코드가 여러 스레드와 공유 자료를 추가하면서 악몽으로 변한다

 

먼저, SRP를준수한다. POJO 사용해 스레드를 아는 코드와 스레드를 모르는 코드를 분리한다. 스레드 코드를 테스트할 때는 전적으로 스레드만 테스트한다, , 스레드 코드는 최대한 집약되고 작아야 한다

 

동시성 오류를 일으키는 잠정적인 원인을 철저히 이해한다.

여러 스레드가 공유 자료를 조작하거나 자원 풀을 공유할 동시성 오류가 발생한다.

루프 반복을 끝내거나 프로그램을 깔끔하게 종료하는 경계 조건의 경우가 까다로우므로 특히 주의한다.

 

사용하는 라이브러리와 기본 알고리즘을 이해한다. 특정 라이브러리 기능이 기본 알고리즘과 유사한 어떤 문제를 어떻게 해결하는지 파악한다.

 

보호할 코드 영역을 찾아내는 방법과 특정 코드 영역을 잠그는 방법을 이해한다.

잠글 필요가 없는 코드는 잠그지 않는다.

잠긴 영역에서 다른 잠긴 영역을 호출하지 않는다.

그러려면 공유하는 정보와 공유하지 않는 정보를 제대로 이해해야 한다.

공유하는 객체 수와 범위를 최대한 줄인다.

클라이언트에게 공유 상태를 관리하는 책임을 떠넘기지 않는다.

필요하다면 객체 설계를 변경해 클라이언트에게 편의를 제공한다.

 

어떻게든 문제는 생긴다. 초반에 들어가지 않는 문제는 일회성으로 치부하지 말자 무시하지 말자

대게 일회성 문제는 시스템 부하 상태나 뜬금없이 발생한다. 그러므로 스레드 코드는 플랫폼에서 많은 설정으로 반복적으로 테스트해야 한다

테스트 용이성은 TDD 3 규칙을 따른 자연히 얻어진다.

테스트 용이성은 또한 넓은 설정 범위에서 코드를 수행하기 위해 필요한 기능을 제공하는 플러그인 수준을 의미한다.

 

시간을 들여 보조 코드를 추가하면 오류가 드러날 가능성이 크게 높아진다.

직접 구현도 좋고 가지 자동화 기술을 사용해도 괜찮다.

초반부터 보조 코드를 고려한다. 스레드 코드는 출시 전까지 최대한 오랫동안 돌려봐야 한다.

'IT책, 강의 > 클린코드(Clean Code)' 카테고리의 다른 글

다시 시작  (0) 2023.11.10
마무리  (0) 2022.11.15
13장 동시성 - 1  (0) 2022.11.08
12장 창발성  (0) 2022.11.05
11장 시스템  (0) 2022.11.01

IN, EXISTS 

비슷한 듯, 동작방식이 다른 두 연산에 대해 알아보자.

 

select DISTINCT deptno from dept

select DISTINCT deptno from dept

 

select DISTINCT deptno from emp

 

IN 동작방식

근본적으로 IN 은 OR 동작과 같다.

 

select DISTINCT deptno
  from dept
 where deptno in (select DISTINCT deptno from emp)

 

위 쿼리에 서브 쿼리 결과는 아래와 같다.

select DISTINCT deptno from emp

즉, 위 쿼리는 아래와 같은 결과를 도출한다.

 SELECT *
  FROM DEPT
 WHERE DEPTNO IN 
 (30
,NULL
,20
,10)

 

실행결과는 둘 다 같다.

EXISTS  

 select  *
  from dept d
 where  EXISTS  (select deptno from emp e WHERE e.DEPTNO = d.DEPTNO)

위 쿼리 또한 같은 결과를 도출한다.

 

IN과 차이는 EXISTS는 서브쿼리가 행을 반환하면 TRUE를 도출한다. 즉, 직접적으로 값 비교를 하지 않는다.

 

NOT IN, NOT EXISTS

단순히 위 쿼리 2개에 NOT만 붙이면 어떻게 될까?

select distinct deptno
  from dept
 where deptno not in (select distinct deptno from emp)

아마 위와 같은 결과를 기대했을 것이다.

하지만 아래와 같은 결과가 나온다.

 SELECT  DISTINCT DEPTNO
  FROM DEPT D
 WHERE NOT EXISTS  (SELECT DISTINCT DEPTNO FROM EMP E WHERE E.DEPTNO = D.DEPTNO)

NOT EXISTS는 정상적으로 기대한 값이 나온다. 

왜 이런 결과가 나오는 것일까?

 SELECT DISTINCT DEPTNO
  FROM DEPT
 WHERE DEPTNO NOT IN 
 (30
--,NULL
,20
,10)

위 쿼리에서 봤던 풀이에서 NULL만 주석 처리하고 결과를 보면 같은 결과가 나온다.

위 결과가 도출된 이유는 아래와 같다.

SELECT DISTINCT DEPTNO FROM DEPT;
SELECT DISTINCT DEPTNO FROM EMP;

각 테이블의 결과를 데카르트 곱을 하게 된다.

10을 예로 들면

(10=10, 10=20, 10=30, 10=NULL)

 

IN은 근본적으로 OR연산이니

(10=10 OR 10=20 OR 10=30 OR 10=NULL)

 

(TRUE OR FALSE OR FALSE  OR NULL)

 

OR연산에서 하나라도 TRUE가 있으면 FALSE가 몇 개던 TRUE이다.

(TURE OR NULL)

 

여기가 중요하다 OR은 NULL과 연산해도 TRUE를 도출한다.

(TURE)

 

즉, 각 값마다 데카르트 곱을 할 때 NULL이 껴 있느면 그냥 IN일때는 TRUE를 반환하지만

NOT IN 일 경우 TRUE에 NOT이 되어 전부 FALSE가 되는 것이다.

 

 SELECT  DISTINCT DEPTNO
  FROM DEPT D
 WHERE NOT EXISTS  (SELECT DISTINCT DEPTNO FROM EMP E WHERE E.DEPTNO = D.DEPTNO)

EXISTS의 경우에는 각 행 단위로 행 결과만 존재 여부로 TRUE, FALSE를 리턴하기 때문에 정상적으로 값이 도출되는 것이다.

 

 

이래나 저래나 당장 이해하기 버겁다면, NOT IN만 조심하면 된다는 것을 기억하면 된다.

아니 NOT IN에 NULL이 끼어있으면 값이 제대로 도출이 안된다는 것만 기억하면 된다.

 

이를 방지하기 위해선 위 처럼 NOT EXISTS를 사용하거나

기존 쿼리 구조를 변경하기 어려운 경우라면 NULL처리를 적당해 해주면 된다.

SELECT DISTINCT DEPTNO FROM DEPT
 WHERE DEPTNO NOT IN (SELECT DISTINCT  NVL(DEPTNO, 0) FROM EMP)

굳이 NVL아니더라도 DECODE, COALESCE.... 등 편한대로 처리하면 된다.

 

 

 

 

 

 

 

 

코드

public class 숫자뒤집기 {
	public static void main(String[] args) {
		int value = 12345;
		int rest = 0;
		int count = 0;
		//value의 일의 자리를 계속 자르고 맨 앞으로 보낸다.
		while(value>0) {
			int units = value % 10 ; // 일의 자리 구하기
			// 일의 자리를 계속 10곱하기 반복, 결국 뒤집기가 된다.
			rest = rest * 10 + units;
			System.out.println(value+" "+ ++count + "회 " + rest  
					+" | 일의 자리를 *10 하다보면 뒤집어진다.");
			value = value / 10;		 // 십의 자리만큼 제거
		}
		value = rest;
	}
}

결과

12345 1회 5 | 일의 자리를 *10 하다보면 뒤집어진다.
1234 2회 54 | 일의 자리를 *10 하다보면 뒤집어진다.
123 3회 543 | 일의 자리를 *10 하다보면 뒤집어진다.
12 4회 5432 | 일의 자리를 *10 하다보면 뒤집어진다.
1 5회 54321 | 일의 자리를 *10 하다보면 뒤집어진다.

핵심은 일의 자리를 때고 10씩 곱하다보면 숫자가 뒤집힌다.

'자료구조&알고리즘 > 자바(Java) 알고리즘 문제풀이 : 코딩테스트 대비' 카테고리의 다른 글

중복문자제거  (0) 2022.11.14
격자판 최대합  (0) 2022.11.12
봉우리  (0) 2022.11.09
등수구하기  (0) 2022.11.05
문자뒤집기  (0) 2022.11.03

코드



import java.util.*;
import java.util.stream.IntStream;
/*
핵심
별도 탐색 배열을 만드는 것
탐색 배열을 이용해 반복문으로 인덱스 보정
보정 값에 조건문
탐색 배열의 이점, 조건문 4번으로 검사해도 되지만, 
만약 좌상,상, 우상, 이렇게 8방향을 검사하라고 하면?
*/
class 봉우리 { 
    public static void main(String[] args){
        //봉우리 크기
        final int LENGTH = 10;
        //봉우리 높이
        final int HEIGTH = 10;
        int answer=0;
        int[][] arr =   IntStream.range(0, LENGTH)
                                 .mapToObj(num->{
                                     return new Random().ints(LENGTH, 0, HEIGTH)
                                                        .toArray();
                                 }).toArray(int[][]::new);
        prettyPrint(arr);
        
        // 타겟[i][j] 위치에 상 우 하 좌 위치 탐색 배열
        int[] dx={-1, 0, 1, 0};
        int[] dy={0, 1, 0, -1};
        
        for(int i=0; i<LENGTH; i++){
            for(int j=0; j<LENGTH; j++){
                
                boolean flag=true;
                //탐색을 위한 반복문 순회
                for(int k=0; k<4; k++){
                    //인덱스 보정   상, 우, 하, 좌
                    int ni=i+dx[k];
                    int nj=j+dy[k];
                    // 보정인덱스는 -1이나 배열크기면 크다고 가정한다. 
                    // 예를들어 [0,0] [마지막][마지막] 배열을 보정하면 배열범위를 초과해 익셉션 발생
                    if(0<=ni && ni<LENGTH && 0 <= nj && nj<LENGTH && arr[i][j]<=arr[ni][nj] ){
                        flag=false;
                        //한 개라도 작거나 같으면 break
                        break;
                    }
                }
                if(flag) {
                    System.out.print("["+i+","+j+"] "+arr[i][j]+(answer%5==4?"\n":""));
                    answer++;
                }
            }
        }
        System.out.println();
        System.out.println(answer);
    }
    static void prettyPrint(int[][] arr, boolean isIndex) {
        for(int i=0;i<arr.length;i++) {
            for(int j=0;j<arr[i].length;j++) {
                if(isIndex) System.out.printf("%2d,%2d ", i,j);
                else System.out.printf("%2d" + (j==arr[i].length-1? "":",") ,arr[i][j]);
            }
            System.out.println(isIndex?"\n":"");
        }
    }
    static void prettyPrint(int[][] arr) {
        prettyPrint(arr, false);
    }
}

결과

 5, 4, 4, 1, 5, 6, 3, 5, 0, 3
 7, 4, 8, 7, 7, 7, 1, 4, 4, 9
 9, 3, 7, 3, 9, 2, 6, 2, 0, 2
 7, 1, 2, 6, 0, 2, 0, 5, 9, 9
 3, 0, 1, 3, 9, 1, 5, 3, 1, 9
 2, 8, 2, 2, 0, 6, 0, 4, 9, 3
 1, 3, 6, 8, 6, 8, 6, 4, 8, 0
 0, 6, 3, 6, 2, 3, 2, 2, 6, 7
 1, 5, 4, 4, 5, 7, 6, 4, 7, 2
 9, 4, 7, 3, 2, 2, 5, 8, 7, 9
[0,7] 5[1,2] 8[1,9] 9[2,0] 9[2,4] 9
[2,6] 6[3,3] 6[4,4] 9[4,6] 5[5,1] 8
[5,8] 9[6,3] 8[6,5] 8[7,1] 6[7,9] 7
[8,5] 7[9,0] 9[9,2] 7[9,7] 8[9,9] 9

20

핵심 구조는 2차원 배열을 순회하는 이중 반복문을 사용하는데 이정된 인덱스[][] 마다 내 상, 하, 좌, 우를 검증하는 반복문을 넣는 것이다.

위 예제를 단순히 삼중 반복문 사용하네!! 이렇게 접근하면 복잡하고 어려워진다.

이차원 배열을 순회하는 이중 반복문 + 지정된 배열[][] 마다 검증로직(반복문)     

이렇게 접근해야 쉬워진다.

'자료구조&알고리즘 > 자바(Java) 알고리즘 문제풀이 : 코딩테스트 대비' 카테고리의 다른 글

격자판 최대합  (0) 2022.11.12
숫자뒤집기  (0) 2022.11.10
등수구하기  (0) 2022.11.05
문자뒤집기  (0) 2022.11.03
가위바위보  (0) 2022.10.28

동시성과 깔끔한 코드는 양립하기 아주 어렵다.

깨끗한 동시성은 하나를 할당할 정도로 복잡한 주제다.

 

동시성이 필요한 이유?

동시성은 결합을 없애는 전략이다. 무엇과 언제를 분리하는 전략이다. 쓰레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 호출 스택을 살펴보면 곧바로 알수 있다.

 

무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 구조적 관점에서 거대한 루프 하나가 아니라 작은 협력 프로그램 여럿으로 보인다. 따라서 시스템을 이해하기 쉽고 문제를 분리하기도 쉽다.

 

예를 들어, 어플리케이션 표준인 서블릿 모델을 보면 서블릿은 혹은 EJB컨테이너라는 우산 아래서 동작한다. 컨테이너는 동시성을 부분적으로 관리한다. 요청이 들어올 때마다 서버는 비동기식으로 서블릿을 실행한다. 서블릿 프로그래머는 들어오는 모든 요청을 관리할 필요가 없다. 원칙적으로 서블릿 스레드는 다른 서블릿 스레드와 무관하게 자신만의 세상에서 돌아간다.

실제로 컨테이너가 제공하는 결합분리(decoupling)전략은 완벽과 거리가 아주 멀다. 따라서 서블릿 프로그래머는 동시성을 정확히 구현하도록 각별한 주의와 노력을 기울여야 한다. 그럼에도 서블릿 모델이 제공하는 구조적 이점은 아주 크다.

 

구조적 개선만을 위해 동시성을 채택하는 아니다. 응답 속도와 작업 처리량 이점이 존재한다. 예를 들어 CPU 보통 I/O단계에서 병목이 발생한다. 충분한CPU 속도를 I/O는 절대 따라올 수가 없다. 이럴 다중 쓰레드는 I/O 병목을 다소다소 완화 있다.

 

미신과 오해

  • 동시성은 항상 성능을 높여준다

동시성은 때로 성능을 높여준다.

대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다.

  • 동시성을 구현대로 설계는 변하지 않는다

단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다. 일반적으로 무언과 언제를 분리하면 시스템 구조가 크게 달라진다

  • 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다.

실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 있는지를 알아야만 한다.

 

반대로 동시성과 관련된 타당한 생각 가지

 

동시성은 다소 부하를 유발한다. 성능 측면에서 부하가 걸리며, 코드도 더 짜야한다

동시성은 복잡하다. 간단한 문제라도 동시성은 복잡하다

일반적으로 동시성 버그는 재현하기 어렵다. 그래서 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다

동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.

동시성 방어 원칙

  • 단일 책임 원칙(Single Responsibility Principle)

SRP 주어진 메서드/클래스/컴포넌트를 변경할 이유가 하나여야 한다는 원칙

동시성은 복잡성 하나만으로도 따로 분리할 이유가 충분하다.

, 동시성 관련 코드는 다른 코드와 분리해야 한다는 뜻이다.

  • 고려사항

동시성 코드는 독자적인 개발, 변경, 조율 주기가 있다.

동시성 코드에는 독자적인 난관이 있다. 다른 코드에서 겪는 난관과 다르며 훨씬 어렵다.

잘못 구현한 동시성 코드는 별의별 방식으로 실패한다. 주변에 있는 다른 코드가 발목을 잡지 않더라도 동시성 하나만으로도 충분히 어렵다.

따름 정리 : 자료 범위를 제한하라

객체 하나를 공유한 동일 필드를 수정하면 스레드 간섭이 발생한다.

해결 방법으로 객체를 사용하는 코드 내내 임계 영역 임계 영역(critical section) synchronized 키워드로 보호한다.

다만 이런 임계 영역의 수를 줄이는 기술이 중요하다. 수가 많을수록 다음 가능성이 커진다.

보호할 임계 영역을 빼먹는다.

모든 임계영역을 올바로 보호했는지 확인하느라 노력과 수고를 반복한다

버그 찾기가 더욱 어려워진다.

 

따름 정리: 자료 사본을 사용하라

공유하지 않는 방법으로 객체를 복사해 읽 전용으로 사용하는 방법이다.

데이터의 변경이 없는 읽기는 동시성에서 자유롭다.

 

따름 정리: 스레드는 가능한 독립적으로 구현하라

다른 스레드와 자료를 공유하지 않는다. 스레드는 클라이언트 요청 하나를 처리한다. 모든 정보는 비공유 출처에서 가져오며 로컬 변수에 저장한다.

예를 들어, HttpServlet클래스에서 파생한 클래스는 모든 정보를 doGet doPost매개변수로 받는다. 그래서 서블릿은 마치 자신이 독자적인 시스템에서 동작하는 요청을 처리한다. 서블릿 코드가 로컬 변수만 사용한다면 서블릿이 동기화 문제를 일으킬 가능성은 전무하다. 물론 DB 연결과 같은 자원을 공유하는 상황은 처한다.

 

권장사항: 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라

라이브러리를 이해하라

  • 자바 5는 동시성 측면에서 이전 버전보다 많이 나아졌다.

스레드 환경에 안전한 컬렉션을 사용한다. 자바 5부터 제공한다.

서로 무관한 작업을 수행할 때는 executor 프레임워크를 사용한다.

가능하다면 스레드가 차단(blocking) 되지 않는 방법을 사용한다.

일부 클래스 라이브러리는 스레드에 안전하지 못한다.

 

추가로 자바 8부터 지원하는 Stream API는 동시성 구현이 쉽고 안전하다.

스레드 환경에 안전한 컬렉션

java.util.concurrent 패키지가 제공하는 클래스는 다중 스레드 환경에서 사용해도 안전하며, 성능도 좋다.

실제로 ConcurrentHashMap 거의 모든 상황에서 HashMap보다 빠르다. 동시 읽기/쓰기를 지원하며, 다중 스레드 환경에서 문제가 생시는 자주 사용하는 복합 연산을 다중 스레드 상에서 안전하게 만든 메서드로 제공한다.

좀 더 복잡한 동시성설계를 지원하고자 자바 5에는 다른 클래스도 추가되었다.

 

권장사항 : 언어가 제공하는 클래스를 검토하라.

자바에서는 java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks 익혀라

실행 모델을 이해하라

한정된 자원(Bound Resource) 다중 스레드 환경에서 사용하는 지원으로, 크기나 숫자가 제한적이다. 데이터베이스 연결, 길이가 일정한 읽기/쓰기 버퍼 등이 예다.
상호 배제(Mutual Exclusion) 한 번에 한 스레드만 공유 자료나 공유 자원을 사용할 수 있는 경우를 가리킨다.
기아(Strarvation) 한 스레드나 여러 스레드가 굉장히 오랫동안 혹은 영원히 자원을 기다린다. 예를 들어, 항상 짧은 스레드에게 우선순위를 준다면, 짧은 스레드가 지속적으로 이어질 경우, 긴 스레드가 기아 상태에 빠진다.
데드락(Deadlock) 여러 스레드가 서로가 끝나기를 기다린다. 모든 스레드가 각기 필요한 자원을 다른 스레드가 점유하는 바람에 어느 쪽도 더 이상 진행하지 못한다.
라이브락(Livelock) 락을 거는 단계에서 각 스레드가 서로를 방해한다. 스레드는 계속해서 진행하려 하지만, 공명(resonance)으로 인해, 굉장히 오랫동안 혹은 영원히 진행하지 못한다.

생산자-소비자

하나 이상 생산자 스레드가 정보를 생성해 버퍼나 대기열(queue) 넣는다

하나 이상 소비자 스레드가 대기열에서 정보를 가져와 사용한다.

생산자 스레드와 소비자 스레드가 사용하는 대기열은 한정된 자원이다.  생산자 스레드는 대기열에 공간이 있어야 정보를 채운다. 즉, 빈 공간이공간이 생길 때까지 기다린다.

소비자 스레드는 대기열에 정보가 있어야 가져온다. , 정보가 채워질 때까지 기다린다.

대기열을 올바로 사용하고자 생산자 스레드와 소비자 스레드는 서로에게 시그널을 보낸다.

생산자 스레드는 대기열에 정보를 채운 다음 소비자 스레드에게 "대기열에 정보가 있다" 시그널을 보낸다.

소비자 스레드는 대기열에서 정보를 읽어 들인 후 "대기열에 공간이 있다" 시그널을 보낸다.

 

읽기-쓰기

읽기 스레드를 위한 주된 정보원으로 공유 자원을 사용하지만, 쓰기 스레드가 공유 자원을 이따금 갱신한다고 하자.

처리율이 문제의 핵심이다. 처리율을 강조하면 기아 현상이 생기거나 오래된 정보가 쌓인다.

갱신을 허용하면 처리율에 영향을 미친다.

쓰기 스레드가 버퍼를 갱신하는 동안 읽기 스레드가 버퍼를 읽으면 안 되고

읽기 스레드가 버퍼를 읽는 동안 쓰기 스레드가 버퍼를 갱신하면 안 된다.

대개 쓰기 스레드가 버퍼를 오랫동안 점유하는 바람에 여러 읽기 스레드가 버퍼를 기다리느라 처리율이 떨어진다.

 

읽기 스레드의 요구와 쓰기 스레드의 요구를 적절히 만족시켜 처리율도 적당히 높이고 기아도 방지하는 해법이 필요하다.

간단한 전략은 읽기 스레드가 없을 때까지 갱신을 원하는 쓰기 스레드가 버퍼를 기다리는 방법

읽기 스레드가 계속 이어지면 쓰기 스레드가 기아 상태가 된다.

쓰기 스레드에게 우선권을 상태에서 쓰기 스레드가 계속 이어진다면 처리율이 떨어진다.

양쪽 균형을 잡으면서 동시 갱신 문제를 피하는 해법이 필요하다

 

생각하는 철학자들

둥근 식탁에 철학자  무리가 둘러앉았다.

철학자들 사이 마다 포크가   있다.

식탁 가운데에 거대한 스파게티  접시가 있다

철학자들은 배고프면 양손에 포크를 집어 스파게티를 먹는다.

따라서 왼쪽, 오른쪽 철학자는  철학자가 포크를 내려놓을 때까지 기다려야 한다.

 

여기서 철학자를 쓰레드, 포크를 자원으로 치환하면 된다.

주의해서 설계하지 않으면 데드락, 라이브락, 처리율 저하, 효율성 저하 등을 겪는다.

 

대부분의 쓰레드 문제는  세가지 생산자-소비자, 읽기-쓰기, 생각하는 철학자들 범주 속한다.  알고리즘을 공부하고 해법을 직접 구현해보자. 나중에 문제  해결이 쉬워진다.

 

 

 

 

 

'IT책, 강의 > 클린코드(Clean Code)' 카테고리의 다른 글

마무리  (0) 2022.11.15
13장 동시성 - 2  (1) 2022.11.12
12장 창발성  (0) 2022.11.05
11장 시스템  (0) 2022.11.01
10장 클래스  (0) 2022.10.26

코드

import java.util.*;
// 핵심은 중복 점수 등수가 왜 문제가 없는
class 등수구하기_ {	
		
	public static void main(String[] args){
		int[] scoreArr = new Random().ints(15, 0, 101)
				                     .toArray();
		
		final int LENGTH = scoreArr.length;
		int[] answer = new int[LENGTH];
		int rank = 1;
		
		for(int i=0;i<LENGTH;i++) {
			for(int j=0;j<LENGTH ;j++) {
				//나와 나를 비교하면 참이 안될 것 == 나와 동점은 참이 안될 것
				//결과적으로 동점은 같은 등수를 가지게 된다.
				if(scoreArr[i]<scoreArr[j]) {
					rank++;
				}
			}
			answer[i] = rank;
			rank = 1;
		}
		System.out.println(Arrays.toString(scoreArr));
		System.out.println(Arrays.toString(answer));
		
	}
}

결과

[49, 78, 82, 27, 25, 89, 19, 90, 13, 3, 64, 12, 62, 31, 94]
[8, 5, 4, 10, 11, 3, 12, 2, 13, 15, 6, 14, 7, 9, 1]

 

'자료구조&알고리즘 > 자바(Java) 알고리즘 문제풀이 : 코딩테스트 대비' 카테고리의 다른 글

숫자뒤집기  (0) 2022.11.10
봉우리  (0) 2022.11.09
문자뒤집기  (0) 2022.11.03
가위바위보  (0) 2022.10.28
큰수출력하기  (0) 2022.10.26

창발적 설계로 깔끔한 코드를 구현하자

착실히 따르면 우수한 설계가 나오는 간단한 규칙 가지.

코드 구조와 설계를 파악하기 쉬워지게 해 준다.

그래서 SRP(Single Responsibility Principle, 단일 책임원칙)나 DIP(Dependency Inversion Principle, 의존관계 역전 원칙)을 적용하기적용하기 쉬워진다.

 

켄트 백이제 시한단순한 설계 규칙 가지 (중요도 )

  • 모든 테스트를 실행한다
  • 중복을 없앤다
  • 프로그래머 의도를 표현한다
  • 클래스와 메서드 수를 가능한 최소로 줄인다

단순한 설계 규칙 1: 모든 테스트를 실행하라

모든 테스트 케이스를 항상 통과하는 시스템은 테스트가 가능한 시스템이어야 한다.

테스트가 불가능한 시스템은 검증도 불가능하므로 절대 출시하면 안 된다

 

테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다.

크기가 작고 목적 하나만 수행하는 클래스가 나온다.

SRP 준수하는 클래스는 테스트가 훨씬 쉽다.

 

결합도가 높으면 테스트 케이스를 작성하기 어렵다.

테스트 케이스를 많이 작성할수록 개발자는 DIP 같은 원칙을 적용하고, DI, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춘다.

 

결과적으로 "테스트 케이스를 만들고 계속 돌려라"라는 규칙을 따르면 시스템은 낮은 결합도와 높은 응집력을응집력을 목표로 하는 객체지향 방법론에 가까워진다.가까워진다.

, 테스트 케이스를 작성하면 설계 품질이 높아진다.

단순한 설계 규칙 2~4: 리펙터링

테스트 케이스를 모두 작성했다면 이제 코드와 클래스를 정리한다.

구체적으로는 코드를 점진적으로 리팩터링 해나간다.

코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까!

 

리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다.

응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 시스템 관심사를 모듈로 나누고, 함수와 클래스 크기를 줄이고, 나은 이름을 선택하는 다양한 기법을 동원한다.

또한 단계는 단순할 설계 규칙 나머지 3개를 적용해 중복을 제거하고, 프로그래머 의도를 표현하고, 클래스와 메서드 수를 최소로 줄이는 단계이기도 하다.

 

중복을 없애라

중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻한다.

중복은 여러 가지 형태로 표출된다.

똑같은 코드는 당연히 중복이고, 구현 중복도 중복의 형태다.

//구현 중복 예시
int size(){구현...}
boolean isEmpty(){구현...}
--------------------------------
//구현 중복 제거 예시
boolean isEmpty(){
	return size() == 0 ;
}

깔끔한 시스템을 만들려면 줄이라도 중복을 제거하겠다는 의지가 필요하다.

작은 중복을 제거하겠다는 것을 무시하면 안 된다.

작은 중복 제거를 할 줄 알아야 큰 중복을 제거할 수 있다.

 

"소규모 재사용" 시스템 복잡도를 극적으로 줄여준다

소규모 재사용을 제대로 익혀야 대규모 재사용이 가능하다.

 

TEMPLATE METHOD 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법이다

표현하라

우리 대다수는 엉망인 코드를 접한 경험이 있으리라.

자신이 이해하는 코드는 짜기 쉽다. 코드를 짜는 동안에는 문제에 빠져 코드를 구석구석 이해하니까

하지만 나중에 코드를 유지 보수할 사람이 코드를 짜는 사람만큼이나 문제를 깊이 이해할 가능성은 희박하다.

 

소프트웨어 프로젝트 비용 대다수는 장기적인 유지보수에 들어간다. 따라서 유지보수 개발자가 시스템을 제대로 파악해야 버그가 스며들지 않는다.

시스템이 점차 복잡해지면 유지보수 개발자가 코드 분석에 보내는 시간은 점점 늘어나 오해할 가능성도 커진다. 그러므로 코드는 개발자의 의도를 분명히 표현해야 한다. 개발자가 코드를 명백하게 수록 다른 사람이 코드를 이해하기 쉽다. 이는 유지보수 비용 절감으로 나타난다.

 

우선, 좋은 이름을 선택하라.

기능과 딴판인 이름을 지으면 안 된다.

 

둘째, 클래스 크기를 가능한 줄여라

이름 짓기도 구현도 이해도 쉬워진다

 

셋째, 표준 명칭을 사용하라.

예를 들어, 패턴을 적용했다면 클래스 이름 뒤에 패턴 이름을 붙인다.

의사소통과 표현력이 강화된다

 

넷째, 단위 테스트 케이스를 꼼꼼히 작성하라

테스트 케이스는 예제로 보여주는 문서와도 같다.

다시 말해 만든 테스트 케이스를 읽어보면 클래스 기능을 이해할 있게 된다

 

마지막으로 가장 중요한 방법은 노력이다.

흔히 코드만 돌린 다음 문제로 직행하는 개발자가 많다.

나중에 읽을 사람을 고려해 조금이라도 노력하지 않는 개발자가 많다.

하지만 나중에 코드를 읽을 사람은 바로 자신일 가능성이 높다는 사실을 명심하자

 

함수와 클래스에 조금 시간을 투자하자.

나은 이름을 선택하고,

함수를 작은 함수 여럿으로 나누고,

자신의 작품에 조금만 주의를 기울이자.

주의는 대단한 재능이다.

 

클래스와 메서드 수를 최소로 줄여라

중복 제거, 의도 표현, SRP 준수를 극단적으로극단적으로 지키다 보면 득 보 다실이실이 많아진다.

클래스와 메서드 크기를 줄이자고 조그마한 클래스와 메서드를 수 없이 만드는 사례도 없지 않다.

그래서 규칙은 함수나 클래스 수를 "가능한" 줄이라 것이다.

 

때로는 무의미하고 독단적인 정책 탓에 클래스 수와 메서드 수가 늘어나기도 한다.

클래스마다 무조건 인터페이스를 생성하라고 요구하는 구현 표준이 좋은 예다.

자료 클래스와 동작 클래스는 무조건 분리해야 한다고 주장하는 개발자도 좋은 예다.

가능한 독단적인 견해는 멀리하고 실용적인 방식을 택한다.

 

목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 있다.

하지만! 규칙은 간단한 설계 규칙 우선순위가 가장 낮다.

다시 말해, 클래스와 함수 수를 줄이는 작업도 중요하지만, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 중요하다는 뜻이다.

 

 

결론

경험을 대신할 단순한 개발 기법은 없다. 하지만 책에서 소개한 기법은 저자들의 수십 경험이 녹아있다. 규칙을 따르다 보면 나중에 오랜 경험이 쌓인 기법을 활용할 있을 것이다.

 

 

 

 

 

'IT책, 강의 > 클린코드(Clean Code)' 카테고리의 다른 글

13장 동시성 - 2  (1) 2022.11.12
13장 동시성 - 1  (0) 2022.11.08
11장 시스템  (0) 2022.11.01
10장 클래스  (0) 2022.10.26
9장 단위 테스트  (0) 2022.10.21

코드

public class 단어뒤집기 {
	public static void main(String[] args) {
		String word = "가나다라마바사";
		int lt = 0;
		int rt = word.length()-1;
		char[] cs = word.toCharArray();
		char[] cs2 = word.toCharArray();
		char tmp = ' ';
		
		//방법 1
		while(lt<rt) {
			tmp = cs[lt];     
			cs[lt] = cs[rt];  
			cs[rt] = tmp;     
			lt++;
			rt--;
		}
		
		//방법 2
		int len = cs2.length;
		for(int i=0; i<len/2;i++) {
			tmp = cs2[i];
			cs2[i] = cs2[len-i-1];
			cs2[len-i-1] = tmp;
		}
		
		System.out.println(String.valueOf(cs));
		System.out.println(String.valueOf(cs2));
		
	}
}

결과

사바마라다나가
사바마라다나가

자리 옮기기

cs[lt]를 tmp로 옮김
cs[lt]는 보존되어 있다. 그 자리에 cs[rt]를 넣는다.
cs[rt]자리에 cs[lt]를 넣는다. 자리 옮기기 끝


개인적으로 "방법 2"로만 했었는데,  "방법1"이 더 가독성이 좋아보인다. 구조도 이해하기 쉽다.

'자료구조&알고리즘 > 자바(Java) 알고리즘 문제풀이 : 코딩테스트 대비' 카테고리의 다른 글

숫자뒤집기  (0) 2022.11.10
봉우리  (0) 2022.11.09
등수구하기  (0) 2022.11.05
가위바위보  (0) 2022.10.28
큰수출력하기  (0) 2022.10.26

복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다.

도시를 세운다면?

여러분이 도시를 세운다면? 온갖 세세한 사항을 혼자서 직접 관리할 있을까?

불가능하다.

이미 세워진 도시라도 사람의 힘으론 무리다.

도시들이 돌아가는 이유는 수도 관리팀, 전력관리팀, … 분야를 관리하는 팀이 있기 때문이다. 도시의 그림을 그리는 사람도 있으며, 작은 사항에 집중하는 사람도 있다

도시가 돌아가는 다른 이유!!

적절한 추상화와 모듈화 때문이다. 그래서 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다.

 

소프트웨어 팀도 도시처럼 구성한다.

깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.

장에서는 높은 추상화 수준, 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다.

 

시스템 제작과 시스템 사용을 분리하라

제작(construction) 사용(use) 아주 다르다

호텔을 짓기 위해 작업복과 안전모를 사람들이 열심히 일을 한다. 내부 인테리어까지 예쁘게 꾸미고 나면 이제 호텔에 있는 사람들은 잘차려진 복장을 입은 사람들이다.

 

소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 준비 과정과 준비 과정 이후에 이어지는 런타임 로직을 분리해야 한다.

 

시작 단계는 모든 애플리케이션이 풀어야 관심사다 관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 하나다.

불행히도 대다수 애플리케이션은 시작 단계라는 관심사를 분리하지 않는다.

Main 분리

시스템 생성과 시스템 사용을 분리하는 가지 방법 소개

생성과 관련한 코드는 모두 main이나 main 호출하는 모듈로 옮긴다.

나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다.

 

main함수에서 시스템에 필요한 객체를 생성한 이를 애플리케이션에 넘긴다. 애플리케이션은 그저 객체를 사용할 뿐이다.

애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다. 그저 적절히 생성됐다고 가정한다.

 

의존성 주입

사용과 제작을 분리하는 강력한 메커니즘 하나가 의존성 주입이다. (Dependency Injection)

의존성 주입은 제어의 역전(Inversion of Control) 기법 의존성 관리에 적용한 메커니즘이다.

제어 역전에서는 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다.

새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙을 지키게 된다.

의존성 관리 맥락에서 객체는 의존성 자체를 인스턴스로 만드는 책임을 지지 않는다.

대신에 이런 책임을 다른 '전담' 메커니즘에 넘겨야만 한다.

그렇게 함스로써 제어를 역전한다.

초기 설정은 시스템 전체에서 필요하므로 대개 '책임질' 메커니즘으로 main 루틴이나 특수 컨테이너 사용한다.

 

DI컨테이너는 대개 요청이 들어올 때마다 필요한 객체의 인스턴스를 만든 생성자 인수나 설정자 메서드를 사용해 의존성을 설정한다.

실제로 생성되는 객체 유형은 설정 파일에서 지정하거나 특수 생성 모듈에서 코드로 명시한다

 

스프링 프레임워크는 가장 널리 알려진 자바 DI 컨테이너를 제공한다.

객체 사이 의존성은 XML 파일에 정의한다.

그리고 자바 코드에서는 이름으로 특정한 객체를 요청한다.

그러나 초기화 지연으로 얻는 장점은 포기해야하는 걸까?

기법은 DI를사용하더라도 때론 여전히 유용하다.

대다수 DI 컨테이너는 필요할 때까지는 객체를 생성하지 않고, 대부분은 계산 지연이나 비슷한 최적화에 있도록 팩토리를 호출하거나 프록시를 생성하는 방법을 제공한다.

, 계산 지연 기법이나 이와 유사한 최적화 기법에서 이런 메커니즘을 사용할 있다.

 

확장(Open-Closed Principle 원칙을 기억하자)

군락-> 마을-> 도시이렇게 점차 규모 확장되며 그게 맞게 도로 같은 인프라도 확장해야하지만 꽉막힌 도로를 보면서 처음부터 도로를 6차선으로 뚫지 않았나라고 생각한적 있는가?

반대로 생각해보자. 마을 규모에서 반드시 도시로 성장할 것이라 생각하고 처음부터 6차선 도로를 뚫을 것인가?

 

'처음부터 올바르게' 시스템을 만들 있다는 믿음은 미신이다.

당장 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 한다.

내일은 새로운 스토리에 맞춰 시스템을 조정하고 확장하면 된다.

이것을 반복적이고 점진적인 애자일 방식의 핵심이다.

테스트 주도 개발(Test-driven Development, TDD),리팩터링, 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다

 

하지만 시스템 수준에서는 어떨까? 시스템 아키텍처는 사전 계획이 필요하지 않을까?

단순한 아키텍처를 복잡한 아키텍처로 조금씩 키울 없다는 현실은 정확하다.

 

소프트웨어 시스템은 물리적인 시스템과 다르다.

관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 있다.

 

소프트웨어 시스템은 '수명이 짧다' 본질로 인해 아키텍처의 점진적인 발전이 가능하다.

먼저, 관심사를 적절히 분리하지 못하는 아키텍처 예를 소개한다.

 

EJB1, EJB2 아키텍처는 관심사를 적절히 분리를 하지 못했다. 따라서 유기적인 성장이 어려웠다.

불필요한 장벽이 생긴 탓이다.

 

횡단(cross-cutting) 관심사

EJB2 아키텍처는 일부 영역에서 관심사를 거의 완벽하게 분리한다.

, 원하는 트랜잭션, 보안, 일부 연속적인 동작은 소스코드가 아니라 '배치 기술자'에서 정의한다.

 

영속성과 같은 관심사는 애플리케이션의 자연스러운 객체 경계를 넘나드는 경향이 있다.

모든 객체가 전반적으로 동일한 방식을 이용하게 만들어야 한다.

예를 들어, 특정 DBMS 독자적인 파일을 사용하고, 테이블과 열은 같은 명명 관례를 따르며, 트랜잭션 의미가 일관적이면 더욱 바람직하다.

원론적으로는 모듈화 되고 캡슐화된 방식으로 영속성 방식을 구상 있다. 영속성 방식을 구현한 코드가 온갖 객체로 흩어진다. 여기서 횡단 관심사라는 용어가 나온다. 영속성 프레임워크 또한 모듈화 할 수 있다. 도메인 논리도 독자적으로 모듈화할 수 있다. 문제는 영역이 세밀한 단위로 겹친다는 점이다.

 

EJB아키텍처가 영속성, 보안, 트랜잭션을 처리하는 방식은 관점 지향 프로그래밍(Aspect-Oriented Programming, AOP) 예견했다고 본다. AOP 횡단 관심사에 대처해 모듈성을 확보하는 일반적인 방법론이다.

 

AOP에서 관점(aspect)이라는 모듈 구성 개념은  "특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야 한다"라고 명시한다. 명시는 간결한 선언이나 프로그래밍 메커니즘으로 수행한다.

영속성을 예로 들면, 프로그래머는 영속적으로 저장할 객체와 속성을 선언한 영속성 책임을 영속성 프레임워크에 위임한다. AOP 프레임워크는 대상 코드에 영향을 미치지 않는 상태로 동작 방식을 변경한다

 

 

자바에서 사용하는 관점 혹은 관점과 유사한 메커니즘 개를 살펴보자

자바 프락시

자바 프락시는 단순한 상황에 적합하다.

개별 객체나 클래스에서 메서드 호출을 감싸는 경우가 좋은 예다.

하지만 JDK에서 제공하는 동적 프록시는 인터페이스만 지원한다.

클래스 프락시를 사용하려면 CGLIB, ASM Javassist 등과 같은 바이트 코드 처리 라이브러리가 필요하다. 스프링은 CGLIB 기본 탑재

import java.lang.reflect.*;

public class Test {
	public static void main(String[] args) {
		Runnable instance = 
				(Runnable) Proxy.newProxyInstance(
						Runnable.class.getClassLoader()
						, new Class[] {Runnable.class} 
				        , new PersonHandler(new Person()) );
		instance.run("빠르게");
		instance.eat("맛있게");
	}
}
class PersonHandler implements InvocationHandler{
	Runnable runnable;
	@Override
	public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
		String methodName = method.getName();
		
		if(methodName.equals("run")) {
			runnable.run((String) args[0]);
		}else if (methodName.equals("eat")) {
			runnable.eat((String) args[0]);
		}
		return null;
	}
	public PersonHandler(Runnable runnable) {
		this.runnable = runnable;
	}
}

interface Runnable {
	void run(String str);
	void eat(String str);
}

class Person implements Runnable{
	@Override
	public void run(String str) {
		System.out.println(str + "달린다.");
	}
	@Override
	public void eat(String str) {
		System.out.println(str + "먹는다.");
		
	}
}

프락시에는 InvocationHandler를 넘겨줘야 한다.한다.

단순한 예제지만 코드가 상당히 많으며 제법 복잡하다.

바이트 조작 라이브러리를 사용하더라도 만만찮게 어렵다.

코드 양과 크기는 프락시의 두 가지 단점이다.

다시 말해, 프락시를 사용하면사용하면 깨끗한 코드를 작성하기 어렵다

또한 프락시는 AOP 해법에 필요한 시스템 단위로 실행 지점을 명시하는 메커니즘도 제공하지 않는다.

순수 자바 AOP 프레임워크

복잡한 프록시 코드는 대부분 판박이라 다행스럽게도 도구로 자동화 있다

순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는 내부적으로 프락시를 사용한다. 스프링은 비즈니스 논리를 POJO 구현한다

POJO  순수하게 도메인에 초점 맞춘다. POJO 엔터프라이즈 프레임워크에 의존하지 않는다. 그리고 단순하다. 따라서 테스트와 유지보수가 쉽다.

 

프로그래머는 설정 파일이나 API 사용해 필수적인 애플리케이션 기반 구조를 구현한다.

영속성, 트랜잭션, 보안, 캐시, 장애조치 등과 같은 횡단 괌 심사도 포함된다

많은 경우 실제로는 스프링이나 JBoss라이브러리의 관점을 명시한다.

이때 프레임워크는 사용자가 모르게 프락시나 바이트코드 라이브러리를 사용해 이를 구현한다.

이런 선언들이 요청에 따라 주요 객체를 생성하고 서로 연결하는 DI 컨테이너의 구체적인 동작을 제어한다.

 

AspectJ관점

마지막으로, 관심사를 관점으로 분리하는 가장 강력한 도구는 AspectJ언어다

AspectJ 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장이다.

 

앞전에 스프링 AOP JBoss AOP 제공하는 순수 자바 방식은 관점이 필요한 상황 80-90% 충분하다. AspectJ 관점을 분리하는 강력하고 풍부한 도구 집합을 제공하지만, 언어 문법과 사용법을 익여야 된다는 단점 있다.

 

최근 나온 AspectJ 애너테이션폼은폼은 이런 부담을 어느 정도 완화한다

애너테이션폼은순수한 자바 코드에 자바 5 애너테이션을사용해 관점을 정의한다.

추가로 스프링 프레임워크는 AspectJ 미숙한 개발자들을 위해 애너테이션 기반 관점을 쉽게 다용하도록 다양한 기능을 제공한다.

 

AspectJ 대한 상세한 설명은 범위를 벗어난다. 자세한 내용은 AspectJ, Colyer, Spring 참조한다.

테스트 주도 시스템 아키택처 구축

관점으로 혹은 유사한 개념으로 관심사를 분리하는 방식은 위력이 막강하다.

애플리케이션 도메인 논리를 POJO 작성할 있다면, 코드 수준에서 아키텍처 관심사를 분리할 있다면 진정한 테스트 주도 아키텍처 구축이 가능해진다.

그때그때 새로운 기술을 채택해 단순한 아키텍처를 복잡한 아키텍처로 키워갈 수도 있다.(처음부터 거대한 시스템을 설계할 필요가 없다 아니 안 해도 된다.)

BDUF(Big Design Up Front) 추구할 필요가 없다. 실제로 BDUF 해롭기까지 하다.

처음에 쏟아부은 노력을 버리지 않으려는 심리적 저항으로 인해, 그리고 처음에 쏟아부은 노력을 버리지 않으려는 심리적 저항으로 인해, 그리고 처음 선택한 아키텍처가 향후 사고방식에 미치는 영향으로 인해, 변경을 쉽사리 수용하지 못하는 탓이다.

 

건축가는 BDUF 방식을 취한다. 물리적 구조는 일단 짓기 시작하면 극적인 변경이 불가능한 탓이다.

소프트웨어 역시 나름대로 형체가 있지만, 소프트웨어 구조가 관점을 효과적으로 분리한다면, 극적인 변화가 강제적으로 가능하다.

 

다시 말해, 아주 단순하면서도 멋지게 분리된 아키텍처로 소프트웨어 프로젝트를 진행해 결과물을 재빨리 출시한 , 기반 구조를 추가하며 조금씩 확장해 나가도 괜찮다 말이다.

세계 최대 사이트들은 고도의 자료 캐싱, 보안, 가상화 등을 이용해 아주 높은 가용성과 성능을 효율적이고도 유연하게 달성했다.

설계가 최대한 분리되어 추상화 수준과 범위에서 코드가 적당히 단순하기 때문이다.

 

그렇다고 아무 방향 없이 프로젝트에 뛰어들어도 좋다는 소리는 아니다.

프로젝트를 시작할 때는 일반적인 범위, 목표, 일정은 물론이고 결과로 내놓을 시스템의 일반적인 구조도 생각해야 한다. 하지만 변하는 환경에 대처해 진로를 변경할 능력도 반드시 유지해야 한다.

 

초창기 EJB 아키텍처는 기술을 너무 많이 넣느라 관심사를 제대로 분리하지 못했던 유명한 API 하나다.

설계가 아주 멋진 API 조차도 정말 필요하지 않으면 과유불급이다.

좋은 API 걸리적거리지 않아야 한다.

그래야 팀이 창의적인 노력을 사용자 스토리에 집중한다.

그리하지 않으면 아키텍처에 발이 묶여 고객에게 최적의 가치를 효율적으로 제공하지 못한다.

 

요약

최선의 시스템 구조는 각기 POJO 객체로 구현되는 모듈화 된 관심사 영역(도메인)으로 구성된다. 이렇게 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 있다.

 

 

 

의사 결정을 최적화하라

모듈을 나누고 관심사를 분리하면 지엽적인 관리와 결정이 가능해진다.

아주 시스템에서는 사람이 모든 결정을 내리기 어렵다.

가장 적합한 사람에게 책임을 맡기면 가장 좋다.

우리는 때때로 가능한 마지막 순간까지 결정을 미루는 방법이 최선이라는 사실을 까먹곤 한다.

게으르거나 무책임해서가 아니다.

최대한 정보를 모아 최선의 결정을 내리기 위해서다.

성급한 결정은 불충분한 지식으로 내린 결정이다.

너무 일찍 결정하면 고객 피드백을 모으고, 프로젝트를 고민하고, 구현 방안을 탐험할 기회가 사라진다.

 

관심사를 모듈로 분리한 POJO시스템은 기민함을 제공한다. 이런 기민함 덕택에 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬워진다. 또한 결정의 복잡성도 줄어든다.

 

 

 

 

명백한 가치가 있을 표준을 현명하게 사용하라

EJB2 단지 표준이라는 이유만으로 많은 팀이 사용했다.

가볍고 간단한 설계로 충분했을 프로젝트에서도 EJB2 채택했다.

나는 업계에서 여러 형태로 아주 과장되게 포장된 표준에 집착하는 바람에 고객 가치가 뒷전으로 밀려난 사례를 많이 봤다.

 

표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고, 적절한 경험을 가진 사람을 구하기 쉬우며, 좋은 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다. 하지만 때로는 표준을 만드는 시간이 너무 오래 걸려 업계가 기다리지 못한다. 어떤 표준은 원래 표준을 제정한 목적을 잊어버리기도 한다.

 

 

 

 

시스템은 도메인 특화 언어가 필요하다.

대다수 도메인과 마찬가지로, 건축 분야 역시 필수적인 정보를 명료하고 정확하게 전달하는 어휘, 관용구, 패턴이 풍부하다.

소프트웨어 분야에서도 최근 들어 DSL(Domain-Specific Language) 새롭게 조명받기 시작했다.

DSL(Domain-Specific Language) 간단한 스크립트 언어나 표준 언어로 구현한 API 가리킨다.

DSL 코드는 도메인 전문가가 작성한 구조적인 산문처럼 읽힌다.

좋은 DSL 도메인 개념과 개념을 구현한 코드 사이에 존재하는 의사소통 간극을 줄여준다.

도메인 전문가가 사용하는 언어로 도메인 논리를 구현하면 도메인을 잘못 구현할 가능성이 줄어든다.

 

효과적으로 사용한다면 DSL 추상화 수준을 코드 관용구나 디자인 패턴 이상으로 끌어올린다. 그래서 개발자가 적절한 추상화 수준에서 코드 의도를 표현할 있다.

 

도메인 특화 언어를 사용하면 고차원 정책에서 저 차원 세부사항에 이르기까지 모든 추상화 수준과 모든 도메인을 POJO 표현할 있다.

 

 

 

결론

시스템 역시 깨끗해야 한다.

깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다.

도메인 논리가 흐려지면 제품 품질이 떨어진다.

버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다.

기민성이 떨어지면 생산성이 낮아져 TDD 제공하는 장점이 사라진다.

 

모든 추상화 단계에서 의도는 명확히 표현해야 한다.

그러려면 POJO 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 구현 관심사를 분리해야 한다.

 

시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

 

 

'IT책, 강의 > 클린코드(Clean Code)' 카테고리의 다른 글

13장 동시성 - 1  (0) 2022.11.08
12장 창발성  (0) 2022.11.05
10장 클래스  (0) 2022.10.26
9장 단위 테스트  (0) 2022.10.21
8장 경계  (0) 2022.10.18

+ Recent posts