코드 라이브러리가 시간의 시련을 이겨낼 수 있는 5가지 방법

이것은 일련의 문장 중의 첫 번째 문장이다
나는 우리가 지난 3년 동안 거대하고 신속하게 변화하는 코드 라이브러리에서 일한 후에 배운 지식을 공유하고 결과에 매우 만족한다!
만약 당신이 웹 개발자라면, 일주일마다 새로운 프레임워크, 라이브러리, 기술을 내놓는 것에 익숙해졌을 것이다.

We are on a never-ending quest to find better tools and patterns, but does that mean our code is doomed to become old and wrinkly?

당신은 어떻게 당신의 프로젝트를 고정시켜 조류의 바람을 막습니까?여기에 다섯 가지 건의가 있는데 우리에게 효과가 매우 좋다.

1. 기술 개념이 아닌 영역 개념에 따라 코드 분리

새로운 프로젝트를 시작할 때 가장 먼저 물어야 할 문제 중 하나는 그것을 어떻게 조직해야 하는가이다.여기에는 두 가지 유행하는 사상 유파가 있다. 우리가 기술 개념에 따라 서류를 분할하든지, 분야 개념에 따라 서류를 분할하든지.

    # Split by tech concepts        # Split by domain concepts

    |- src                          |- auth
    |  |- controllers               |  |- controllers
    |  |  |- auth                   |  |- models
    |  |  |- profile                |  |- views
    |  |  |- article                |  |- tests
    |  |- models                    |- profile
    |  |- views                     |- article
    |- test                         (...)
    |  |- controllers
    |  |  |- auth
    (...)

만약 네가 제목을 읽었다면, 너는 우리가 무엇을 추천할지 알 수 있지만, 우리는 약간의 생각으로 그것을 지지할 것이다.
특정한 목표 (버그 찾기, 특성 추가, 삭제 등) 를 가지고 프로젝트의 루트에 도달한다고 가정해 보세요.적당한 코드를 찾고 관련 파일을 훑어보고 테스트를 보며, 자신이 충분할 때 코드 라이브러리를 변경해야 합니다.
개발자로서 이 과정은 우리의 생계이기 때문에 우리는 그것을 더욱 효율적으로 하는 것이 가장 좋다.

What is easier to maintain, a codebase with 10 files or one with 100 files?

도메인 개념에 따라 코드를 나누면 코드 라이브러리의 일부분에 집중할 수 있고, 기술 개념에 따라 코드를 나누면 점프할 수 있습니다.

2. 모든 분야 개념에 대한 공공 계약(API) 제공

프로젝트에 payments 디렉터리가 있다고 가정하면 모든 것을 저장합니다💰-관련 코드.우리는 일련의 구성 요소가 지불을 데이터베이스에 저장하거나 제3자 서비스, 예를 들어 Stripe에 연결한다.
이 모든 구성 요소는 계약을 이행하기 위한 것이다. 즉, payments 응당한 방식으로 행동하도록 확보하는 것이다.
명확한 것은 모바일 응용 프로그램이 호출할 HTTP API를 사용자에게 요금을 부과하는 것에 대해 논의하는 것이 아니라는 것이다.우리는 당신의 지불 디렉터리를 자신의 마이크로서비스로 바꾸는 내부 API를 논의합니다. (무료로 이 용어를 사용합니다.)
왜, 물어봐?
명시적 API가 제공되므로

예상 행위에 대한 명확한 묘사.

모든 사람이 동의하고 약속할 수 있는 최저 테스트 범위.

모든 내용을 변경할 수 있는 자유를 밑바닥에서 실현한다.

또한 이 API는 사용자, 권한 또는 환경과 같은 외부 개념을 최대한 적게 이해해야 합니다.도메인의 일부가 아닙니다.이것은 우리가 통신층 문제 (공공 HTTP 노드 자체가 안전하지 않음) 를 해결하거나 작업 흐름을 개발하는 방식이다.
예:

대중을 대상으로 하는 API로 일부 지역 행위를 공개하고 신분 검증과 권한을 제어한다.

개인 관리 API+ 패널로 간단한 고객 지원을 제공하고 데이터베이스나 컨트롤러에 접촉하지 않고 오류를 찾을 수 있습니다.

기기, 예시, 이동을 작성하는 매우 간단한 방법.

3. 작은 인터페이스에 의존

이것은 매우 환영을 받는다.개발자로서 우리는 구체적인 실현이 아니라 추상에 의존해야 한다는 것을 자주 일깨워 준다. segregate our interfaces과invert our dependencies.
너는 이 이론을 포괄하는 대량의 자료를 쉽게 찾을 수 있기 때문에 우리는 몇 가지 실례를 주목하자.우리의 Payments 응용 프로그램은 이러한 인터페이스와 대화해야 할 수 있습니다.

이벤트 발표자

이벤트 구독자

신용카드 충전기

이메일 보낸 사람

이 모든 인터페이스에는 작고 명확한 역할이 있다.잠시 후, 우리는 특정한 실현을 주입할 것이다.

production = Payments.new(
  event_publisher: rabbitmq,
  event_subscriber: rabbitmq_replicas,
  credit_card_charger: stripe,
  email_sender: mailgun,
)

development = Payments.new(
  event_publisher: in_memory_bus,
  event_subscriber: in_memory_bus,
  credit_card_charger: stripe_test_mode,
  email_sender: muted_mailer,
)

보시다시피 작은 인터페이스는 우리가 정의된 좋은 테스트를 만들고 환경에 따라 모든 조작에 대해 최선의 정책을 선택할 수 있도록 합니다.다른 한편, 우리는 모든 지식과 보조 기능을 집중하기 위해 특정 기술을 바탕으로 작성한다.

4. 데이터와 저장 정책을 분리

우리가 그것을 분명히 하자. 우리는 ORM이 틀렸다고 생각한다. (또는 사람들이 잘못했을 수도 있다.)Ruby on Rails 코드:

class Article < ActiveRecord::Base
  belongs_to :user
  has_many :comments, dependent: :destroy

  scope :authored_by, ->(username) { where(user: User.where(username: username)) }

  validates :title, presence: true, allow_blank: false
  validates :body, presence: true, allow_blank: false

  before_validation do
    self.slug ||= “#{title.to_s.parameterize}-#{rand(36**6).to_s(36)}”
  end
end

여기 열 게 많아요.
우선, 우리는 이 대상이 관계, 등급 삭제, 빈 속성을 묘사하고 있음을 알아차렸다.이것이 바로 대상 관계 맵에 대한 기대입니다.상당히 투명하다!
다음은 우리 한번 생각해 봅시다.한 편의 문장을 대표할 때, 무엇이 우리에게 중요합니까

우리는 우리가 사용하고 있는 언어의 힘을 충분히 이용할 수 있어야 한다.우리가 Java를 사용할 때, 우리는 OO 모드와 계승을 자유롭게 사용할 수 있기를 바란다.우리가 Haskell을 사용할 때, 우리는 연합 형식과 기록을 사용하기를 희망한다.

우리는 서로 다른 형식과 데이터베이스로 데이터를 저장할 수 있어야 한다.이로써 우리는 ElasticSearch를 사용하여 성능 검색을 할 수 있고, PostgreSQL을 사용하여 일치 상태 검색을 할 수 있으며, Redis를 사용하여 우리의 autosave 기능을 충분히 빨리 유지할 수 있다.

ORM 모델은 SQL 데이터베이스와 인터페이스하는 방식일 뿐이기 때문에 둘 다 제공되지 않습니다.우리는 여전히 다른 곳에서 우리의 데이터를 표시하고 조작해야 한다.문제는 이 주장을 받아들이면 ORM을 사용하는 것이 서투르거나 지나치다는 것이다.이것이 바로 우리의 뜻이다.

# Let's say we have a series of entities in our domain that we use to represent an article.
class Article; end # The big picture
class Tag; end
class RichText; end # Headings, bold, cross-references, …


# Now we need an interface to store the article's content in our SQL database.
class ArticleStore
  def store(title:, body:, tags:, author:)
    # Ruby doesn't have explicit interfaces, but you get the point
    raise NotImplementedError
  end
end


# Using an ORM creates an additional level of indirection that looks pointless
class ArticleORMStore < ArticleStore
  def store(title:, body:, tags:, author:)
    ArticleModel.create(title: title, body: body, tags: tags, author: UserModel.get(author.id))
  end
end


# A low-level SQL library feels simpler in comparison.
class ArticleSimpleStore < ArticleStore
  def store(title:, body:, tags:, author:)
    article_table.insert(title: title, body: body, tags: tags, author: author.id)
  end
end

여기의 밑줄은 ORMs를 사용할 수 있지만 데이터를 표시하고 조작하는 유일한 방법으로 삼지 마십시오.그것은 결코 그들의 목적이 아니다.

5. 이벤트를 사용하여 응용 프로그램 연결과 코드 결합을 유지합니다

만약 응용 프로그램의 두 부분이 연결되어 있다면, 코드는 반드시 어떤 방식으로 연결되어야 한다. 그렇지?
Event-driven 프로그래밍은 응용 프로그램의 상호 연결을 유지하는 데 매우 잘하지만, 당신의 코드는 작성하고 유지하기 쉽다.사실상 잘 되고 있다. 비슷한 생각은 이동과 전단 개발에서 Reactive Programming 라는 이름으로 보급되고, 운영 분야에서 cloud providers and companies betting hard on it 라는 이름으로 보급된다.
기본 사상은 역의 모든 변경이 원자 사건으로 표시되는 것이다.

    article_published(…) 1 minute ago
    article_draft_created(…) 5 minutes ago
    user_signed_in(…) 25 minutes ago

모든 이벤트는 특정한 이벤트 라인을 통해 발표되며, 랜덤 관찰자는 관심 있는 이벤트를 구독하고 응답할 수 있으며, 다른 구성 요소를 지나치게 방해하지 않는다.
우선 이벤트 라인에 기반을 다지고 모든 이벤트의 속성과 원자성을 고려해야 하기 때문에 추가적인 노력이 필요합니다. 그러나 장기적으로 보면 이것은 절대적으로 가치가 있습니다.
다음은 몇 가지 기능 예시입니다. 이러한 기능은 이벤트 구동 구조로 실현하기 쉽고 다른 방식으로 사고하고 유지하기 어렵습니다.

글의 평론을 듣고 계수기를 늘린다.

새 사용자에게 시작 메시지를 보냅니다.

글쓴이에게 새로운 평론이 있음을 통지한다.

수동적인 방식이 아니라 명령적인 방식으로 이 임무를 어떻게 완수할지 상상해 보세요.

Event-driven programming avoids long functions with many different side effects, and makes your tests nicer and more isolated.

다음 글에서, 우리는 어떻게 이 모든 부분을 한데 모아 자신의 구조를 만드는지 설명할 것이다.
우리는 평론 부분에서 당신의 이러한 생각에 대한 견해를 보게 되어 매우 기쁩니다.