남은 음식을 만들지 마라(DCL)

모든 사람이 앤디 헌트(Andy Hunt)와 데이브 토머스(Dave Thomas)가 제기한 DRY 소프트웨어 공학 원리를 잘 알고 있다.그것은 장기적으로 보면 코드에서 자신을 중복하지 말고 애매모호하지 않은 코드를 실현하고 쓸데없는 것과 많은 다른 장점을 피해야 한다고 지적했다.
이 글에서 나는 내가 각종 프로젝트에서 반복적으로 본 또 다른 모델이 소프트웨어 프로젝트의 유지보수성에 문제와 영향을 미칠 수 있다는 것을 설명하고 싶다.그것은 원본 코드 자체에 영향을 주지 않고, 그것을 구성하는 파일의 조직에 영향을 준다.

남은 음식은 무엇입니까?

소프트웨어 프로젝트의 생명 주기에 코드는 사용자의 기대를 충족시키기 위해 창설되고 소각될 것이다.이 기간 동안 더 이상 사용하지 않는 파일, 구성 요소 및 기타 유형의 내용을 쉽게 생성할 수 있습니다.이러한 인기 없는 소프트웨어 세션은 유지보수를 더욱 어렵게 하고 내부 지표에 영향을 주며 지속적인 통합 검사의 속도와 기타 각종 부작용을 낮출 수 있다.
과거에 남겨진 것들은 프로젝트에 아무런 가치도 가져다 주지 않고, 올바른 청소를 할 용기가 없어 건강한 코드 라이브러리를 가질 수 있는 지경까지 발전할 수 있다.이것은 바로 기술 채무통에 들어간다.
이 항목들은 마지막 인용이 사라질 때 삭제해야 하는데 개발자가 삭제하는 것을 잊어버렸다.이 나머지 내용은 사용하지 않은 이미지, 사용하지 않은 복사본, 테스트 세트에서 사용하지 않은 테스트 등등이다.
메모리 쓰레기 수집기의 직책은 비슷한 점과 비슷한 점이 많다는 것을 알 수 있다.이것은 위젯 간의 의존 관계를 추적하고 reference counting 명령을 사용하여 사용하지 않은 인용을 삭제합니다.문제는 코드 라이브러리의 의존항 사이에서 이런 정보를 추적할 수 없다는 것이다.

우리는 왜 남은 음식을 만들어야 합니까?

이런 엉망진창인 디자인 모델은 아마도 매우 많은 형상이 있을 것이다.이것은 남은 음식을 만들지 않고 현재의 많은 항목에 영향을 미치는 또 다른 예이다.당신들 중 몇 명이 번역 시스템을 가지고 있는데, 그 중에서 번역은 한 곳에 있고, 그것들을 사용하는 곳은 다른 곳에 있습니까?src/translations/en.json

{
  "hello_world": "Hello World!"
}

src/components/hello_world.jsx

export default function HelloWorld () {
  return (
    <div>{i18n.t('hello_world')}</div>
  )
}

이러한 번역 방법의 문제는 HelloWorld 구성 요소가 장래에 사라지면 en.json의 복사본은 개발자가 그것을 정리하는 것을 기억하지 않으면 잊혀진다는 것이다.미래의 어느 순간, 주 번역 파일에 수백 개의 사용되지 않은 키가 생기기 시작하면, 지원하고 싶은 모든 새로운 언어에 손해를 볼 수 있다.

일부 사람들translation systems은 이 점을 의식하고 더 좋은 방법을 취했다.그들은 추출한 것이 하나 있다
코드 라이브러리에서 모든 번역을 검색하는 절차입니다.따라서 이미 사용된 복사본 (의존항) 의 목록은 시종 최신이다.

기타 예

웹 플랫폼 강좌를 몇 번이나 보았는데, 그 중에서 assets 폴더와 그것들의 사용 위치가 매우 멀었습니까?
다음과 같은 간단한 파일 구조를 사용합니다.

/assets/images/
  - post1-cover.jpg
  - post1-thumbnail.jpg
/posts/post1/
  - helper.js
  - index.jsx
/specs/
  - helper.spec.js

이런 구조는 익숙하겠지만 DCL의 영향을 받는다.만약 어떤 이유로 post1가 더 이상 필요하지 않고 사라진다면 테스트에 실패한 후 helper.spec.js 파일은 삭제될 가능성이 높지만 assets와 관련된 post1 파일은 영원히 잊혀질 것이다.
다른 예를 확인합니다.

components/
  List/
    index.jsx (has a dependency with ListItem)
  ListItem/
    index.jsx
stories/
  List.story.jsx

이 파일 조직은 악의는 없는 것 같지만 DCL의 영향을 받는다.List 구성 요소가 사라지면 List.story.jsx 부작용으로 효력을 잃을 수 있지만 ListItem도 제거해야 한다고 알려주는 사람이 없습니다.

어떻게 검사합니까?

이 원칙은 부모 구성 요소나 외부 자원에 대한 인용으로 나타나지만, 때때로 그것을 검출하기가 더욱 어렵다.
어떤 상황에서도 엄지법은 자신의 질문에 대답한다.
만약 내가 나의 코드 라이브러리에서 이 구성 요소나 코드 세션을 삭제한다면, 나는 남은 것을 만들 수 있습니까?
이 질문이 있으면, 이 반짝이는 새 코드를 나중에 삭제하고, 원본 코드에 사용되지 않은 모든 부분을 볼 수 있다고 상상할 수 있습니다.이 점에서 이 질문에 대답하면 이 코드의 모든 의존 관계를 이해하는 데 도움을 줄 수 있습니다.

더 좋은 방법

이 조직 문제를 해결하려면 모든 의존항을 더 잘 봉인하는 것이 가장 좋은 방법이다.파일 구조의 경우 의존항이 한 번만 사용될 경우 부모 구성 요소에 의존항이 있는 것을 피하고 서브 구성 요소로 이동하십시오.모든 의존항은 상대 경로를 사용할 수 있습니다.
앞의 예에 따르면 이것은 더욱 좋은 조직이 될 것이다.

/components/
  List/
    ListItem/
      index.jsx
    index.jsx
    index.story.jsx

이런 새로운 방법은 더욱 좋은 포장성과 명확한 의존 관계를 가지고 있다.이렇게 하면 구성 요소를 파괴하지 않고 다른 구성 요소로 이동할 수 있다는 직접적인 장점이 있다.
어떤 경우, 번역 예시와 같이, 보기 의존 관계를 해결하기 위해 도구 체인에 추가 절차를 추가해야 합니다.assets one에 대해, 이 문제들을 해결하기 위해 구축기 (예: Webpack) 가 지원해야 합니다.

결론

우리는 방금 남은 음식을 만들지 않는다는 원칙의 몇 가지 예를 되돌아보았다.
서비스 가능성의 결과를 이해하면 더 좋은 방식으로 구성 요소를 만들고 조직할 수 있으며 장기적으로 더 건강한 방식으로 코드 라이브러리를 유지할 수 있습니다.
너는 이 원칙을 고정불변의 것으로 여길 필요가 없다.DRY 원칙에서처럼 샌디 메츠가 언급한 것처럼 잘못된 추상에 빠질 필요는 없다.너는 그것을 사용하고 보존해야 한다
구성 요소, 보기, 자산 구축 또는
니 프로젝트가 뭐든
나는 이 글이 네가 가능한 한 빨리 이런 모델을 발견하여 프로젝트의 유지보수성을 통제하는 데 도움을 줄 수 있기를 바란다.
해커!