개발자인가 설계자인가

DB 란 무엇인가.

Database 의 약자인 DB는 

쉽게말해 정보의 집합체 이다.

그럼 정보는 무엇일까? 세상의 온갖것들이 다 정보이다.

그럼 그 모든것들을 다 Data 라고 봐야하나? 그건 아니다. 

설계자로써 가져야 하는 기본 마음 가짐은 "의미없는 컬럼은 없다" 이다. 

예를들어 내가 어떤 음식을 좋아하고 어떤 게임을 즐겨하며 직원들과 몇번의 술자리를 갖는지 

가족관계는 어떻게 되고 우리 가족은 휴일에 무엇을 하는지 

이런 것들은 일종의 정보일수는 있지만 Data라고 볼 수 없다. 

Data란 "구축된.. 또는 구축되어야 하는 System에서 필요로 하는 정보" 이다.

고객들과의 분석 과정에서 우린 수많은 요구사항을 듣는다. 

물론 고객들은 필요한 것들을 요구한다.

하지만 우린 제한된 Resource 안에서 수행할 수 밖에 없고 

고객의 모든 요구가 Programming 적으로 합당한지 검토할 수 밖에 없다. 

또한 그안에서 품질(Quality) 가 나와야 한다.

그렇다면 분석/설계자 (이하 설계자) 무엇에 초점을 맞추고 진행해야 할까? 

지극히 개인적인 생각이지만 역시 한줄로 표현하면 

"의미없는 컬럼은 없다" 이다.

"컬럼(Column)"은 Data의 최소 단위 이다. 이 컬럼들이 모여서 

데이터의 집합체-테이블(Table)이 된다. 또 그 테이블이 모여 고객이 원하는 시스템의 

데이터베이가 되는것이다.

설계자는 이 컬럼의 필요성과 연결고리를 고려해야만 한다. 

또한 사용처를 고민하지 않을 수 없다. 컬럼은 전체적인 공수나 프로그램 수정에 직접적인 영항을 주기 때문이다.

예를들어 고객사의 현업 A씨는 '도착예정일자'가 필요 하다고 한다. 

이유는 단순히 예정일자를 관리하고 싶어서 이다.

이건 현업의 언어이다. 설계자는 저 요구사항에서 일단 컬럼을 생각한다. 

표준에 맞는 DB타입, 개발 언어나 공통에서 제공하는 부분이 있는지.. 

현재 Table 에는 있는지 등등 ... 근데 더욱 중요한건 

업무적으로 어떻게-어디서 쓰이느냐 또 다른 화면에 영향이 있는가 이다.

생각나는데로 몇가지 얘기해 보면 

- 검수 등의 스케쥴을 관리해야 하는가?

- 예정일자로 인해 스케줄 관리가 추가될 가능성이 있는가? 

- 현황을 보는 레포트에서 추가가 필요한가? 

- 현황을 보는 레포트가 없다면 레포트가 추가될 가능성이 있는가? 

- 날짜에 대한 계산을 해야하는 것인가? 

- 현재 화면(업무)을 참조하는 다른 화면에서는 필요하지 않은가?

- 예정일자가 지난 경우 어떻게 처리가 될것인가?  Alert 기능이 필요한가?

- 예정일자가 도래하고 있는경우 어떻게 처리해야 하는 것인가? Alert 기능이 필요한가?

- 현재 화면에 예정일자에 대한 조회 조건을 추가해야 하는것인가? 

- 프레임웍에선 어떻게 조회조건을 받고 있는가?

 등등 ... 

고객은 단순히 "도착예정일자가 필요해요" 한마디 한건데 너무 오버 한다고 느껴지는가? 

본인은 그렇지 않다. 실제로 많은 현업들은 지금 생각나는것을 말한다. 

더 실력이 좋은 현업들은 다음,, 그 다음 요구하기 위해 현재의 것을 요청한다. 

최종적으로 요청할 화면 또는 프로세스가 너무 커지므로 조금씩 구현 시켜놓는 것이다. 

고객의 요구를 무시하자는 말이 아니다. 

거의 대부분의 요구에는 컬럼이 필요하고 설계자가 그것을 어떻게 받아 들이는지가

일정과 직접적인 연관이 있으니 이런 작은 쨉(?) 들을 단순하게 받아들이면 안된다는 것이다. 

설계자는 언제나 고객요구사항-일정-개발자-품질 의 한 가운데에 있다.

정해진 기일까지 최상의 품질로 모두를 만족 시켜야 하는 그런 어려운 일을 하고 있다.

그런 설계자 이기에 항상 모든 요구 하나하나에 무게를 두고 일을 해야한다. 

SQL, 우리가 쿼리를 짠다고 하는 .. 그 SQL.

SQL의 작성 순서는 어떻게 될까? 

쿼리 좀 짠다는 사람들은 "쿼리는 집합적 사고방식을 가져야 한다." 라는 말을 

몇번씩 들어 봤을 것이다. 

본인 역시 공감한다. 

단순한 쿼리야 뭐 어떻게든 작성할 수 있지만 

당장 테이블 3,4 개 이상만 조인을 하게 된다고해도 "집합적" 인 사고방식이 아니고서야 

작성 자체가 힘들어 하는 쿼린이들이 있을 것이다.

나보다 더 훌륭한 쿼리 고인돌들이 이글을 보면 뭐라고 할지 모르겠지만 

가장 첫 번째로 생각할 것은 

내가 가져오려고 하는 데이터가 어디에 있는가? 이다 

예를 들어 내가 Select 해야하는 컬럼의 갯수가 20 라고 가정할때 

저 20개 컬럼이 한 테이블에 다 모여 있다면 ?? 매우 Happy 하다. ㅎㅎ

근데 이런일은 없다 ㅠㅠ 

어지간한 데이터 건수가 아니면 집계테이블도 없고 

설사 집계테이블을 생성할 수 있다고 해도 집계테이블의 특성상 

언제나 비동기적이기 때문에 생성 자체를 고민해야 하고 ...

여튼...이건 설계 문제이니 다시 본론으로 돌아와서 

20개의 컬럼이 어디에 분포 되어 있는지를 찾는다.....가 첫번째 할일이다

이를 SQL로 본다면  SELECT * FROM T1, T2, T3, T4, T5 에 해당 될것이다. 

주의점은 SELECT 는 * 로 거들뿐 지금 단계에서는 고민 하지 않는다.

두번째는 이  T1 ~ T5 를 어떻게 연결(JOIN) 할 것인가? 이다. 

이부분은 WHERE 절에 해당 되는 내용이다. 

그러면 남은건? SELECT 에 원하는 20 컬럼을 잘 선택해서 사용 하면 되는것.  이게 세번째 ... 

근데 왜? 쿼리짜는걸 어려워 할까?  쉬운데....

나 어렸을적.. 43분마다 혼나던 시절을 떠올려 보면 

결국 두가지다

1. 원하는 데이터가 TABLE 로 없다...

모든 데이터가 단순히 테이블 조인으로 연결이 된다면 어려울리가 없겠지..

근데 실상은 그렇지가 않다. 

그러니 이 테이블을 SQL상에서 임시로 만들어야 하는 경우가 생긴다. 

이럴때 집합적인 사고방식이 필요하다는 것. 

2. JOIN의 개념을 모른다.

테이블(임시 테이블 포함) 간의 조인을 하는 부부이 어려웠다 

특히 OUTER JOIN과 INNER JOIN

근데 이건 뭐 일단은 공부하고 외우는 수밖에 없다. 

좀더 고급진 조인은 그 다음 문제...

그럼.... 저 두가지 문제를 어떻게 해결 해야 할까? 

그 방법은 다음에 작성하도록 한다.   뿅

자료형 변환

코틀린(Kotlin) 만의 얘기는 아니겠지만 

코틀린에서는 자료형이 다르면 변환하여 대입해 주어야 한다. 

예를 들어 자바의 경우 

int a = 1;
double b = a; 

라고 하면 int 형인 a 를 double형인 b 에 대입하면 

자동으로 a 를 double 형으로 변환해 준다. 더 큰? 자료형으로 변환되는 것.

즉 b 의 값은 1.0 으로 자동 형 변환.

하지만 코틀린 에서는 Type mismatch 오류가 발생한다. 

아래의 예를 보자 

(그리고 자꾸 까먹는데.....코틀린에서 변수선언시 변수 타입의 첫글자는 대문자로 하자 ㅠㅠ)

// 코틀린은 에러를 발생
val a1: Int = 1
val b1: Double = a1 // Int 형 변수인데 왜 Double에 넣음? 이건 에러!
val c1: Int = 1.0 // Int 형 변수인데 왜 소수점 넣음? 이건 에러!

그래서 뒤에 변환 메서드를 붙인다 

// 매우정상
val a1: Int = 1
val b1: Double = a1.toDouble()
val c1: Int = 1

이중등호 & 삼중등호

이중등호(==) 와 삼중등호(===) 는 값만 같은가 주소값 까지 같은가의 차이 이다.

아래를 보자 

// (1) 이중등호 , 삼중등호
val a3: Int = 128
val b3: Int = 128

println(a3 == b3) // true
println(a3 === b3) // true

// (2) 이중등호 , 삼중등호
println("삼중등호 널값 체크")
val a4: Int = 128
val b4: Int? = 128

println(a4 == b4) // true
println(a4 === b4) // false

"// (1)" 의 경우 이중부호, 삼중부호 모두 true 값이 나온다. 

"// (2)" 의 경우 이중부호 true, 삼중부호 false 값이 나온다. 

이유는 (1)의 경우 기본형으로 변환되어 스택에 128을 저장하게 된다. 

하지만 (2)의 경우 Null 값을 허용하는 참조형이므로 참조 주소가 저장되어 있기때문...

그런데 한가지 주의 할 점은 

만약 수치가 -128 ~127 사이에 있다면 모두 true가 나온다 

아래와 같이 ... 
val a4: Int = 123
val b4: Int? = 123

println(a4 == b4) // true
println(a4 === b4) // true 

이는 -128 ~ 127 까지의 값은 캐시에 값을 저장하고 변수는 캐시의 주소값을 가리키기 때문에 그렇다.

코틀린에 어떤 Error 가 있는지 궁금하면?? 클릭 -> [코틀린] 오류코드 정리 :: 리뎁

자료형 과 변수가 궁금 하다면 ? 아래를 클릭 -> [코틀린] 자료형과 변수 & 엘비스 연산자 :: 리뎁

변수 선언

Kotlin에서 변수를 선언할땐 

val 과 var을 구분해야 한다.

val 은 상수값을 대입하기 위해 사용한다.  (최초 지정한 변수값에서 변경할 수 없음)

var 은 변수값을 대입하기 위해 사용한다. 

이때 상수 val 은 자료형(타입)을 선언하지 않으면 Kotlin은 변수에 할당된 값으로 자료형을 자동으로 지정한다.

예를들어 

val userNm = "Gildong" 이라고 하면 userNm은 String 타입으로 자동인식.

물론 val userNm: String ="Gildong" 으로 해도 된다.

var 역시 마찬가지.

자료형 

프로그래밍에서 자료형을 "기본형 자료형" 과 "참조형 자료형" 으로 구분한다. 

코틀린에서는 "참조형 자료형"만 사용한다. 

기본형 과 참조형이 무엇인지 살짝 짚어보면 

예를들어 자바의 경우 

기본형 자료형 : int, long, double 등을 말하고 

참조형 자료형 : String, Date, 사용자가 정의한 객체 등을 말한다. 

아무래도 참조형 보다 기본형이 성능면에서 좀더 우월하다. 

코틀린은 컴파일시 참조형을 기본형으로 대체 되니 성능 최적화를 위한 자료형은 딱히 신경쓰지 않아도 된다.

음... 

혹시 이부분은 참고하는게 좋을 것 같다. 

typealias를 쓰는 경우 아래와 같은 메세지를 만날수 있는데 

Kotlin: Nested and local type aliases are not supported

typealias 선언을 클래스나 오브젝트 안쪽에 넣은 경우 발생한다. 

자료형의 검사와 변환

코틀린은 기본적으로 null 을 허용하지 않는다. 

null 을 허용하려면 ?를 사용해야 한다. 

예를 들어 자바는 

String str = null; 

이런식으로 null 이 허용 되지만 

코틀린은 

var str: String = null 이라고 하거나 

var nullTest: String = "test"

nullTest = null 

라고 하면

Error:(25, 23) Kotlin: Null can not be a value of a non-null type String 

와 같은 오류가 발생한다.

하지만 ?를 사용하여 (여기서 ? 를 Safe Call 이라고 함)

var nullTest: String? ="test"

nullTest = null 

라고 하면 오류가 발생하지 않는다. 또는 단정부호 (!!) 를 사용해도 오류가 발생하지 않는다. 

var nullTest: String?

nullTest = null

println("nullTest: $nullTest length: ${nullTest!!.length}") // 단정부호 !! 를 사용함.

단, 단정부호 !! 사용시 Compile 시에는 오류가 발생하지 않지만 

RunTime 시 아래와 같이 NullPointerException 이 발생할 수 있다.

Exception in thread "main" kotlin.KotlinNullPointerException 
at chap02.section2.VarTestKt.main(varTest.kt:73)
at chap02.section2.VarTestKt.main(varTest.kt)

※ 참고 ※

null 값과 "" 은 다른 값으로 인식함.

Elvis(엘비스) 연산자

코틀린(Kotlin) 에만 있는건 아니지만 여튼 코틀린 에는 엘비스(Elvis) 연산자가 있다. 

?:  <-- 요렇게 사용한다. 

문법 내용은 

aaaa ?: bbbb  엘비스 연산자 ?: 를 기준으로 변수가 null 인지를 검사하여 

null 이 아니면 aaaa를 null 이면 bbbb 를 실행하는 것.  아래와 같이 사용

var nullTest: String?

nullTest = null

println("nullTest: $nullTest length: ${nullTest?.length ?: -999 }") // Safe Call ? 와 엘비스 연산자 ?: 를 같이 사용함.

결국 아래 참고 조건절과 같은 내용인데 단순 조건절을 한줄로 표현 할 수 있으니 가독성 측면에서 

엘비스 연산자가 효율적이다.

참고 : if ( nullTest != null) nullTest.length else -999

자바 또는 다른 언어로 개발해본 사람이면 모두 변수, 자료형, 연산자에 대해 알고 있다.

물론 나 역시 알고있다.

그래서 사실 2장은 그냥 Skip 해도 상관 없지만 

블로그의 목적상 작성하고 넘어간다.

우선 자료형을 공부하기 전에 모듈과 패키지의 개념을 짚고 넘어가자

Project , Module , Package, File 

코틀린의 프로젝트(Project)는 모듈(Module), 팩키지(Package), 파일(File) 로 구성되어 있다. 

당연히 모듈이 가장 큰 단위 -> 파일이 가장 작은 단위라고 보면 된다.

프로젝트(Project)

프로젝트는 최상위 개념이라고 보면 되겠다. 

예를들어 비용등록 프로그램(A), 고객관리 프로그램(B), 수정요청관리 프로그램(C)을 각각 만든다고 하면 

세개의 프로젝트가 될것이다 (물론 저렇게 할 일은 없다....)

모듈(Module) 

모듈은 각각의 프로젝트에 있는 기능(대분류) 단위이다. 

실제 프로젝트시에 보면 모듈을 대분류단위 또는 업무구분 단위로 분리하게 될것이다. 

(구매/영업/생산 ... + 공통영역.. 등등)

예를들어 (A) 프로그램에는 비용등록(A1), 비용코드관리(A2), 거래처관리(A3) .. 등이 모듈이 될것이다. 

패키지(Package) 

패키지는 상황에 따라 좀 다르다. 

기능적으로 분류할 수도있고 작업단위로 분류할 수도 있다. 

프로젝트의 성격과 인원 자사의 Framework 등에 따라 조금씩 다르게 정의할 수 있겠다.

또한 배포의 문제도 감안해야 할 것이다. 

단순 SI인지 솔루션 기반으로 진행할 것인지 등도 감안해야 하겠다. 

어쨋든 지금은 모듈의 하위단에 있다는 정도로 이해하자.

한가지 기억할 점은 

코틀린 파일의 맨 위에는 어떤 패키지에 포함 되었는지 명시해야 한다. 

패키지를 명시하지 않으면 default 패키지에 포함된다.

(파일이 위치한 폴더와 관계없다)

파일(File) 

음.....그렇다. 이건 파일이다.

코틀린 파일의 확장자는 .kt 인데 파일안에 하나의 클래스만 있는경우 프로젝트창에서 .kt 는 생략된다. 

하나의 파일안에 여러개의 클래스가 있는경우 파일은 단순히 클래스를 묶는 역할만을 하고

프로젝트 창에서 .kt 확장자를 볼수 있다. (여러개의 클래스인 경우 상단에 있는 패키지를 인식한다.)

참고로 코틀린은 자바처럼 파일명과 클래스명이 동일 해야하거나

public 클래스를 하나만 써야 하는 규칙은 없다.

팩키지 생성 

IntelliJ 실행 > New 프로젝트(Project) 생성 > 프로젝트 창에서 src 폴더 우클릭 > New > Package 클릭 > 이름짓기 

New 프로젝트 생성을 모른다면 아래 클릭

https://redev.tistory.com/3?category=812832

그러면 src 폴더 밑에 본인이 지어준 팩키지 이름이 보일 것이다.  (나는 com.example.edu 로 했다.)

탐색기를 열어보면 . (점)을 기준으로 폴더가 생긴것을 확인할 수 있다.

팩키지 alias 

예를들어 com.example.edu 의 clss1 을 import 하여 사용한다고 가정하면 

import com.example.edu.clss1 라고

현재 코딩중인 파일의 상단에 이렇게 import할 것이다. 

근데 만약 clss1 이 현재 패키지에 이미 존재한다면 충돌이 날것이다. 

그렇기에 edu.clss1 에 alias를 줄수 있다. 

import com.example.edu.clss1  as eduClass1 과 같은 식으로..

alias 개념은 다 알것이니 설명은 생략하고 

실전에서는 저렇게 쓰는일이 많지는 않을것 같다 

뭐 성능적으로 import com.example.* 와 같은식은 퍼포먼스 측면에서 사용하지 말라고 하긴 하는데

import com.* 수준이 아니라면 import com.example.* 는 어느정도 허용이 될것이다. 

그러면 alias를 쓰지 못할테니....그리고 파일명칭을 충돌시키는 Naming Rule 자체를 권장하지 않는다.

하지만 상황봐서 유용할 수 있으니 알아 두어야겠다.

사실 순서로 보자면 "코틀린 이란?"  또는 "Why Kotlin?" 뭐 이런게 어울릴거 같지만 

여튼 시작해보자

개발환경 Setup 

Kotlin 역시 JDK를 사용한다. 

Oracle 에서 유료화 했으므로 OpenJDK인 Zulu로 JDK를 대신한다. 

아래 주소에서 JDK SE8 다운로드 후 설치 한다. (이미 JDK가 있다면 ??? 그냥 그거 쓰면 된다)

https://www.azul.com/downloads/zulu 

환경변수 설정 

JDK를 설치 했으니 환경변수에 JAVA HOME을 잡아준다.  (역시 이미 설정되어 있다면? Skip ~)

( 음...누군가 이글을 볼지 모르겠는데.... JAVA HOME 설정은 Googling 하시길...

"JAVA HOME 환경변수" 이렇게 검색해 보시면 됩니다. )

Java version 확인

정상적으로 설치 되었다면 cmd 창에서 

java -version 이라고 쓰고 엔터를 치면 

openjdk version "1.8.0_xxx" 뭐 이런식으로 나오면 환경 변수까지는 끝. 

IDE 설치 

IDE 란 Integrated Development Environment 의 약자이다 

직역하면 "통합된 개발 환경" 인데....쉽게 말해 개발 Tool을 의미한다. 

예를들면 Netbeans, Eclipse, IntelliJ IDEA 같은것들...

여기서는 IntelliJ IDEA를 사용한다. (보통은 IntelliJ라고 부른다 "인텔리제이")

(근데....갑자기 궁금해 지는게... intelli 는 intelligent 의 약자일거같고 J 는 Java 겠지...???)

그러니 아래 링크에서 설치 Ultimate는 유료이니...Community에디션을 다운 받는다

https://www.jetbrains.com/idea/download/ 

뭐 테마 설정하고 이런게 있는데 그런건 그냥 "기본값"으로... 하는게 정신건강에 좋다는걸

17년의 감각이 알려주고 있다...ㅋ

또 만났군 HelloWorld ......

이제 프로젝트를 만들어야 한다. 

프로젝트는 "작업하는 프로그램(제품) 단위"라고 이해하면 된다.

IntelliJ 를 실행하면 Welcome 화면이 뜨면 아래 순서로 진행하면 된다.

(1) + Create New Project 클릭 

(2) 왼쪽 리스트에서 Kotlin 선택

(3) 우측 리스트에서 Kotlin/JVM 선택 후 Next

(4) 프로젝트 명 입력창이 뜨면 HelloKotlin 으로 입력 후 [OK] 버튼 클릭

(한글은 사용하지 않는게 역시 건강에 좋다)

참고로 글꼴은 D2Coding 으로 설정해 준다. (File > Settings에서 설정)

(5) 편집기 화면에 main 입력후 [Tab] 버튼을 클릭하면 main() 함수가 만들어진다

fun main(){

   println("Hello redev") 

}

(6) Run 해본다 ( 상단 메뉴 > Run > Run 해도됨.)

"Hello redev" 라는 Text가 IntelliJ 콘솔창에 뜨면 성공

그럼 개발환경 셋팅은 일단 끝.

새벽 1시가 넘었다... .졸립네....