제이제이랩

최근에 Jake Warton의 Retrofit 라이브러리 발표 영상을 보고 추상화에 대해서 곰곰히 생각해 보았습니다. 아래 동영상인데요. Jake Warton의 발표를 보면 header abstraction, response abstraction, Call encapsulation 등의 용어를 사용하여 Retrofit을 설명합니다. 이 부분이 저에게는 좀 충격으로 다가왔는데요. 내가 OOP 개념에 대해 대학교 때 공부한 이후에 고민해 본적이 있는가? 나는 코드 설계할때 뭘 고려하지? 나는 저런 용어를 사용하여 내 코드를 설명할 수 있는가? 등등의 생각이 들었드랬죠.

애플리케이션 개발자는 기획에서 내려온 요구사항은 기본적으로 만족시켜야 하고 차후 변경에도 유연하고 확장성 있는 코드를 설계하고 구현 해야합니다. 이 글에서는 유지 보수 용이하고 확장성 있는 코드를 설계하고 구현하기 위해선 뭐가 중요할까 고민해 보는데 그 핵심은 추상화로 보고 고민해 볼까 합니다.

추상화라는 것을 간단하게 말하면 복잡한 것을 간추려서 간단하게 하는 것인데요. 사실 추상화라는 개념은 인간의 사고 방식과 빼놓을 수 없을 것 같습니다. 어떤  유무형의 사물을 볼 때 내 기준에 비추어서 흥미있고 필요한 부분만을 보고 그것에 대해 머리속으로 간단히 기억합니다. 제 생각엔 이미 인간의 인식, 사고, 기억하는 단계에 이미 추상화를 하고 있는것으로 보입니다. 대부분의 사물의 복잡하고 자세한 내부는 외부에 감추어져 있고 사람이란 동물은 꼭 필요하지 않으면 시간 써가면 자세한 내부사항은 알 필요가 없죠. 

만약 자신의 고용주가 어떤 개발 프로젝트를 따와서 본인에게 던져줬다고 합시다. 음, 구체적인게 좋겠군요. 자동차 중고매매 사업장에서 각 딜러가 어떤 차를 누구에게 팔았고, 어떤 차가 재고로 있으며 어떤 차가 새로 들어왔는지등을 확인할 수 있는 애플리케이션 개발을 해야한다고 합시다. 그럼 이 애플리케이션 개발하기 앞서 설계를 하고 개발을 해야하겠는데요. 시스템의 전체적인 설계는 소프트웨어 아키텍쳐 패턴에서 적절한 패턴을 이미 선택했다고 가정하고 이 시스템을 구성하는 객체가 무엇이 있는지 각 관계는 무엇인지 파악하는 단계로 들어섰다고 합시다.

그래서 자동차(Car)를 설계해야 하는데, 요구사항이 무엇인지에 따라 차후 어떤 변경이 있을지에 따라 자동차의 추상화 수준을 결정해야 합니다. 자동차 추상화(Car abstraction)작업을 그럼 해볼까요?

개인적으로 안드로이드 UI 개발할 때 ButterKnife를 애용합니다.

제가 ButterKnife를 쓰는 가장 중요한 이유는 각 View, Resource Look-up 타임을 없애주고 다수의 안드로이드 개발자들과 협업할때 View, Resource를 바인딩 하는 convention을 제공하기 때문입니다. 성능상 단점이나 장점은 없지만 코드의 가독성을 높여주는데 참 좋은것 같습니다.

http://jakewharton.github.io/butterknife/ 

위 사이트에 가면 제가 중요하게 생각하는 점이 다 설명되어 있는데요.  Activity에서 @Bind, @BindColor, @BindString등의  annotation을 onCreate() 메소드 위에서 명시하여 사용하는게 일반적입니다. 각 멤버 변수가 레이아웃의 어느 뷰와 연결되어 있는지 한눈에 알 수 있습니다. String, Color, Drawable같은 리소스도 아래와 같이 onCreate() 메소드 위에서 다 바인딩하여 사용하는게 일반적인데 이러한 컨벤션을 지키면 소스 코드가 정말 깔끔해 집니다. 그리고 각 리소스와 뷰가 어디에 바인딩 되어 있는지 1초도 안되어 알 수 있습니다.

class ExampleActivity extends Activity {
  @Bind(R.id.title) TextView title;
  @Bind(R.id.subtitle) TextView subtitle;
  @Bind(R.id.footer) TextView footer;

  @Override public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.simple_activity);
    ButterKnife.bind(this);
    // TODO Use fields...
  }
}

만일 Activity.findViewById() 메소드를 사용하면 어떤 일이 벌어질까요? 아래 코드를 보시죠.

class ExampleActivity extends Activity {
  TextView title;
  TextView subtitle;
  TextView footer;

  @Override public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.simple_activity);

    title = findViewById(R.id.title);
    subtitle = findViewById(R.id.subtitle);
    footer = findViewById(R.id.footer);
    // TODO Use fields...
  }
}

ButterKnife 없는 코드는 아래와 같이 Activity.findViewById()를 사용하여 바인딩을 해줘야 하는데요. 일명 boilerplate 코드이지요. 또 중요한 건 여러 개발자들과 같이 작업하다보면 Activity.findViewById() 메소드를 이곳 저곳 그곳에서 호출하여 어떤 멤버 변수가 어떤 View, Resource와 바인딩 되어 있는지 찾기가 쉽지 않습니다. ButterKnife로는 1초만에 걸리던게 적게는 수초 많게는 수십초이상이 걸리는데요. UI 개발하면서 개발자가 각 멤버 변수가 어떤 뷰, 리소스에 바인딩 되어있는지 항상 기억하지 못하기 때문에 이를 알기 위해 look-up 을 자주 합니다. 이렇게 자주하는 행위를 ButterKnife를 이용해 해쉬 처럼 빠르게 스트레스 안받고 작업하는 것과 바인딩 포인트를 찾을 때까지 탐색하는 것은 분명 차이가 있습니다. 게으른 코딩을 하기 위해 ButterKnife를 사용해 보시는건 어떠시나요? 완벽히 익히는데 1시간도 걸리지 않습니다. 그리곤 게을러 질 수 있어요. 아래 사이트 참고하셔서 굿 코딩하세요.

http://jakewharton.github.io/butterknife/

추가로 ButterKnife는  클릭 이벤트 핸들러를 annotation으로 명시하고 처리할 수 있습니다. 이 또한 기존의 클릭 이벤트 처리하면서 발생한 boilerplate 코드를 제거한겁니다.

요 아래는 안드로이드 스튜이오 플러그인입니다. 자동으로 layout xml의 뷰에 해당하는 멤버변수를 만들어 주네요~! 엄청 편합니다.

https://github.com/avast/android-butterknife-zelezny

이벤트 Bus Otto에 대한 두번째 글입니다.

http://tmondev.blog.me/220610369558