기술 부채와 모놀리스 신화

왜 자신에게 물어보고 있습니까?

Unsplash에 Zoltan Tasi의 사진

이것은 초기 단계의 Tech Startups에서 가장 반복되는 시나리오 일 수 있습니다. 창립 팀은 원래 아이디어가 작동하는지 증명하기 위해 MVP 를 구축 합니다. 가능한 한 빨리 제품 시장 적합성 을 찾는 것이 가장 중요합니다.

스타트 업은 그렇지 않으면 살아남지 못할 것입니다!

결과적으로 팀은 기술 선택, 소프트웨어 아키텍처 및 모범 사례에 제한적인주의를 기울입니다.

반대로 기술 솔루션의 "아름다움"에 너무 많이 그리고 너무 빨리 집중하는 것은 치명적인 실수가 될 수 있습니다. 사용자가없는 훌륭한 기술을 갖는 이유는 무엇입니까?

문제는 제품 시장이 생기면 일반적으로 시리즈 A 자금 조달 단계에서 시작됩니다. 사용자 기반은 새로운 기능 및 높은 안정성에 대한 요구와 함께 증가합니다. 갑자기 첫 번째 단계를 잘 수행 한 동일한 애플리케이션이 부담이되었습니다.

엔지니어링 팀은 한마음으로 말합니다.

기술 부채가 너무 많습니다. 우리는 단일체를 깨야합니다!

이것이 최선의 전략인지 평가하기 위해 고려해야 할 많은 기술적 고려 사항이 있습니다. Sam Newman의 "Building Microservices""Monolith to Microservices" 는 주제에 대해 자세히 알아 보고자 하는 모든 사람에게 훌륭한 참고 자료입니다.

대신, 저는이 문제를 더 높은 관점에서 바라 보면서 기술이 무엇인지 , 즉 목적을위한 수단을 취하고 싶습니다 .

문제점

엔지니어가 기술 부채에 대해 제기하는 일반적인 불만 사항은 다음과 같습니다.

  • 백엔드는 확장되지 않으며 증가하는 사용자 기반을 지원할 수 없습니다.
  • 페이지로드 속도가 느리고 사용자 경험이 끔찍합니다.
  • 레거시 코드는 복잡하고 복잡하며 버그를 쉽게 수정할 수 없습니다.
  • 우리 코드의 비즈니스 및 프레젠테이션 로직은 밀접하게 결합되어 있으며 새 기능을 빠르고 안정적으로 구축 할 수 없습니다.
  1. 해결해야 할 가장 중요한 문제는 무엇입니까?
  2. 언제 해결되었다고 생각하십니까?

critical 이라는 단어의 압축을 풀지 않고는이 질문에 답할 수 없습니다 . 따라서 다른 질문에 답하여 문맥에 넣어 보겠습니다.

회사가 목표를 달성하기 위해 필요한 것은 무엇입니까?

예를 들어 목표가 짧은 시간에 사용자 기반을 크게 늘리는 것이라면 시스템이 효과적으로 확장 할 수있는 능력 이 중요합니다.

일단 비즈니스 우선 순위를 명확히하고 나면 갑자기 유지 보수 가능성과 깨끗한 아키텍처가 부차적 인 관심사가됩니다. 덜 중요한 것은 확장 가능한 플랫폼을 구축하려면 두 가지 문제를 모두 해결해야 할 가능성이 높습니다. 그러나 그것들이 당신의 주된 초점이되어서는 안됩니다.

차이는 미묘하지만 사고 방식의 변화는 특히 “중지”할 때를 아는 맥락에서 매우 중요 합니다.

기술 부채에 대한 작업은 결코 중단되지 않아야합니다. 솔루션의 저하를 방지하는 것이 나중에 수정하는 것보다 훨씬 효율적입니다. 그러나 우선 순위와 노력은 시간이 지남에 따라 균형을 이루어야합니다.

문제가 언제 해결되었다고 생각하십니까?

정확한 성공 척도 없이는 프로젝트를 정당화 할 수 없습니다 . 이전 게시물 에서 설명했듯이 팀이 수행하려는 작업과 관련된 측정 항목을 식별하고 공식화하는 것은 성공으로 이끄는 가장 중요한 일일 것입니다.

예를 들어, 좋은 비즈니스 모델에는 시간이 지남에 따라 예상 되는 사용자 기반 성장 이 포함되며 , 이는 중요한 API 엔드 포인트에 대한 예상 되는 초당 동시 요청 으로 비교적 쉽게 변환 될 수 있습니다 . 이것이 당신의 목표입니다.

목표에 도달하지 않으면 아키텍처 재 설계, 코드 리팩토링 또는 데이터 마이그레이션이 그만한 가치가 없습니다!

예외가 있습니까?

별로. 예를 들어 깨끗한 아키텍처에 대한 필요성 과 같이 표면적으로 측정하기 어려워 보이는 문제점에도 동일하게 적용됩니다 .

회사 목표로 돌아가서, 제품 로드맵에 과거보다 더 많은 기능이 포함되어 있다면 코드 아키텍처에 병목 현상이 발생할 수 있습니다.

Nicole Forsgren, Jez Humble 및 Gene Kim의 Accelerate 연구에서 자세히 설명 했듯이 리드 타임 및 배포 빈도와 같은 메트릭이 필요할 수 있습니다.

어떤 측정 항목을 선택하든 시각화하지 않는 한 그다지 유용하지 않을 것이며 팀은 매일 진행 상황을 확인하고 결정을 내리는 데 사용합니다. 작업이 시작되기 전에 대시 보드 가 있는지 확인하는 것이 팀 리더로서 할 수있는 두 번째로 중요한 일일 것입니다.

결론

요약하면, 기술 부채를 해결해야한다고 생각할 때마다 다음과 같이 자문 해보십시오.

  1. 회사의 주요 목표는 무엇입니까?
  2. 기술 부채의 어떤 요소가 직접 연결되어 있습니까?
  3. 개선되고 있는지 확인하기 위해 측정해야하는 비즈니스 및 기술 메트릭은 무엇입니까?
  4. 상황이 충분하다는 것을 알기 위해 달성해야하는 목표는 무엇이며 우선 순위를 검토 ​​할 때가 되었습니까?

Suggested posts

Express.js 시작하기

Express.js 시작하기

Express는 웹 및 모바일 앱을 만드는 경험을 즐겁게 만드는 기능 세트가 포함 된 Node.js 프레임 워크입니다.

Vue 3 및 JavaScript를 사용하여 JSON-CSV 변환기 만들기

Vue 3 및 JavaScript를 사용하여 JSON-CSV 변환기 만들기

Vue 3는 프런트 엔드 앱을 만들 수있는 사용하기 쉬운 Vue JavaScript 프레임 워크의 최신 버전입니다. 이 기사에서는 Vue 3 및 JavaScript와 함께 JSON을 CSV로 만드는 방법을 살펴 보겠습니다.

Related posts

백엔드 개발을 배우기위한 10 가지 최고의 튜토리얼

프로그래밍은 당신이 아는 것에 관한 것이 아닙니다. 그것은 당신이 알아낼 수있는 것에 관한 것입니다.

백엔드 개발을 배우기위한 10 가지 최고의 튜토리얼

"더 나은 오류 메시지를 작성하지 말고 필요하지 않은 코드를 작성하십시오." — Jason McDonald Backend Development — 대부분 웹, 소프트웨어 또는 앱에서 모든 것이 작동하는 방식에 관한 것입니다. 대부분은 애플리케이션 작동 방식의 중추입니다.

엔트리 레벨 소프트웨어 엔지니어로서 배운 5 가지

엔트리 레벨 소프트웨어 엔지니어로서 배운 5 가지

코딩과 기술력뿐만 아니라 3 년 전, 저는 사물이 어떻게 생겼을 지에 대한 수많은 가정과 기대를 가지고 기업 세계에 처음 발을 들여 놓았습니다. 내가 얼마나 잘못이 증명 될지 거의 알지 못했습니다.

소프트웨어 개발에서“단순한 것”이 빠르게 복잡 해지는 방법

소프트웨어 개발에서“단순한 것”이 빠르게 복잡 해지는 방법

"자동화되기를 바라는이 사소한 것이 있습니다."— 사소한 일이 아닐 것임을 알고 이것을 얼마나 자주 듣지 못했습니까? 아니면 당신이 더 잘 알면서도 직접 말 했나요? 왜 단순한 것들은 소프트웨어 개발에서 결코 단순하지 않고, 여기저기서 몇 가지 작은 것들이 빠진 것과 당신이 만들어야했던 몇 가지 지름길을 아는 것에 대한 좌절없이 우리가 기능을 "적절하게"구현하는 것을 방해하지 않는가? 프로젝트의 다음 기한을 잡을 수있을만큼 모든 것이 제대로 작동하도록하려면? Europe Elects의 다른 사람들과 함께 여러 유럽 국가의 여론 조사에서 주요 데이터를 수집하는 약간의 취미 프로젝트가 있습니다. 이 프로젝트에서는 모든 정보를 수집 할 수있는 인프라를 설정해야합니다.

해독 : 얻을 수없는 테스트 안정성 (아니면?)

해독 : 얻을 수없는 테스트 안정성 (아니면?)

Detox는 모바일 앱용 그레이 박스 테스트 솔루션으로, 테스트 코드와 앱 간의 동기화를 관리하므로 사용자가 수동으로 수행 할 필요가 없습니다. 사용자의 필요와 풍부한 문서 및 가이드가 없어도 개발자와 테스터는 여전히 사용 패턴, 잘못된 구성, 열악한 테스트 안정성으로 어려움을 겪을 수 있습니다.