윤경구의 Log on Java

개발자들의 업무 효율과 관련해서 asynchronous event를 제거하는 것의 중요성은 software development team manager에게 매우 중요한 일이다. 개발은 집중을 요구하는데 context switching 혹은 집중으로부터 벗어나는 계기가 되는 일들이 가끔 있다. 메신저류들, 혹은 메일 notification 등등... 그러한 것들 외에도 습관적인 부분들이 존재한다. 컴파일이 시간이 걸릴 경우 혹은 테스트하기 위해 패키징하는 시간이 걸리는 경우, 테스트를 위해 서버 같은 테스트 환경을 부팅 시키는 데 시간이 걸리는 경우 등등 코딩의 연속성을 벗어나게 되는 일들이 있다. 이때 무엇을 하느냐에 따라 개발 효율이 많이 떨어지게 된다. 컴파일하는 동안 잠시 신문을 읽는다든지 웹 서핑을 한다든지 한다면 이 상황에서는 다시 원래의 집중으로 회복하는 데 최소 30분이 소요된다. 이러한 경우에는 컴파일 몇 번 돌리면 하루가 다 가게 된다. 컴파일하는 도중에 계속해서 같은 문맥의 코딩을 할 수 있다면 가장 좋다. 그것이 안된다면, 이러한 때를 위한 가벼운 읽을거리를 마련해두자. 연예정보가 아닌 개발에 필요한 정보를 습득할 수 있는 거리를.. (적어도 뇌의 같은 부위를 사용하는 일을 하도록 해서 context switching이 발생하지 않도록 .. ^^;;) 잠시 호흡을 가다듬는다거나, 뇌를 쉬게 하는 것도 좋다. 불필요하게 뇌를 다른 문맥에서 헤매게 노동시키는 것을 경계하면 된다. ^^;;

자바에서 serial version uid를 생성하는 것은 기본적으로 서로 다른 클래스들 간의 구별을 하기 위한 것이다. 동일한 이름을 가진 클래스라 하더라도 메소드나 필드가 다를 경우 서로 다른 것으로 인식하는 것이 기본이기 때문에 Object Serialization을 할 때 import/export 등에서 버전에 따라 종종 불일치 에러가 발생하는 것을 만나게 된다. 클래스가 바뀌었다는 것을 기본 serial version uid 계산 알고리즘을 통해서 검출했기 때문이다. 물론 private static final long serialVersionUID = -6120832682080437368L; 와 같이 클래스에 직접 serial version uid 값을 지정해버리면 기본 uid 계산 알고리즘을 사용하지 않고 이 값을 사용하게 되므로 버전에 따른 불일치 에러는 막을 수 있다. 이렇게 하지 않은 경우 사소한 메소드 시그너처 변경으로도 불일치가 발생하게 된다. 기본 uid 값 계산에 사용되는 정보들은 다음과 같다. 1. 클래스 이름 (fully qualified) 2. 클래스의 접근 제한자 (public, final, abstract, 또 interface 여부) 3. 각 멤버 필드의 시그너처 (이름과 접근 제한자, 타입) 4. 각 멤버 메소드의 시그너처 (이름과 접근 제한자, 각 인자별 정보, 리턴 타입) 4. 각 생성자의 시그너처 (접근 제한자, 각 인자별 정보) 5. static initializer block 존재 유무 이러한 값들을 사용하여 적당한 문자열을 만든 다음 SHA 알고리즘을 사용하여 해시값을 계산한 값이 기본 UID 값이 된다. 이때 필드나 메소드, 생성자의 선언 순서는 바뀌더라도 상관없도록 sort를 한다음 계산을 한다. 여기에서 알 수 있듯이 사소한 변경만으로도 기본 suid 값은 변경되게 마련이다. 따라서 serializable 객체로 객체 통신에 사용되는 클래스들은 가능하면 명시적으로 su