이제는 순수 객체 지향 언어(JAVA)는 보내주어야 할 것 같다

1. 아무리 생각해도 객체지향은 프로그램의 복잡성을 증가시키는 것 같다.

2. 복잡성 보다 더 큰 문제는 객체지향설계를 그대로 구현할 수가 없다는 점이다. 설계현실과 코딩현실의 불일치이다.

  2-1 객체 지향설계를 해놓아도 사실 웹에 적용할 경우에는 그대로 사용할 수가 없다. MVC나 DDD가 훨씬 실용적이다.

  2-2 웹만 그런 것이 아니라 데스크톱 프로그램도 마찬가지이다.

  2-3 결국 의미가 있으려면 UI가 없는 네트워크 프로그램 같은 것에나 적용가능하다. 이게 사실 의미가 없다.

  2-4 글로벌 기업의 객체지향 면접(System Design)은 그다지 큰 의미가 없어 보인다. 일반적으로 설계한대로 만들게 되면 보통 단일 스레드의 콘솔프로그램이 되고 만다. 그냥 데이터 기반 설계가 훨씬 낫다.

 

3. 재활용이니 관심사의 분리니 해도 현업에서는 이런 거 별로 의미가 없다.

4. 결국은 이해하기 쉬운 것이 가장 좋다. 심플하고 확장하기 좋은 구조를 목표로 하는 것이 좀 더 실용적이다.

5. 자바 스크립트와 자바는 소스 구조를 파악하는 데 너무 힘이 든다. 

  5-1 자바스크립트는 워낙 언어의 자유도가 높아서 이해하기가 쉽지 않고(자바 라이브러리 보다는 이해하기가 수월하다.)

  5-2 자바는 오버엔지니어링으로 인해 구조를 파악하기가 너무 어렵다. 구조를 파악을 하기 위한 기본자료가 많지 않다.

 

6. 결국은 GO와 Scala인데 이런 객체 기반 함수형 언어가 가장 이해하기 쉽다는 결론에 도달했다.

  6-1 GO는 언어가 존나 간단해서 소스를 보면 보통  이해가 된다. 네트워크에서 웹까지 거의 그렇다. 물론 인터페이스가 명시적으로 구현되지 않기 때문에 구조를 이해하는데 어느 정도의 노력이 필요하긴 하다.

    6-1-1 게다가 컴파일언어라서 굉장히 빠르다.

  6-2 Scala 역시 자바와는 달리 구조파악이 용이하고 빠른 개발이 가능하다. 

 

7. 자바스크립트나 파이썬 같이 자유도가 높은 언어는 개인적으로 잘 안 맞는 것 같다. 물론 타입이 없다는 점이 때때로는 엄청난 개발시간 단축을 가져온다는 걸 알고 있다. 언어는 필요에 따른 선택의 문제다. 나에게는 C언어가 아직도 젤 편하다.

 

8. 한가지 더 남기자면 JSON vs Protocol Buffer 

  8-1 Protocol Buffer는 수많은 장점에도 불구하고 쓰레기라고 생각한다. 복잡하면 아무도 안쓴다.

    8-1-0 바이트 기반이라 개발자가 디버깅하기가 어렵다는 점이 치명적이다. 개발자 비용이 네트워크 속도보다 중요하다.

    8-1-1 성능 떨어져도 JSON이 최고다. gRPC를 쓰려고 ProtoBuf을 쓰는 건 오버라는 생각이다.

    8-1-2 장담하는데 JSON 유사한 형식을 기반의 사용하는 HTTP2, HTTP3를 사용한 서비스 구현이 분명히 나올 거다.

    8-1-3 GO에는 gRPC라는 공식이 존재하는 듯한데, REST를 대체하는 무언가가 필요하지만 gRPC는 아닌 것 같다.

    8-1-4 gRPC는 protocol buffer 때문에 CORBA와 유사한 길을 걸을 것이라고 확신한다.