웹 스타트 업에서 엔지니어가 기능의 프론트 엔드 및 백엔드를 작업하게하는 것이 더 일반적입니까 (기본적으로 전체 기능을 담당)? 아니면 엔지니어가 백엔드와 프론트 엔드를 분리 했습니까?
어떤 것이 더 유익하고 어떤 상황에 유리합니까?
전체 기능을 담당하는 엔지니어 한 명과 관련하여 단점은 사람이 프론트 엔드 또는 백엔드 개발에서 특히 강할 수 있지만 둘다는 아니기 때문에 속도와 품질이 저하 될 수 있다는 것입니다.
하나의 기능에 프론트 엔드 및 백엔드 개발자가 있으면 기능의 속도와 품질이 향상되고 협업이 촉진됩니다. 그러나 한 엔지니어가 다른 기능을 사용하여 작업 할 수 있기 때문에 두 명의 엔지니어가 한 기능에서 작업하여 자원을 제대로 사용하지 못할 수도 있습니다.
소규모 초기 단계에서 백엔드 / 프런트 엔드 엔지니어링 리소스를 할당하는 일반적인 / 모범 사례는 무엇입니까? 그리고 자라면서 어떻게 변할까요?
답변:
14 년의 경험에서 얻은 나의 지혜는 다음과 같습니다.
가장 좋은 대답은 @Shark에서 나온 것이지만 마지막 부분은 "의존합니다" 약 16 년 정도의 경험으로 두 가지 옵션이 다양한 구성으로 시도되는 것을 보았습니다. 풀 스택 개발자이기 때문에 여기에 내가 배우는 것이 있습니다.
* (BE = 백엔드, FE = 프런트 엔드)
민첩한 개발 관행 (요즘 일반적인 전략)은 기능 개발을 권장합니다. 여기서 기능은 고객 관점에서 유용한 단일 기능 척입니다. 이러한 관점에서 개발자는 두 가지를 모두 구현해야합니다.
서버 경계를 따라 스택을 분할하면 두 개발자간에 통합 지점이 생성됩니다. 그들이 효과적으로 의사 소통하고 잘 작동하지 않으면 두 기능이 결합 될 때 상당한 버그가 발생합니다.
Mythical Man-Month의 n (n-1) / 2 통신 규칙을 적용하면 두 사람간에 두 부분으로 기능을 분할하면 전체 작업량이 증가 함을 알 수 있습니다. 규칙은 기능에도 적용되지만 스택을 분할하면 통신량이 두 배가됩니다.
설계자는 BE 개발자가 매력적인 인터페이스를 처음부터 만들 수없는 문제를 해결합니다. 이것은 그들이 적어도 html & css를 알고 있다고 가정하고 디자이너가 만든 스크린 샷과 일치하는 인터페이스를 생성 할 수 있습니다.
기능은 일반적으로 다른 기능과 거의 상호 작용하지 않는 격리 된 구성 요소입니다. 항상 그런 것은 아니지만 일반적으로 상호 작용 지점은 데이터베이스 나 파일 시스템과 같은 수준이 낮습니다. 따라서 풀 스택 개발자가 기능을 구현하는 것을 막을 수는 없습니다. 그러나 FE 개발자가 BE 개발자가 작업을 완료 할 때까지 기다려야하는 경우 3 점의 생산성 손실 외에 더 많은 지연이 발생합니다.
Web2.0은 FE와 BE의 차이를 더욱 흐리게합니다. MVC 프레임 워크 및 전체 애플리케이션이 클라이언트 측에 구축되므로 안전하고 효율적인 FE 애플리케이션을 구현하려면 상당한 BE 지식이 필요합니다.
이 관행에 대한 나의 가장 큰 그립은 그것이 프로젝트에 관련된 모든 사람들의 능력을 제한한다는 것입니다. 이것이 2000 년대 초의 일반적인 관행 이었음에도 불구하고 두 가지를 모두 수행 할 수있는 개발자를 찾는 것이 매우 어려웠 기 때문에 (필수적으로 새로운 것이기 때문에 두 가지를 배우는 데 본질적인 어려움이 없었기 때문에) 필연적으로 수행되었습니다. 10 년 후에도 CSS를 모르는 "웹 개발자"가 있습니다.
두 번째로 큰 문제는 개발 팀을 쉽게 분류 할 수 있다는 것입니다. FE 개발자는 BE 코드를 수정 한 후 버그를 생성하고 팀은 스택 스택 개발 도매를 제한하기 위해 투표합니다. 코드 검토 및 교육으로 문제를 해결할 수 있지만 사람들은 대신 영토가됩니다.
RESTful API는 FE가 없으므로이 설명에 완벽합니다. 종종 회사는 먼저 RESTful API를 개발 한 다음 웹 애플리케이션을 개발합니다. 이 경우 BE 팀이 다음 주요 버전에 집중하는 동안 FE가 응용 프로그램을 마무리하는 강력한 사례가 있습니다. 그러나 FE 개발 단계에서 발견 된 새로운 정보가 BE API를 사소하게 수정해야하는 경우 이탈 위험이 여전히 존재합니다.
FE와 BE 간의 불균형 워크로드는 FE 전용 팀을 만드는 좋은 사례입니다. 다시 말하지만 이것은 아마도 주 개발이 데스크탑 애플리케이션을 통해 이루어지고 회사가 'lite'웹 인터페이스를 개발하려고 시도하는 상황입니다.
신규 / 주니어 개발자 교육 인턴 또는 주니어 개발자를 고용하고 있고이를 딥 엔드에 투입하는 데 관심이있는 경우 해당 통신 / 통합 비용 중 일부를 동료 개발 시스템에 투자하는 것이 좋습니다.
첫 번째 요점은 꽤 대담합니다. "좋은 자체 조직화 팀"이 없다면 빠르게 실패 할 것입니다. 당신이 그 팀을 가지고 있더라도, 그들의 경계를 넓히는 것은 당신과 그들의 이익에 달려 있습니다. 훌륭한 자체 조직 팀이 항상 그렇게 동기 부여되는 것은 아닙니다.
두 번째 요점이 잘못되었습니다. 최신 웹 개발에는 성능, 보안, 비동기식 안전, XSS 방지, 크로스 브라우저 및 신속하게 개발 된 FE 코드가 필요합니다. 목표는 단순히 그들이 동등하다는 BE와 경쟁하지 않습니다.
세 번째 요점은 또한 잘못된 가정입니다. FE 개발은 BE 기초 작업없이 순수한 html / css / js로 시작할 수 있습니다. 거기에서 BE 렌더링을위한 템플릿으로 세분화하는 것은 쉬운 일이 아닙니다. 때때로 FE 작업으로 시작하는 것이 가장 좋습니다. 이해 당사자들에게 시각적 진행 상황을 미리보고 싶어하는 따뜻한 느낌을 줄 것입니다.
결론:
신생 기업이고 시간이나 돈이 많이 들지 않으면 FE를 고용하거나 개발자 만 BE하지 마십시오. 고위급 웹 개발자와 훌륭한 UX / 디자이너를 고용하면 가능한 빨리 애플리케이션을 시작할 수 있습니다. 비용이 많이 들지만 훨씬 생산적이기 때문에 더 적은 비용이 필요합니다.
질문이 잘못되었다고 생각합니다.
내가 참여한 모든 신생 기업에는 FE-BE 전용 아키텍처가 없었습니다.
내가 아는 대부분의 신생 기업은 다음과 같습니다.
핵심 개발자가 없어도 API는 상태 비 저장 상태이며 쉽게 조롱 할 수 있습니다. 지옥, 프로젝트를 처음부터 시작해야한다면 모의에서 순전히 작동하는 전체 UI로 시작할 수 있습니다. 프레젠테이션에 좋습니다. 대부분의 피드백은 UI 때문입니다. 고객은 더 많은 것을 주목해야합니다 (대상 고객에 따라 다름).
예를 들어 Google 검색에는 웹을 크롤링하고 색인 생성하는 핵심 구성 요소가 있으며 Google UI는 완전히 다른 세계입니다. 이 코어는 WWW 이외의 검색을 쉽게 지원할 수 있지만 UI는 지원하지 않습니다.
이 방법으로 UI를 "플러그 가능"하고 분리 할 수 있습니다.
개발 지식을 언급했지만 프로젝트 관리 측면을 간과하고 있습니다. 핵심 팀에는 2 주 스프린트 기간이 필요할 수 있지만 UI 팀은 CI를 사용합니다. 모든 것이 항상 업로드됩니다. 핵심 팀은 이전 버전과의 호환성이 필요하지만 UI는 그렇지 않습니다.
언어가 다릅니다. C 구성 요소에 C 개발자가 필요할 것입니다. UI가 크로스 OS 언어로 작성되는 단일 OS에서 실행되는 경우 괜찮을 것입니다.
테스트가 다릅니다. UI 테스트 세계는 내가 소프트웨어 개발에서 가장 복잡한 것 중 하나입니다. 대부분의 신생 기업은 그것을 무시하고 나중에이 결정을 후회합니다. 테스트 할 때 BE와 FE를 분리 할 수 없습니다. 이를 처리하는 단일 장치 여야합니다.
오픈 소스 UI – 두 가지를 분리 할 때 얻을 수있는 가장 큰 장점 중 하나는 UI를 오픈 소스 할 수 있다는 것입니다. UI 프로젝트는 오픈 소스 지원이 필요합니다.
전체 session 기능을 이해할 수없는 UI 개발자를 상상할 수 없습니다 . 알다시피-다른 요청 사이에 로그인하고 로그인 상태를 유지합니다. 사실 그들은 Java가 아닌 PHP를 알고있을 수도 있지만 BE 개념은 명확해야합니다 (예 : 암호화 된 쿠키 사용). 특정 언어 장벽이 잘못되었습니다. 모든 개발자는 모든 언어로 기꺼이 일해야합니다. 몇 년 전에 누가 JavaScript로 BE를 작성할 것이라고 생각했을까요?
핵심, BE 및 FE의 3 개 팀이 있다면 자원 낭비입니다. DB는 어떻습니까? DBA가 있어야합니까? BE 개발자가 DB를 알아야하고 FE 개발자가 BE와 DB를 알아야하는 이유는 무엇입니까? 제한이 없습니다.
전문가가 필요한 경우 전문가를 아웃소싱하는 것이 좋습니다. 그들은 보통 양질의 코드를 제공하고 매우 빠릅니다. 그들이 떠나면 길을 잃을 것이기 때문에 반드시 사내에서 그들을 원하지는 않습니다. 게다가 당신은 오늘 온라인에서 훌륭한 조언을 얻을 수 있습니다. 최첨단 재료에는 다른 접근 방식이 필요할 수 있습니다.
따라서 모든 FE 개발자가 개발할 수있는 UI의 결과는 기본적으로 매우 얇은 BE입니다. UI에 두꺼운 BE가 있다면 아마도 Core에 필요한 일부 API 기능이있을 것입니다.
나머지는 눈에 띄는 개발자가 항상 하나 이상 있습니다. 그러한 얇은 FE가 주어지면 BE 코드로 다른 개발자를 지원 (개발하지 않음) 할 수 있습니다. 내 의견은이 개발자가 매우 좋은 위치에 있으며 적절하게 수여되어야한다는 것입니다 (급여가 아닌 다른 것). 또한 빌드 프로세스를 처리하고 올바르게 빌드 할 수 있다고 믿습니다.
이 모델은 BE 개발과 관련하여 뛰어난 유연성을 제공합니다. BE 세계는 지난 몇 년 동안 여러 차례의 전환을 알고 있었으므로 BE 안정성에 너무 의존하지 않는 것이 좋습니다. 핵심은 다른 이야기입니다.
FE와 동일한 프로젝트 여야 합니까? 다음 사항에 유의해야합니다.
계속할 수는 있지만 BE와 FE는 같은 팀이어야하지만 다른 프로젝트 일 것입니다.
성공적인 구현은 몇 가지 일 수 있다고 생각합니다. 강력한 백엔드를 가지고 있지만 사용자 인터페이스와 모든 "프론트 엔드"부분을 잘 파악하고있는 유일한 개발자가 있다면 아마도 성공했을 것입니다. 그러나 (개인 경험으로는) 일반적으로 그렇지 않습니다. 예를 들어, 나는 백엔드 개발자라고 생각합니다. 그러나 나는 혼자서 많은 프로젝트를 수행합니다. 프레젠테이션과 클라이언트 측 작업을 수행합니까? 확실한. 그들은 실제 재능있는 디자이너와 클라이언트 측 개발자가 만드는 것처럼 보입니까? 절대적으로하지.
모두주고받습니다. 그러나 두 개발자의 공동 작업으로 인해 주저하지 마십시오. 개발자와 디자이너 사이에서 생산을 극대화 할 수있는 방법이 있습니다.
즉 ... 그것은 달려있다
if you have a startup, don't assign roles. Better hope that you assembled a good self organizing team. If everybody knows each other, everybody knows who does what the best.