TheCodestReview #5 - 격주 소프트웨어 엔지니어링 주스

지난 에피소드에서 직장 내 유머의 중요성에 대해 다룬 기사에 댓글을 달겠다고 장난을 쳤지만, 그 사이 훨씬 더 많은 공로를 인정받을 가치가 있다고 생각해서 조만간 전체 블로그 포스팅을 작성할 예정입니다.    

지난 몇 주 동안 저를 바쁘게 했던 일들: 

a) 크리스마스 전에 저는 첫 번째 에피소드로 "방탄 CTO" 웨비나 시리즈 (2월의 두 번째 에피소드에서 SaaS를 소개할 예정이니 기대해주세요. CTOs자세한 내용은 곧 제 LinkedIn에서 확인할 수 있습니다).

b) Ruby 및 JS 핵심 비즈니스를 넘어 Magento 및 제품 디자인 역량 사내.

자기 홍보는 그만하고, # 더코데스트 리뷰 시리즈의 5번째 에피소드로 여러분을 초대합니다. 

내 주제 팀 이 시간을 위해 준비했습니다: 

1. 확장 가능하고 유지 관리 가능한 프런트엔드 아키텍처.
2. 기존 커밋.
3. Ruby 3.0.0 릴리스 업데이트.

프론트엔드 애플리케이션 및 기존 커밋에 대한 의견은 이번 주에 React 엔지니어가, Ruby 3.0.0은 Ruby 드림팀이 전달합니다.

오늘날 많은 개발자가 시간 절약을 위해 이미 만들어진 UI 라이브러리와 재사용 가능한 컴포넌트를 사용하고 있습니다. 이는 좋은 방법이고 많은 시간을 절약하는 데 도움이 되지만, 우리의 프로젝트 로는 처리하기에 충분하지 않다는 것을 이해하게 될 것입니다. 코드.

백엔드 개발에는 도메인 중심 개발(DDD)과 관심사 분리(SoC)라는 두 가지 좋은 패턴이 있습니다. 프론트엔드 아키텍처에서도 사용할 수 있습니다.

DDD에서는 유사한 기능을 그룹화하여 다른 그룹(모듈)과 최대한 분리하려고 합니다.

예를 들어, SoC에서는 로직, 뷰, 데이터 모델을 분리합니다(예: MVC 또는 MVVM 디자인 패턴 사용).

사용할 수 있는 좋은 사례와 패턴이 많이 있지만 저는 이 방법을 선호합니다.

이 패턴을 사용하면 다음과 같은 그림을 얻을 수 있습니다:

처음에 사용자는 앱 라우팅을 통해 올바른 모듈로 리디렉션됩니다. 모든 모듈은 완전히 포함되어 있습니다. 그러나 사용자가 여러 개의 작은 애플리케이션이 아닌 하나의 애플리케이션을 사용하기를 기대하기 때문에 일부 결합이 존재하게 됩니다. 이러한 결합은 특정 기능이나 비즈니스 로직에 존재합니다.

그리고 우리는 이런 구조를 가지고 있습니다:

앱 폴더 - 애플리케이션 계층

자산 - 사진, 글꼴, 아이콘 등을 위한 폴더입니다.

컴포넌트 - 여기에는 복잡한 로직이 없는 재사용용 컴포넌트가 있어야 합니다.

구성 - 여기에는 전역 상태를 저장합니다.

lib - 복잡한 함수 및 논리 계산을 위한 폴더

모듈 - 여기 모듈이 있습니다.

pubsub - 데이터 구조를 설명하기 위한 스키마를 저장하는 장소입니다.

스타일 - CSS/SCS 코드의 경우

이 구조는 증가하는 애플리케이션을 처리하고 버그를 줄이는 데 도움이 될 것입니다. 또한 별도의 모듈로 작업하는 부분을 더 편하게 만들고, 테스트하고, 리팩터링과 디버깅을 더 쉽게(별도의 모듈로 인해) 하는 데 도움이 될 것입니다.

모듈 아키텍처와 API와의 연결에 대해 더 자세히 살펴보면 이와 같은 결과를 얻을 수 있습니다:

'app' 폴더에 API 호출을 위한 코드와 'config/store'에 저장할 데이터가 있는 또 다른 폴더 'api'를 생성합니다. 여기에는 전체 애플리케이션에서 사용하는 정적이고 불변의 데이터를 보관합니다.

또한 'pubsub/schema' 폴더에는 다음과 같은 특정 데이터 유형에 대해 설명합니다. JavaScript 객체입니다.

모든 모듈에는 우리가 사용해야 하는 데이터(사용자, 경로, 테이블, 작업 등)가 들어 있습니다. 모든 모듈은 애플리케이션 계층과 연결되며 필요한 모든 데이터를 가져옵니다.

프론트엔드는 사용자가 가장 먼저 접하는 곳입니다. 프론트엔드 프로젝트의 기능이 늘어남에 따라 버그도 늘어날 것입니다. 하지만 사용자들은 버그가 없고 새로운 기능이 빠르게 제공되기를 기대합니다. 이는 불가능합니다. 하지만 좋은 아키텍처를 사용함으로써 가능한 한 이를 달성할 수 있습니다.

기존 커밋 by DZone의 사티야보드 무드홀

더 나은 방식으로 작업을 커밋해야 하는 이유

이제 막 입사한 회사에서 일을 시작했다고 상상해 보세요. 모든 사람들이 친절하게 대해주고, JavaScript가 언어가 되기 전의 코드베이스를 소개받고 넷스케이프가 시대에 뒤떨어진 페이지를 로딩하는 시점까지는 모든 것이 괜찮아 보였습니다.

코드 상속은 프로젝트에 새로운 개발자를 투입할 때 큰 문제가 되는 것 같습니다. 코드를 읽는 것과 애플리케이션이 어떻게 개발되었는지 이해하는 것은 완전히 다른 문제입니다. 커밋은 종종 유용하게 사용되며, 왜 이 console.log가 린터에 걸리지 않았는지 또는 왜 처음 주석을 만든 개발자의 자식에게 저 지저분한 // TODO가 존재하는지에 대한 컨텍스트를 제공합니다.

표준화되지 않은 커밋 규칙보다 기존 커밋이 더 나은 이유부터 시작하겠습니다.

대부분의 커밋이 '작동해야 한다' 또는 '최대한 빨리 바닥글을 수정해야 한다'는 메시지로 구성된 프로젝트에 새로운 개발자를 고용한다면 어떤 생각이 떠오르시나요?

적신호가 켜졌다고 말씀드리고 싶습니다:

• 정확히 어떤 것이 효과가 있는지 모르겠습니다.
• 졸음이 쏟아지고 실수할 가능성이 있는 상태에서 무언가를 밀어붙인 이유는 무엇인가요?
• ASAP 주석을 볼 수 있다면 수정이 급하게 이루어졌나요?

팀에서 변경 사항을 커밋할 때 사용자 지정 규칙을 적용할 수 있으므로 커밋이 견고해야 오류가 발생할 여지가 줄어듭니다. 서명은 더 이상 단순한 체크 아웃 방법이 아닙니다. 다른 사람들에게 커밋의 내용을 알고 있다는 것을 알리는 서명입니다. 서명을 제대로 하지 않으면 오류가 발생하고 다음과 같은 메시지가 표시될 가능성이 높다는 것은 말할 필요도 없습니다.

팀에서 특정 키워드를 허용하지 않는 규칙을 설정하여 최대한 빨리 욕설이나 욕설을 블랙리스트에 추가하고 싶을 수 있습니다.

툴링

프로젝트를 시작할 때 정말 도움이 되는 것은 모든 사람에게 어떻게 개발팀 새로운 개발자가 변경 사항을 커밋하기를 원합니다. 그런 다음 개발자들이 모두가 합의한 내용을 따라갈 수 있도록 도와주는 도구를 설정하세요.

제가 사용해 본 도구 중 하나는 다음과 같습니다. 커밋린트 덕분에 규칙이 없는 새로운 프로젝트를 진행할 때 기존 커밋을 관행으로 삼게 되었고, 팀도 이를 도입하는 것에 대해 열린 자세를 갖게 되었습니다.

설정을 다루고 팀 전체에 배포할 때는 npm 패키지를 만들고 각 프로젝트에 mpn i -D하기만 하면 됩니다. 이렇게 하면 프로젝트의 모든 사람이 항상 같은 정보를 공유할 수 있고, 필요한 경우 프로젝트 간에 마지막 변경 사항(및 변경 이유)을 이해하는 데 도움이 됩니다.

여러 혜택이 있는 친구

이제 모든 것을 설정하고 CC를 사용하는 것이 왜 좋은지 이해했다면 이제 가장 좋은 부분은 방금 적용한 규칙을 중심으로 프로그래밍하는 것입니다! 우리는 표준화된 커밋 방식을 사용하고 있으며, 커밋의 실제 내용에 더 많은 주의를 기울이고 있으므로 플래그가 있을 때 스테이징에서 빠르게 테스트할 수 있는 후크를 설정하는 것은 어떨까요? 서비스 과부하를 막고 필요할 때 비용을 절감하고 싶지 않으며 로컬 호스트 대신 프로덕션과 같은 서버에서 테스트해야 하는 몇 가지 이유가 있습니다.

PWA로 작업 중이고 모든 잠재력을 테스트하기 위해 SSL이 필요하며 테스트 플랫폼에 SSL이 있다고 가정해 보겠습니다. 이제 좋은 커밋만 있으면 됩니다. 매니페스트 아이콘 워크박스 설정 업로드를 통해 테스트하고 톱니바퀴를 돌리는 전체 기계가 작동할 것입니다. manifest.json과 같은 정적 데이터만 업로드할 때는 그럴 필요가 없으므로 커밋에 플래그 [TEST_SKIP]를 포스트픽스로 추가합니다. 이렇게 하면 CI가 테스트 환경에 새 에셋만 업로드하고 테스트를 건너뛸 수 있습니다. 이에 대한 자세한 내용은 여기

잠시 후 변경 로그 생성의 용이성, 더 나은 버전 관리와 같은 다른 이점을 확인할 수 있습니다. 시맨틱 버전 관리. 커밋 메시지를 작성하는 방식을 바꾸도록 설득하기에 충분하지 않다면 찬물에 발가락을 담그고 잠시 동안 개인 저장소에서 사용해보면 마음이 바뀔 수도 있습니다.

기존 커밋에 만족하세요!

루비 3.0.0 릴리스 업데이트 by 루비 커뮤니티

커뮤니티에서 오랫동안 기다려온 루비 3.0.0 릴리스가 크리스마스에 빛을 보게 되어 모든 루비 개발자들이 아침에 일어나자마자 크리스마스 트리 아래에서 찾을 수 있게 되었습니다. The Codest에서는 엔지니어들이 주목할 만한 기술 동향과 새로운 발견에 대해 논의하는 개발자 회의를 매주 개최하여 지식 공유 문화를 조성하고 있습니다. 아래에서 루비 수석 엔지니어가 주관적인 관점에서 루비 3.0.0의 몇 가지 중요한 변경 사항에 대해 논의한 데모 데이의 슬라이드 링크를 확인할 수 있습니다:

https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing

또한, 루비 멘토가 성공적으로 병합된 풀 리퀘스트를 통해 새 버전에 기여했습니다. 개인정보 제어 방법에 대한 자세한 내용은 아래 개발 책임자의 짧은 글에서 확인할 수 있습니다.

https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods

읽어주셔서 감사드리며, 여기까지 읽어주신 분들께는 링크드인이나 제 이메일을 통해 모든 피드백을 환영합니다.

2월 말 다음 에피소드에서는 멋진 루비 모놀리스 앱을 개발한 엔지니어링 팀인 Shopify의 CTO를 인터뷰한 팟캐스트 리뷰로 여러분을 다시 찾아뵙겠습니다!

또 뵙겠습니다.

자세히 읽어보세요:

TheCodestReview #4 - 주간 소프트웨어 엔지니어링 주스

TheCodestReview #3 - 주간 소프트웨어 엔지니어링 주스

TheCodestReview #2 - 주간 소프트웨어 엔지니어링 주스