[TIL]180319-0325

3 / 19 (월) ~ 25 (일)

1. 면접 회고

간간이 진행되던 면접 일정이 이번주엔 정점에 달했다. 주중 내내 약속이 잡혔고, 월요일에 AWS 자격증 워크샵, 수요일에 2개의 회의, 목요일 삼성 SDS에서 진행되었던 TDD 및 리팩토링 세미나, 토요일 2개의 스터디까지 고려하면 꽤 빡빡한 일정이었다. (다음달 부턴 1개 더 늘텐데 가능한건가 ㅡㅡ.) 면접이 진행되면서 지금 내 현주소를 파악할 수 있었고 간단히 반성해보자면, 우선 나는 아직 개발자로서의 기본 소양이 많이 부족한듯 하다. 합격시켜주려는 질문들에 횡설수설하는 내 자신이 참 한심스러운 시간들이었다. 물론 최근 다른 여러가지에 흥미가 많았던 것도 사실이고, 처음에 C언어 배울때에 자료구조를 쉽게 접근하여 그동안 우선순위에서 미뤄뒀던 것도 있지만, 결과적으로는 지금의 나는 기초가 부실한 개발자라는 것. 원래도 취업 준비 중보다는 입사 후에 꾸준하게 해야겠다고 생각하고는 있었으나, 이번 기회에 그 당위성을 확실히 느꼈다. 그럼에도 긍정적으로 봐주시고 좋은 기회를 주신 분들께 너무너무 감사한 시간들이었다. 

2. SDS

작은 밋업하나 하는데 촬영 장비들도 많고, 진행하시는 분이나 구성들, 간식 등 세심하게 많이 준비했다는 것이 곳곳에 보였다. 첫 세션에선 "클린코드란 무엇인가?" 라는 주제로 클린코드에 대한 각 주제 및 키워드들을 소개하는 시간이었고, 2번째 세션에선 리팩토링에 대한 경험을 주는 시간이었다. 밋업이 끝나고 드는 생각은, '너무 많은 욕심을 냈던 것 같다'. 

첫번째 세션의 주제만을 가지고 핸즈온을 통해 이를 직접 체험하는 형태로 진행이 되던가, 2번째 세션의 주제만을 가지고 테스트 코드 작성에 대한 경험, 직접 IDE를 활용하여 리팩토링 하는 경험들을 주었으면 좋았을 듯 싶다. 결과적으로는 첫번째 세션에선 으레 아는 주제들을 잘 정리한 피피티를 보는 느낌이었고, 두번째 세션은 리팩토링의 각 요소보다는 순수하게 '타이핑' 해야 할 부분들이 많아 유즈케이스를 잘 모르는 상태에서 변수명도 이상한 그 예제를 화면을 보고 계속 따라하는 장면들이 연출되었고 나중에는 다들 그냥 화면을 보고 있을 뿐이었다. (IDE를 좀 더 잘 활용하자는 생각이 들었던 부분은 좋았었다.) 흠.. TDD 및 리팩토링을 재성이 형한테 배우고 봐왔어서, 기대치가 너무 높아진 탓일련지..

그리고 마지막에 휴가 했던 질문과 관련하여 궁금증이 하나 생기기는 했다. 물론 현업에서는 시니어 개발자들이 있으니 이 날의 예제와 같은 레거시 코드가 나올리는 만무하다만, 리팩토링 중에 테스트코드에 의존성있는 클래스나 인터페이스가 변경되어야 할 경우에 어떻게 해야할까.. 그냥 드는 생각은, 해당 기능이 다른 api에도 의존관계가 있다면 관련 부서가 모여 구조에 대한 논의 후 명세를 바꾸고 테스트코드를 재작성한 후 변경하기 전까지는 각 단위는 그대로 유지해야하지 않을까.. 

package com.gildedrose;
 
class GildedRose {
    private static final String SULFURAS = "Sulfuras, Hand of Ragnaros";
    private static final String BACKSTAGE = "Backstage passes to a TAFKAL80ETC concert";
    private static final String AGED_BRIE = "Aged Brie";
    Item[] items;
 
    public GildedRose(Item[] items) {
        this.items = items;
    }
 
    public void updateQuality() {
        for (int i = 0; i < items.length; i++) {
            Item item = items[i];
            if (item.name.equals(AGED_BRIE)) {
                AgedBrieItem agedBrieItem = new AgedBrieItem(item);
                agedBrieItem.updateQuality();
 
            } else if (item.name.equals(BACKSTAGE)) {
                BackstageItem backstageItem = new BackstageItem(item);
                backstageItem.updateQuality();
            } else if (item.name.equals(SULFURAS)) {
                SulfurasItem sulfurasItem = new SulfurasItem(item);
                updateQualityForSulfurasItem(item);
            } else {
                NormalItem normalItem = new NormalItem(item);
                updateQualityForNormalItem(item);
 
            }
 
            if (item.name.equals(SULFURAS)) {
            } else {
                item.sellIn = item.sellIn - 1;
            }
 
        }
    }
 
    private void updateQualityForNormalItem(Item item) {
        if (item.quality > 0) {
            item.quality = item.quality - 1;
        }
        if (item.sellIn < 1) {
            if (item.quality > 0) {
 
                item.quality = item.quality - 1;
            }
        }
    }
 
    private void updateQualityForSulfurasItem(Item item) {
        if (item.quality > 0) {
        }
        if (item.sellIn < 0) {
            if (item.quality > 0) {
            }
        }
    }
}

이 코드에서 AGED_BRIE, SULFURAS 등을 클래스를 빼는 과정에서 공통된 부분을 추상클래스로 두고 상속받도록 리팩토링 하는 단계였다. 하단처럼 GildedRoseItem 보다는 Item 클래스를 추상클래스로 만들 경우 테스트코드에서 에러가 난다. 

package com.gildedrose;
 
public abstract class GildedRoseItem {
 
    public GildedRoseItem() {
        super();
    }
 
    public abstract void updateQuality();
    public abstract void updateSellIn();
}

3. 스터디

이번주에 딱히 무언가를 한건 아닌데, 계속 미루다가 금요일 밤에 급하게 하느라 제대로 준비를 못했다. 알고리즘 스터디는 그냥 코딜리티 문제 하나 풀고 코딩인터뷰완전분석 챕터하나 읽고 갔는데(책의 문제도 사실 제대로 풀지는..) 코딜리티 문제는 리팩토링이나 성능 등에 대해 고려해보지도 않았다. 토요일 스터디 시간엔 지난 시간에 해결하지 못했던 부분들에 대해 먼저 이야기를 했는데, 다양한 언어들을 간접적으로 느낄 수 있어서 신선했고 다들 스터디 준비들을 잘 해오셔서(ㅠ.ㅠ) 내내 부끄러웠다. 그 중 D3를 이용해서 알고리즘 순회시의 각 노드들을 가시적으로 표현한 분이 있었는데, big-O를 그런 형태로 이해하게 되니 굉장히 신선했는데... 이미 그런 컨텐츠들이 있다고 하는 .. 

SQL 스터디의 경우 책을 읽는 내내 이해가 잘 안되었는데, 리더분 덕분에 참 많은 것을 배워가는 것 같다. 이번 시간에는 실행계획을 읽는 법에 대해 확실히 알게 된 것 같고 스칼라서브쿼리/인라인뷰서브쿼리/서브쿼리 랄까, Filter/Join 간의 비교랄까, Nested Loop Join/Hash Join/Sorted Merge Join 등에 대해 생각해볼 수 있는 시간이었다. 무엇보다 이제 Hint문에 대한 막연한 두려움이 사라진 거 같다.  

주일동안 OOA&D를 빨리 읽고 마무리 지을 생각이고, 장고 스터디 준비도 마무리지을 생각이다. 장고가 어느정도 완숙도가 오르면 간단한 토이프로젝트를 하나 진행할 생각이다.(모두의학원 백오피스 혹은 아버지를 위한 장부 및 명함관리 웹서비스 혹은 경제학 학습을 위한 웹 서비스 등으로 컨셉을 잡고 있다.) 그리고 다음달엔 코틀린과 DDD를 슬슬 시작할까 생각 중이다. 

4. 유지보수

네이버 및 넥슨 개발자 분들이 들어오셨다. 그동안 IDC 서버에 직접 접근하여 작업했었는데, (그 서버에 gitlab, redmine, jenkins도 같이 설치해두고 작업 진행중이었다.) 금요일 새벽에 급하게 AWS에 테스트 환경만들어드리니 액티브하게 작업하신다. 나는 php 레거시 코드가 너무 보기 싫어서 각종 핑계대면서 미루고 있었는데 정말 반성해야겠다. 

5. late binding

시작은 상코의 질문이었다. 

public class TurboPlane extends Plane implements Turbo {
 
    @Override
    public void boost() {
        System.out.println("TurboPlane boost");
    }
    
    @Override
    public void fly() {
        System.out.println("TurboPlane fly");
    }
 
    
    public static void main(String[] args) {
        Plane plane = new TurboPlane();
        plane.fly();
    }
    
    public void babo() {
        System.out.println("바보");
    }
}
 
class Plane {
    public void fly() {
        System.out.println("Plane");
    }
}
 
interface Turbo {
    public void boost();
}

Plane plane = new TurboPlane();
        plane.fly();

이 경우 "TurboPlane fly"가 출력되는 부분은 당연히 그러려니하고 생각했었다. 이러한 경우 자식에만 있는 메서드는 사용이 불가하고 plane 인스턴스가 fly를 메서드를 실행할 때는 override된 fly 메소드를 실행할 거란 부분에서, 왜? 라는 생각이 들 부분은 없었기 때문.

논란이 됬던 것은 상코가 '상위 타입으로 하면 JVM에서 상위타입을 쳐다본다던데 상위타입을 쳐다보는데 재정의한 메서드는 자식의 것을 읽어온다는 것이 이해가 되지 않는다'고 했던 부분이다. 관련하여 검색하다 괜찮은 자료를 찾았다.

baseclass is also the superclass that you think. 
Inheritance means that child already have the all attributes/properties/methods_and_variables that the parents have if they are in the same package. 
Child can do anything that he can do and what the parent can do by inheriting it. 
Therefore parent don't need to run anymore because child already know what the parent can do.
 
If you execute the parent, 
child is not executed and parent don't have the child attributes. 
If you execute the child with inheritance to parent. 
The child is executed with parents attribute but the parent itself is not.

[메모리의 4대 특징]  
  1. 자식이 생성되면 부모도 생성된다.
  2. 자식의 설계도가 사용되면 부모의 설계도를 같이 사용한다.
  3. 주소는 부모쪽의 주소를 사용한다.
  4. 설계도에 공개된 메소드만 사용할 수 있다.

[Polymorphism의 3대 특징]
  1. 부모의 이름으로 자식을 생성할 수 있다.
  2. 부모의 타입으로 자식을 받을 수 있다.
  3. 부모의 메소드로 자식의 메소드를 호출할 수 있다.

그리고 우리가 궁금했던 답은 해결되었다.

 "JVM에 의해서 자동으로 VMI(Virtual Method Invocation)이 일어나서  Overriding이 있을 경우 자식의 메소드가 호출된다" 

그런데 여기서 말하는 VMI란 무엇일까? 

 
## What do you understand by late binding or virtual method Invocation ?
 
## late binding 또는  virtual method Invocation로 무엇을 이해합니까?
 
When a compiler for a non object oriented language comes across a method invocation, it determines exactly what target code should be called and build machine language to represent that call. In an object oriented language, this is not possible since the proper code to invoke is determined based upon the class if the object being used to make the call, not the type of the variable. Instead code is generated that will allow the decision to be made at run time. This delayed decision making is called as late binding 
 
비 객체 지향 언어를 위한 컴파일러가 메소드 호출을 가로 질러 오면, 
정확히 어떤 타겟 코드가 호출되어야 하는지를 결정하고 그 호출을 표현하기위한 기계어를 빌드한다. 
객체 지향 언어에서는 호출 할 적절한 코드가 변수의 형식이 아니라 호출하는 데 사용되는 경우 클래스를 기반으로 결정되기 때문에 가능하지 않습니다. 
대신 런타임에 결정을 내릴 수있는 코드가 생성됩니다. 지연된 의사 결정은 지연 바인딩이라고합니다.

late binding을 보다보니 JPA의 lazy loading이 생각나서 찾아보다 관련하여 이런 자료가 있어 공유해본다.

https://softwareengineering.stackexchange.com/questions/200115/what-is-early-and-late-binding

http://www.it.uu.se/research/group/udbl/Theses/StaffanFlodinLic.pdf