Javascript Colocation (번역글) 🤔

이 포스트는 아래 출처의 글을 번역한 글입니다. 의역과 오역을 자주 사용합니다.

 

 

우리 모두는 유지보수가 쉬운 코드를 원합니다. 그래서 우리는 코드를 유지보수가 쉽고 이해하기 쉽게 만들기 위한 최선의 의도와 함께 시작을 합니다. 시간이 지나고 코드가 커질수록 의존성을 관리하기는 어려워 집니다. 프로젝트가 커질 수록 코드가 '사소한 지식'이 되고 '기술 부채'에 기여하는 코드의 양은 증가해져 갑니다.

 

저는 제 코드를 저 뿐만 아니라 동류, 미래의 코드 관리자, 6개월 뒤에 저를 위해 관리가 수월하게 하고 싶었습니다. 모두가 동의할 수 있다고 생각합니다. 이것은 좋은 생각이고 우리가 우리의 코드에서 갈구해야 하는 것이라는 것을. 이것을 성취하기 위한 기술과 다양한 도구 들이 많이 존재합니다.

 

Let's talk about Code Comments

 

당신의 코드에 주석을 달아야 하는지 아닌지 당신의 주석이 무엇이어야 하는지에 대해서 논의하고 싶지 않습니다. 대신에 이러한 주석이 어느 위치에 존재해야 하는지에 관점을 두고 싶습니다. 우린 일반적으로 이러한 주석을 관련 코드에 가능한 가깝게 위치시켜 설명하는 코드와 동일한 장소에 배치합니다.

 

만약 우리가 이걸 다르게 한다면 어떨지 잠깐만 생각해보세요. 이러한 주석들은 완전히 분리된 파일에서 어느곳에 위치시켜야 할까요? 거대한 `DOCUMENTATION.md` 파일 혹은 아마도 `src/`디렉터리로 다시 매핑되는  `docs/` 디렉토리일 수도 있습니다. 흥미롭게 들리나요? 저는 아닙니다. 코드가 표현되는 곳과 다른곳에 우리의 주석을 위치시킨다면 심각한 문제에 직면할 수 있습니다.

 

• 유지보수성 : 싱크가 어긋나거나 이미 빠르게 지난 날짜 일겁니다. `docs/`파일의 해당하는 내용의 업데이트 없이 'src/' file을 지우거나 이동시킬 겁니다
• 적용성 : 사람들은 `src/`의 코드를 살펴보고 `docs/`의 중요한 주석을 놓치거나 그들의 코드에 대한 주석을 달지 않을 겁니다. 왜냐하면 `src/` 파일을 위한 `docs/` 파일이 존재하는지를 인식하지 못하기 때문입니다
•  쉬운 사용성 : 한 장소로부터 다음 으로의 컨텍스트 스위칭은 장애물이 됩니다. 파일을 위해 여러곳에서 다루는 것은 컴포넌트를 유지하기 위해 필요한 모든것을 확실히 하기에 어렵게 합니다

 

코드 주석 스타일과 같은 종류를 위해 컨벤션을 이전에 명시해 놓을수도 있습니다. 하지만 왜 그래야 할까요? 우리가 표현하는 코드와 주석을 동일한 위치에 두는 것이 간편하지 않을까요??

So what?

이제 당신은 아마 스스로 이렇게 생각할 겁니다. "좋아, 음, 이것이 `docs/`와 같은 것들을 이용하지 않는 이유고 모든 이들은 단지 그들의 코드와 주석을 동일한 위치에 위치켜. 그것은 명백해. 무엇이 관점이지?"  제 관점은 동일한 위치에 두는 이점은 모든 곳에 있다는 것입니다.

 

HTML/View

HTML을 예를 들어볼게요. 주석을 동일위치에 위치시키는 이점은 템플릿 간에도 전달이 됩니다. React와 같은 현대의 프레임워크 이전에 는 view 로직과 완전히 별도의 디렉터리 들에 위치한 view 템플릿들을 이용하였었습니다. 이것은 위에서 언급한 것과 같은 문제가 발생됩니다. 오늘날 React와 Vue의 예시 같이 이러한 것들은 같은 파일에 위치시키는 것은 흔합니다. Angular에서 만약 같은 파일이 아니었다면 템플릿 파일은 적어도 사용되는 js 파일 바로 옆에 있었습니다.

CSS

CSS는 다른 개념이 잘 적용되어있습니다. CSS-in-JS의 이점에 관하여 논하지는 않겠지만 이점은 이미 유명합니다. Learn more here

 

 

Tests

이러한 파일의 동일위치에 위치시키는 개념은 unit test들에 잘 적용됩니다. `src/` 디렉터리에서 프로젝트를 찾고 `test/` 디렉터리는 `src/` 디렉터리를 반영하기 위한 unit test로 가득찬 것은 흔한 경우입니다. 위에서 설명한 모든 함정은 여기에도 적용됩니다. 유닛 테스트를 완전히 동일한 파일에 넣는 것까지는 하지 않겠지만, 그것도 완전히 흥미로운 아이디어로 배제하지는 않겠습니다.

 

좀 더 유지가능한 코드가 가능하도록 돕기 위해 그들이 테스트 하는 파일들의 그룹 혹은 test file을 동일한 위치에 위치시켜야 합니다. 새로운 이가 코드에 접근할 때 어떠한 모듈이 테스트 되어지고 모듈을 학습하기 위해 이러한 테스트를 사용하는 것을 확실히 할 수 있습니다. 그들이 코드에 변화를 주려면 그들의 변화에 해당하는 테스트를 업데이트 해야하는 것을 상기시킵니다.

 

State

어플리케이션/컴포넌트 상태는 같은 이점을 경험할 수 있습니다. 상태가 사용되어 지는 UI로부터 상태가 끊어지거나 직접적이지 않을 수록 유지보수 하기는 힘들어 집니다. 상태를 적절히 위치시키는 것은 유지보수 보다 큰 이점을 가지고 있습니다. 어플리케이션의 성능 또한 증가시킵니다. 컴포넌트 트리의 한쪽에서 상태의 변화는 트리의 꼭대기에 상태가 변하는 것보다 적은 컴포넌트 들을 리렌더 합니다. 상태를 지역화 하세요

 

 

"Reusable" utility files

"utility" 파일들과 함수에 잘 적용됩니다. 컴포넌트를 작성하고 함수들이 잘 추출되어 질 수 있는 깔끔한 코드들을 볼 수 있다고 상상해 보세요. 여러분은 이것을 추출하고 생각합니다. "음...더 많은 사람들이 사용할 수 있게 투자해야겠어". 그래서 여러분은 앱의 `utils/` 디렉터리에 이 파일을 이동시킵니다.

 

후에, 당신의 컴포넌트가 삭제되어지고 당신이 작성한 유틸리티는 안중에 없어집니다. 관심은 없어지고 이것은 남아있습니다. 왜냐하면 이걸 지우는 사람은 이것이 좀 더 널리 쓰일걸로 가정하기 때문입니다. 몇년 동안 작업자들은 더이상 필요하지 않다는 것조차 깨닫지 못한 채 기능과 테스트들이 계속해서 제대로 작동하고 작동하는지 확인하기 위해 열심히 일합니다. 헛된 노력과 cognitive load

 

만약 대신에 그 함수들을 사용되어지는 파일 내부에 그대로 두었다면 이야기는 완전히 달랐을 겁니다. 복잡한 유틸리티 함수의 유닛테스트를 귀찮게 하지 말라는 것이 아니라 그들이 필요로 한 곳에 가깝게 위치시키면 여러분이 문제를 피할 수 있게 도와줍니다.

 

The principle

 

동일한 위치에 위치시키는 개념은 근본적인 원칙으로 간소화 될 수 있습니다.

코드를 사용 가능성이 있는 곳에 가깝게 위치시키세요

 

당신은 말할겁니다. 함께 변하는 것은 타당히 가깝게 위치 되어야 한다.

 

Open Source made easy(-er)

 

이전에 언급된 문제들을 피하는 측면에서 이러한 방식으로 프로젝트를 구성하는 다른 이점이 있습니다. 컴포넌트를 작성하고 오픈 소스 프로젝트로 바꾸는 것은 폴터를 다른 폴더에 복사/붙여넣기 하고 npm으로 출시하는 것만큼 간편합니다. 그리고 이 프로젝트를 설치하고 `require`/`import` 문을 업데이트 하면 사용할 준비가 끝났습니다.

 

Exceptions

물론 시스템의 전체 혹은 일부를 문서로 통합하고 어떻게 통합할지에 대한 좋은 논쟁이 있습니다. 그리고 여러 구성요소들에 걸쳐 통합 혹은 end-to-end 테스트들을 위치시킬 건가요? 이러한 것들이 예외라고 생각할 겁니다. 그러나 그들은 위에서 언급한 원칙들에 따를 수 있습니다.

 

만약 제 앱에 유저 인증 관련된 부분이 있고 그 흐름을 문서화 하길 원한다면 유저 인증에 관련된 모든 모듈들을 README.md 파일에 위치시킬 수 있습니다. 그 흐름에 통합 테스트가 필요하다면 같은 폴더에 이러한 테스트 파일들을 위치 시킬 수 있습니다.

 

end-to-end 테스트의 경우 일반적으로 프로젝트의 root에 위치시키는 것이 더 이해하기 쉽습니다. 그것들은 프로젝트를 넘어 시스템의 다른 부분에도 존재하므로 분리된 디렉터리에 위치 하는 것이 좋다고 생각합니다. 그들은 `src/` 파일들에 매핑되지 않습니다. 사실 E2E 테스트는 `src/`가 어떻게 구조화 되어있는지 신경쓰지 않습니다. 리팩터링과 `src/` 디렉터리의 파일들을 이동은 E2E 테스트들의 변화가 필요하게는 하지 않습니다.

 

Conclusion

 

우리의 목표는 소프트웨어를 가능한 유지보수가 간단하게 만드는 것입니다. 우리의 주석을 동일 위치에 위치시킴으써 얻을 수 있는 유지보수성, 적용성, 쉬운 사용성의 같은 이점들은 서로 다른 것들을 동일 위치에 위치시킴으로써 얻을 수 있습니다. 만약에 시도해 보지 않았다면 시도해 보길 추천합니다.

 

"관심사의 분리"를 위반하는 것이 걱정된다면 Pete Hunt의 이야기를 체크해보길 추천하고 이것의 의미를 다시 생각해보길 추천합니다.😀.

 

또한 이것은 이미지 들이나 다른 리소스에도 잘 들어맞습니다. webpack과 같은 도구를 사용할 때 co-locating은 미친듯이 쉽습니다. 정직하게 이것은 웹팩 IMO의 핵심 가치중 하나입니다.

 

---

 

출처 : https://kentcdodds.com/blog/colocation

Colocation