2017년 1월부터 3월까지 회고록

3월 25일 한해의 초라고 해도 맞는 말이긴 한데

지난 한 해를 돌아보면 시간인 초고속으로 흐르고 중간 중간 생각하면서 살지 않으면 

헛되이 보내버리는 시간이 많아지기때문에 갑작스럽게 글을 쓰기 시작했다.

2017년에 들어와서 공부만 놓고 본다면

1. Spark 스터디 참여 ( 2번 발표 )

2. JPA 스터디 참여 ( 1번 발표 ) 

3. Java 8 스터디 참여

4. 루씬 참여 3월~ 5일 종료예정

- 루씬을 공부한건 내 개발 인생에 있어서 가장 잘한 일중에 하나라고 생각해도 될정도로 

폭을 넓혀가고 있다

목표

4 월달에는 Spring4 스터디가 예정되어있고

5월달에는 루씬을 쭈욱 이어갈것이고

6월달에는 Solr 랑 Elastic Search 중 하나를 시작하지 않을 까 생각한다.

그리고 회사에서 서비스 개편들어가기때문에 바빠질것 같은데..

개인적으로 몇권의 책을 더 보고자 한다면

1. 클린코더,

2. Hbase

3. 조엘온 소프트웨어

4. Effective 자바

5. 머신러닝에 대해서 조금 깊게 공부를 해볼 생각이다

사실 알고리즘을 꾸준히 더 공부를 하고 싶긴 한데..

올해는 알고리즘보단 서비스를 꾸리기 위한 지식의 폭을 조금 더 넓혀볼 예정이다.

요즘 쉬는날이 없이 공부를 하지만..

알아간다는 즐거움은 날로날로 증가한다.

Effective Java 규칙10 toString은 항상 재정의하라

toString 값을 항상 재정의 하라고 나온다.

"모든 하위 클래스는 이 메서드를 재정의함이 바람직하다"

만약에 재정의 하지 않게 되면..
클래스이름@16진수해쉬코드 로 표현이 되는데

PhoneNumber@163b91 과 같은 사람이 인지하기에는어려움이 있다.
만약에 재정의 한다면 010-xxx-xxxx 처럼 읽기 쉽고, 명확해진다.


어떤사람들은 toString값을 파싱해서 사용하는 사람도 있다.
toString값에 이게 어떠한 값이들어있는지 주석을 달고 명시해주는것도 좋고
만약에 변동될 수 있는 사항이라면 그러한 내용을 담은 주석을 달아놓는것도 좋다.

나는 모든 클래스에 대해서 toString값을 재정의 하지 않는다.
책에서는 하라고 했는데 그냥 필요시에만 해도 여태까지 불편함없이 충분히 잘 개발해오고 debug 해왔다고 생각한다.

머 장점이라고 한다면 컬렌셕을 출력했을때 쉽게 해당 내용을 찾아볼수 있다는것??

모든 클래스 재정의는 한번 생각해볼필요가 있다.

Effective Java 규칙9 equals를 재정의 할때는 반드시 hashCode도 재정의해라

책의 내용이 너무 좋긴 한데 이렇게 긴글을 다 간추리기는 불가능하므로 

느낀점만 작성한다.

그리고 규칙이 띄엄띄엄 블로그에 올라올텐데

완전하게 이해가 안되는 부분은 한 사이클을 돌고 난후 두번째 읽으면서 이해가 되면 올릴 예정이다.

만약에 예를 들어

HashMap<PhoneNumber, String> 의 객체에 new PhoneNumber를 set하고

다시 똑같은 값의 객체를 생성해서 new PhoneNumber get을 하게 되는 경우

hashCode 를 재정의 하지 않은 경우 return의 null 값을 반환하게 된다.

그 이유는 각가 다른 Hash를 가지고 있기때문에 equals로 똑같은 객체라고 판단을 해도 서로 다른 hash bucket을 다이렉트로 참조 하려고 하기 때문이다.

hash code를 정의하는 알고리즘은 있을텐데...

이클립스에서는 자동으로 생성해주는것 같고..

나중에 알고리즘을 한번 읽어봐야겠다..

확실히 책을 읽으니깐 그전에 몰랐던 내용이 이해되는 부분이 많다.