• 며칠전 solnic이 rails를 더이상 쓰지 않는 이유를 썼다. [1]
    • 이 글과 관련 토론을 최근 재밌게 읽었다.
    • 그리고 내 느낀점만 짧게 남겨야 겠다고 생각했다.
  • 일단 나는 ruby와 rails를 좋아한다.
  • 그리고 solnic의 rails에 대한 비판에 공감하는 부분이 많다.
  • solnic의 글은 한 마디로 Rails의 tight-coupling 을 지적하고 있다.
  • 좀 더 자세히는 Rails 에 대해 아래 3가지를 비판하고 있다고 생각한다.
    1. 매우 복잡한 로직을 “쉬운” 인터페이스 뒤에 숨긴다.
    2. 앱의 도메인 로직들이 Rails core features 에 tight-coupling 된다.
    3. ActiveSupport 는 나쁘다.
  • 지적에 공감하지만 나는 여전히 Rails가 좋다.
  • 그리고 오히려 Rails의 장점으로 생각하는 부분이 있다.
  • solnic 은 User.create(params[:user])
    • 이 코드가 “쉬운 인터페이스 뒤에 복잡한 로직이 숨겨져 있다.” 고 지적한다.
    • Rails의 ORM인 ActiveRecord는 지적한 데로
      • 매우 많은 일을 하고,
      • 여러곳에 의존하고,
      • 심지어 web form 데이터 까지 AR에 전달한다.
    • 결벽스러운 소프트웨어 공학자들이 비명을 지를 것이다.
    • domain logic과 framework가 loose-coupling 할 수록 더 좋은 소프트웨어가 맞다.
    • 하지만 (내가 이해하는) Rails way 는 loose-coupling 을 지향하지 않는다.
    • Rails 는 simple 보다 ease-of-use 를 지향한다.
      • (tight-coupling 한 결정이라도, 그것이 쉽고 편하다면 Rails는 그것을 선택한다.)
    • 물론 나도 simple 한 모듈들을 조합하는 방식이 이상적이라고 생각한다.
    • 하지만 매우 loose-coupling 하고, 모듈화된 프레임워크가 장점만 있지 않았다.
      • 프로그래머 별로 조합하는 방식에 일관성이 없고,
      • 여러사람의 손을 거치면 오히려 복잡해지고, 유지보수가 힘들었다.
    • 그래서 나는 Rails way 를 좋아하고, 개인 프로젝트는 Rails 를 사용한다.
  • User.create 는 framework 와 내가 만드는 app 사이의 (일종의) API 이다.
    • API가 사용하기 쉽고, 내부에 복잡한 일을 한다는 건 중요한 문제가 아니라고 생각한다.
    • DB엔진 내부가 복잡하고 자세히 몰라도 우리는 SQL 이라는 인터페이스로 쉽게 조회를 한다.
    • 문이 어떻게 열리는지 내부 구조를 몰라도 우리는 손잡이를 돌려 문을 연다.
  • 중요한 문제는 내부 구조를 확장할 정도로 내가 만드는 앱이 복잡해졌을 때 이다.
    • 예를 들면 MySQL 의 내부구조를 전혀 모르고 SQL 인터페이스로 사용만 해오다가.
      • SELECT 문에 특정 기능을 추가해야 한다면?
      • MySQL 내부구조를 연구해서, 쪼개고, 직접 수정할 것인가?
      • Rails 는 이러한 상황에 우아한 해결책을 주는가?
  • 내 생각에도 Rails 는 이것을 고려해서 만들지도, 또 중요하게 생각하지 않는 것 같다.
  • 내 경험에 한정하면
    • Rails의 내부 구조를 쪼개서 기능 변경을 해야할 정도로 비즈니스 로직이 복잡해 진다면.
    • 일단 내 설계를 의심해왔고, 해결되지 않는 문제는 아직 없었다.
  • ActiveRecord.suppress 와 ActiveSupport 는 나쁜 접근이라는 점에 동의한다.
    • 나도 가능한 안 써야 한다고 생각한다.
    • (다들 쓴다는 점에서 조금 우울하지만…)
  • 나는 무엇보다 사용자가 필요한 기능을 빨리 만들고 변경하는 것을 중요하게 생각한다.
    • MVC, SOLID, 디자인 패턴, DDD 등에 의해 완벽한 소프트웨어를 만드는건 나중에 해도 된다.
      • 이런건 학교에서 열심히 연구하자.
    • 나는 quick and dirty 로 사용자가 원하는 것을 구현하고 나중에 리팩토링 하는 길을 선호한다.
      • quick and dirty 에 최적화된 언어는 PHP 이다.
      • 그게 Facebook, Tumblr 등이 성공한 이유다.
      • 하지만 PHP는 더러운 코드가 유지될 가능성이 높다는 결정적인 단점이 있다.
    • 그런 면에서 Rails 를 사용하며 만족하고 있다.
  • 사실 Rails 를 쓰는 가장 큰 이유는 테스트 코드 작성이 쉽다는 점이다.
    • 난 Java 진영에서 직업으로서의 프로그래밍을 오랫동안 해오면서
      • Java 로 작성된 제대로된 테스트 코드를 본 적이 없다.
    • 사람들은 쉬우면 하고 어려우면 하지 않는다.
    • 대중은 어려운 방향으로 수렴하지 않는다.
    • 테스트 코드 없이는 리팩토링도, 반복된 로직을 줄이는 일도 매우 어렵다.
  • (한 발 더 나가,
    • 요즘엔 테스트 코드 작성과 기존 로직의 “변경”이 어려운 언어/프레임워크를 쓰는 서비스는 실패한다는 편견도 생겼다.)