1. Static Checking

이 강의를 듣게 된 이유 중 하나는, 교과서적으로 software 구조의 기초를 알고 싶었고, testing과 좋은 코드를 작성하는 방법에 대해서 알려 주기도 하고, Java로 진행되기 때문에 이 수업을 https://openlearninglibrary.mit.edu/를 통해서 수강하기로 계획했다.

 

오늘 들은 강의에서는 2가지 주제를 메인으로 다룬다. 

• static typing
• 좋은 소프트웨어의 큰 세가지 특성

이 수업을 통해서 어떻게 좋은 코드를 작성하는건지에 대해 배우는 것이기 때문에, 좋은 소프트웨어의 큰 세가지 특성은 다음과 같다. 

1. bug로 부터 안전함

2. 다른 프로그래머가 이해하기 쉬운 코드 작성

3. 미래의 변화에 대한 준비가 되어 있어야 한다.

 

Hailstone Sequence로 보는 파이썬과 자바의 차이점

n으로 시작하여, n이 짝수일때 다음 숫자는 n/2가 되고, 홀수일 경우 3n+1이 되며 시퀀스가 1에 도착하면 끝이 난다.

아래와 같은 서열을 말한다.

 

 

 

 

 

이러한 sequence를 출력하는 코드를 자바와 파이썬으로 작성해보면 다음과 같다.

Java와 python 비교

자바와 파이썬의 유사한 점은 주요한 statement, operator, expression은 동일하다. (while문, if문..) 

하지만 syntactic차이가 있는데, 자바는 세미콜론이 필수적이고, 조건에 괄호가 들어가며 { } 를 사용한다. 반면 파이선은 들여쓰기를 반드시 해야 에러가 안생기지만 자바는 들여쓰기를 하는 이유는 인간이 보기 좋으라고 하는 것이다.

프로그래밍은 의사소통의 형태이기 때문에 컴퓨터에만 소통하는것이 아닌 인간과도 소통을 해야한다.

 

자바에는 알다싶히 primitive type과 object type이 있고 input을 받아 output을 리턴하는 operation이 있다. type이라는 것이 자바에서는 명시가 되어 있기 때문에 + - * / 같은 연산자들의 오버로딩이 많이 되어 있다.

 

1. Static Typing 

자바와 파이썬의 가장 큰 의미론적으로 다른점은 타입을 명시해주냐 안해주냐의 차이이다.

자바는 statically-typed language이다. 모든 변수의 타입이 실행 전 컴파일때 알고 있기 때문에 컴파일러가 모든 expression의 타입 또한 추측할 수 있다.  (a와 b가 int로 선언되었으면 a+b도 int일것임)

반면 파이썬은 dynamically-typed language이다. 런타임에 되어서야 체크를 할 수 있다.

 

static typing은 static checking이라고 볼수 있는데, static checking이란 컴파일 타임에 버그를 체크 할수 있다는 것이다. 따라서 static typing을 사용하면 좋은 점이 버그를 사전에 더 줄일 수 있다는 것이다.

자바는 compile 시에 에러를 잡아준다.

python은 실행하고 나서야 에러를 발생시킨다.

2.  Automatic checking의 3가지 종류

1) Static checking : 프로그램이 실행되기 전에 자동으로 버그 발견

 - 구문적 오류. 파이썬에서도 indent안하면 에러 발생시키는것이 여기에 들어감. 타입과 관련되어 있어서 변수가 가진 특정한 값과는 무관한 에러임. 타입 검사를 하지만 어떤 값을 가지고 있는지는 런타임에 되어서야 할 수 있다.

 - 틀린 이름 ex) Math.sine(2)

 - 틀린 argument ex) Math.sin(20,30)

 - 틀린 리턴값. int를 반환해야하는 function이 string을 반환하는 경우.

 

2) Dynamic checking : 프로그램이 실행될때 버그 발견. 특정한 값에 의해서 발생되는 에러.

 - Illegal arguement 값. ex) 0으로 나누는 경우. 

 -  나타낼수 없는 값을 리턴하는 경우 ex) 특정 값이 type으로 표현 불가능

 - out-of-range index ex) index로 음수나 범위 밖의 수를 입력하는 경우

 - null 객체 레퍼런스를 메소드가 부르는 경우

 

3) No checking : 전혀 에러를 알려주지 않는 언어. 틀린 결과가 나올 수 있기에 주의해야함.

 

* 자바의 Primitive type은 실제 숫자가 아니다.

 - 자바 뿐만 아리나 많은 프로그래밍 언어가 실제 숫자처럼 행동하지 않는 경우가 있다. 그래서 몇 에러는 dynamic checking을 통해서 안잡히는 것들이 있다.

• Integer division.(정수 나눗셈)

result type을 double로 변환해도 동일하다.

아무 에러를 발생시키지 않는다.

• Integer overflow : int와 long 타입은 실제적으로 범위가 유한하다. 범위를 벗어나면 overflow가 발생하여 나타낼수 있는 범위의 이상한 값이 도출된다.

public class Test {
    public static void main(String[] args) {
        int overflow = 2_000_000_000 * 2_000_000_000;
        System.out.println(overflow);
    }
}

결과값

• floating-point type의 특별한 값 : double type과 같은 floating-point type은 실제 숫자가 아닌 특별한 값을 가지고 있다.  (NaN, POSITIVE_INFINITY, NEGATIVE_INFINITY) 따라서 dynamic error를 발생시킬것으로 예상되는 (0으로 나누거나 루트안에 음수)값을 출력하면 실제 값이 아닌 위와 같은 특별한 값을 받게 되고 계속해서 계산할 경우 결국 엉뚱한 답을 도출시킨다.

3. Array와 Collections.

위의 Hailstone Sequence의 결과값을 담을때, 우리는 크기가 고정된 type인 array를 사용할 수 도 있고 크기를 변환 시킬 수 있는 List type을 사용할 수도 있다. 크기가 어떻게 될지 모르기 때문에 고정된 array보다는 변환시키는 list를 사용하는것이 합리적이다.

메소드를 작성하기 전에 주석을 작성하는 것이 매우 중요하다. 주석은 clear하고 정확해야한다. 메소드 부르는 사람이 알아야 하는 정보를 기입해야 한다. 

프로그래밍은 추정의로 가득하기 때문에, 적지 않으면 우리는 기억을 못하고, 다른 사람이 읽거나 우리 프로그램을 나중에 바꿀때 알지 못하고 추정을 다시해야한다. 따라서 반드시 자바가 자동으로 체크하지 못하는 assumption에 대해서 document로 작성해야한다.

 

4. mutating 값 vs 재할당 해야하는 immutable 값

• 예를들어 변수에 값을 할당할때, 변수가 가리키는 방향을 계속 바꾼다.

• array나 list와 같은 mutable value의 내용을 바꾼다면, 값 안에서의 reference값을 바꾸는 것인데, 이것을 값을 mutating 한다고 한다.

  

Immutable 값과 Mutable값

• String의 경우, 값을 재할당하면 immutable type이기 때문에 다음과 같다. (immutable value에 대한 mutable reference) 

  

• 반면 StringBuilder는 mutable 객체이기 때문에 객체의 값을 메소드로 변경 할 수 있다. (mutable value에 대한 immutable reference)

StringBuilder sb = new StringBuilder("a");
sb.append("b");

 

• Immutable reference

- 자바는 immutable reference한 제공하는데, 한번 할당된 변수는 다시 절대 재할당 될 수 없도록 하게 해준다. reference를 immutable하게 만들려면 final 키워드를 사용하면 된다. final은 immutable reference에 대한 static checking을 제공한다. 따라서 가능한한 많은 지역 변수와 메소드의 매개변수를 선언할때 final 을 사용하는 것은 좋은 관습이다.

 

5. 이 강의의 목적

1. bug로 부터 안전함

2. 다른 프로그래머가 이해하기 쉬운 코드 작성.

 - 미래의 프로그래머가 이해하고 바꿀 수 있도록 소통할줄 알아야한다.

3. 미래의 변화에 대한 준비가 되어 있어야 한다.

 - 소프트웨어는 항상 변한다. 그러한 변화를 쉽게 디자인 해야한다. 

 

개인적인 정리 ) 위의 목적을 위해서 checking의 종류를 알고, 오늘 컴파일 시의 static checking과 런타임시의 dynamic checking의 차이점과 중요함을 알았다. 단순 컴퓨터 뿐만이 아닌 인간인 프로그래머와 대화를 하기 위해서 주석에서의documented assumption 중요성 또한 알수 있었고, final키워드를 사용하면 static checking이 되기에 버그로 부터 안전하며 이해하기도 쉽다는 것을 알았다. dynamic checking에도 잡히지 않는 에러에 대해서는 각별하게 유의하고 있어야 한다는 생각이 들었고, 자바가 장황한 만큼 또한 이점도 많다는 생각이 든다.