프런트 엔드 우선 또는 백 엔드 우선. 좋은 시스템 설계 연습은 무엇입니까?

지금 학교 등록 시스템을 개발해야하는 고객이 있습니다. 이제는 이런 종류의 도전에 직면 한 것은 이번이 처음입니다. 내가 만든 과거 소프트웨어의 대부분은 그렇게 복잡하지 않습니다.

나는 대부분의 사람들이 복잡한 소프트웨어를 만들었다는 것을 알고 있습니다. 프런트 엔드 또는 백 엔드를 먼저 설계해야합니까?

감사!

인터넷에서 얼마 전에 찾은 기사의 결론은 다음과 같습니다. 그냥 공유하고 싶었다

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

프론트 엔드 대 백엔드 개발자 (나의 테이크)

내 개인적인 테이크

다시 말하지만 훈련 문제, 몇 가지 광범위한 뇌졸중 일반화입니다.

프런트 엔드 개발자

• 일반적으로 CS 학위가 없거나 3 단계 학교의 CS 학위가 없습니다.
• 기본과 유사한 언어로 작업하십시오 (PHP는 기본 임)
• Photoshop 문서를 CSS / HTML / etc로 변환하는 데 시각적 인 기술이 필요합니다.
• 타입 자유 언어로 인해 반복 프로그래밍에 대한 높은 내성을 갖습니다.

백엔드 개발자

• CS 학위 또는 많은 경험이 있습니다
• 그들의 문제 해결 접근 방식에 대해 좀 더 체계적인 경향이 있습니다.
• 누출되는 하나의 물체를 찾는 데 며칠을 소비하지 마십시오.
• 문제를 해결하기위한 도구를 사용해보십시오

뒤에서 시작하여 앞으로 나아가면 클라이언트를 오해 할 위험이 있습니다. 쉽게보고 이해하지 못하는 것을 만들 때 요구 사항을 충족하는지 확인하는 데 매우 쉽게 참여할 수 없습니다. 이것은 많은 작업을 낭비 할 수 있음을 의미합니다.

앞에서 시작하고 뒤로 이동하면 클라이언트가 거의 끝났다고 생각할 위험이 있습니다. 모든 작업을 완료하면 화면에 간단한 양식이 그려집니다. 그러면 며칠 만에 끝났기 때문에 왜 그렇게 오래 걸리는지 질문 할 수 있습니다. 또한 더 적합한 프론트 엔드가 더 단순했을 때, 앞뒤로 결혼하기 위해 복잡한 작업을 수행해야한다는 것을 깨달을 때 자신을 구석에 그리는 위험이 있습니다.

IMO, 먼저 기능에 대해 작업해야합니다. 시스템의 각 기능에 대해 프론트 엔드와 백엔드를 함께 작성하십시오. 이것은 고객에게 진행 상황에 대한 더 큰 가시성을 제공하며, 너무 많은 고통을주지 않으면 서 "아니, 그건 내가 의도 한 것이 아닙니다"라고 말할 기회를줍니다.

즉, 서버 하드웨어 나 의존하는 소프트웨어의 기능 (예 : 사용중인 데이터베이스)을 고려해야하는 매우 큰 프로젝트 인 경우에는 먼저 해당 부분에 대해 잘 알고 있어야합니다.

소프트웨어에는 많은 차원이 있으므로 지나치게 단순한 프론트-백-백 (front-vs-back)은 좋지 않은 질문이며, 현명하고 유용한 답변을 제공하는 것은 매우 어렵습니다.

하나의 관점은 데이터의 정적 구조입니다. 이보기에는 아키텍처 계층 ( "전면"), 사용 사례 및 행위자, 구현 비용 또는 위험과 같은 3 가지 차원이 있습니다.

하나의 관점은 처리의 동적 구조입니다. 이 뷰에는 3 차원 이상이 있습니다.

세 번째 관점은 자연스럽게 계층으로 떨어지고 사용 사례를 지원하며 비용과 위험이있는 아키텍처 구성 요소입니다.

나는 계속할 수 있지만 요점은 이것입니다.

프론트 엔드 대 백엔드 개발자 (나의 테이크)

대략 문제를 보는 데 가장 유용한 방법입니다. 실제 개발자와 개발자의 의견은 여기서 거의 중요하지 않습니다. 중요한 것은

• 사용 사례 및 행위자

• 이러한 사용 사례를 지원하는 논리 데이터 모델

• 유스 케이스의 일부로 수행 된 프로세스

• 유스 케이스의 논리 및 처리 요소를 빌드하는 데 사용할 컴포넌트입니다.

이것이 대부분의 사람들이 사용자 스토리 또는 사용 사례별로 시스템을 분해해야한다고 말하는 이유입니다.

개발을 수행 할 사람들에 대해 광범위한 스트로크 일반화를하지 마십시오.

둘 다. 앱이 무엇을 할 수 있어야합니까? 핫 밸브가 뜨거운 물을 공급하고, 콜드 밸브가 냉수를 공급하고, 처음에 물이 흐르고, 필요한 곳에서 파이프를 확장 한 다음 집안의 모든 방에 실제로 배관을 설치하거나 집이 어떻게 될지 걱정할 수 있는지 확인하십시오. 실제로 정확하게 보입니다.

프런트 엔드는 일부 스위치와 레버가있는 마스크 일뿐입니다. 백엔드는 단지 데이터 검색 및 처리 요청을받는 것입니다. 원하는 조합으로 신속하게 구현할 수있는 지점에 도달하십시오.

그러나 무엇을하든 한 디자인이 다른 디자인을 지시하지 않도록하십시오. 그렇게 광기는 거짓말입니다.

개발자가 마음을 바꾸는 횟수에 관계없이 고객이 필요로하는 모든 것을 구축 할 수 있도록 도구를 준비하십시오. 그런 다음 사양에 맞게 빌드하고 작은 cusses가 마침내 행복해질 때까지 다시 트리거하십시오.

또한 2008 년 프론트 엔드 개발자와 백엔드 개발자를 비교하는 것은 오랜 세월이 지난 웹 시대였습니다. 재미를 위해 질문에 링크 한 이후로 오래된 밤나무에 몇 가지 사항을 수정 / 추가하고 싶습니다.

프런트 엔드 개발자

일반적으로 CS 학위가 없거나 3 단계 학교의 CS 학위가 없습니다.

손의 쇼. CS 학위를 가진 사람들이 프런트 엔드에서 모범 사례를 배우는 사람은 몇 명입니까? 또는 JavaScript로 혼란을 일으키지 않는 방법은 무엇입니까? 또는 IE6-IE9에서 CSS 문제를 처리하는 방법은 무엇입니까? 학계를 운영하는 교과서 산업은 끊임없이 변화하는 기술을 다루기에는 너무 뚱뚱하고 부풀어 오르기 때문에 대학에서 '심각한'주의를 거의받지 못했습니다. 이것은 나처럼 늦은 꽃 피는 사람들에게 탁월했습니다.

기본과 유사한 언어로 작업하십시오 (PHP는 기본 임)

PHP는 클라이언트 측 기술이기 때문에? 또는 Scheme에서 주로 영감을 얻은 JavaScript는 Basic보다 Visual Basic과 더 공통적이기 때문에 이제는 더 이상 프론트 엔드에서 계속 관심을 가지지 않고 백엔드 .NET 웹 응용 프로그램에서 여전히 사용할 수 있었습니까? 블로그는이 시점에서 자칭 오픈 소스 웹 개발자와 기업 대중 기술을 사용하는 CS 대학원 웹 개발자를 비교합니다. 나는 그 특정 싸움의 양쪽에서 동등한 지분으로 견딜 수없고 유능한 상태에 빠졌지 만 그는 여전히 OT에 있습니다.

Photoshop 문서를 CSS / HTML / etc로 변환하는 데 시각적 인 기술이 필요합니다.

약간 넓은 "시각적 기술"보다 세부 사항에 더 많은주의를 기울입니다. 우리 모두에게 미적 디자인 기술이있는 것은 아닙니다. 그러나 그렇습니다. 대부분의 사람들은 Jr. 레벨에서이 내용을 배워야하며 실제로 CSS 메스가 작동 할 때 JS 망치를 사용하지 않는 좋은 UI를 작성하는 것이 매우 중요합니다.

타입 자유 언어로 인해 반복 프로그래밍에 대한 높은 내성을 갖습니다.

그렇기 때문에 앞에서 언급 한 부분을 먼저 원합니다. 우리는 눌린 버튼을 전달하면 상품을 생산 / 검색합니다. 우리는 그들을 포장하고 배달합니다. 이러한 것들이 어떤 식 으로든 서로 밀접하게 구속 될 이유는 없습니다. 또한 실제로 OOP에 빠지지 않으면 엄격한 타이핑이 반복 프로세스를 방해해서는 안됩니다. 실제로 수업이없는 언어에 대해 배우기를 좋아하는 대부분의 사람들은 실제로 수업을하지 않습니다. 그러나 악취가 발생하더라도 프론트 엔드는 예측 가능한 액세스 포인트 만 필요하며 JSON이 아닌 JavaScript를 동적으로 작성하는 것과 같은 바보 같은 일을하지 않는 한 백엔드에서 원하는 모든 것을 수행 할 수 있습니다 성공적인 백엔드 동작을 HTML 구조에 "바로 그렇게"묶으십시오. * 기침 * 자바 개발자 * / 기침 *

이에 대한 하나의 정답은 없습니다. 어떤 상황에서는 어떤 상황에서도 좋을 수도 있고 나쁠 수도 있습니다.

(수락 및 단위) 테스트에 의해 주도되는 TDD 접근 방식을 고려하는 것이 좋습니다.

최소한의 기능으로 시스템의 기본 구조 인 기본 인프라 를 결합하여 시작하십시오 . 이것은 개념이 작동하고 다른 구성 요소가 함께 작동 할 수 있음을 보여주기위한 것입니다. 여기에는 실제로 뼈대 UI (해당되는 경우)가 포함되어 있으며 실제로 최소한의 것을 보여줄 수 있습니다.

그런 다음 세부 기능을 기능별로 구체화하십시오 . 특정 기능 / 시나리오에 대한 승인 테스트를 작성하고 실패한 다음이를 만족시키는 코드를 작성하십시오. 이렇게하면 외부에서 안쪽으로 작업 할 수 있습니다 . 시스템은 일부 입력 메시지를 수신하므로 해당 메시지를 처리 ​​/ 변환하고 그에 대한 작업을 수행 한 후 결과를 다시 UI로 전파해야합니다. 이 과정에서 도메인 개념을 발견하고 UI에서 도메인 계층에 이르기까지 새로운 클래스로 개념을 표현합니다.

이 접근 방식의 경우 권장되는 수치는 육성 객체 지향 소프트웨어, Guideed by Tests 입니다.

먼저 API

두 팀의 엔지니어는 프론트 엔드와 백엔드 사이의 API에서 함께 작업해야합니다. 그런 다음 두 팀 모두 설계된 API를 기반으로 작업을 시작할 수 있습니다. 이는 팀이 동시에 작업을 시작할 수 있다는 명백한 이점 외에 다른 프런트 엔드 팀이 웹 클라이언트 후 모바일로 작업을 시작할 수 있다는 이점이 있습니다.

반복적 인 접근 방식과 결합하면 다음과 같아야합니다.

1. 간단한 API 디자인
2. 두 팀 모두 API를 기반으로 개발 및 테스트
3. 통합 테스트
4. 고객에게 보여주고 피드백을받습니다.
5. API를 강화하고 반복하십시오.

프론트 엔드로 시작하지만, 먼저 이미 존재하는 응용 프로그램을 찾을 수없는 이유는 무엇입니까? 이것은이 프로젝트에 대한 더 많은 통찰력을 줄 것입니다. 그들은 독특한 요구 사항이 있거나 더 저렴하게 만들 수 있다고 생각합니까?

보안 기대치와 법이 요구하는 사항을 완전히 파악하십시오. 이것이 어떤 종류의 학교인지는 모르지만 학생 정보에는 보통 기밀이 필요합니다.

잠재적 인 학생들이 웹 사이트에서 데이터를 입력하는 경우 그래픽 디자인이 더 문제가 될 것입니다.

그들의 요청에 따라 프론트 엔드의 모형을 작성하십시오. GUI가 간단하지 않다고 생각하면 기능을 수행해야 할 수도 있으므로 실제로 작동하는 것을 볼 수 있습니다. 그들은 데이터 입력에 따라 다른 방향으로 분기되는 일종의 '마법사'로 등록을 볼 수 있습니다.

그런 다음 데이터베이스에 정보가 유지되도록 시작할 수 있습니다.

예, OP가 얼마 전에 물었다는 것을 깨달았습니다. 백엔드에서 시작하지만 프런트 엔드를 MOCK UP하여 사용자가 원하는 것을 볼 수 있도록합니다. 가치가있는 전부는 종과 휘파람입니다. 백엔드는 돈이있는 곳이며, 일단 똑바로하면 FE는 고기에 대한 육즙입니다.

내 의견을 확장 :

먼저 요구 사항을 수집 한 다음 사용 사례 및 디자인으로 바꿉니다.

먼저 자세한 데이터베이스 정의가 제공됩니다. 나는 고객이 완전히 이해하지 못하더라도 상관하지 않고 앉아서 앉아서 강제로 서명하도록합니다 (아마도 기술에 정통한 사람들 중 한 명이 그렇게해야한다는 것을 깨달았습니다) )를 진행하기 전에

BE없이 어떻게 FE로 시작할 수 있습니까? 무엇에 대한 FE ??? 데이터베이스를 정의하십시오 !! 이것이 FE가 조작하는 것입니다.

좋아, 문제 및 이후 미 조정이있을 것, 내가 할 빙산의 특정 팁은 대부분의 대부분이 이해하는 것입니다 때문에, 최대한 빨리 클라이언트의 앞에 간단하고, 샘플, GUI를 얻기 위해 좋은 것에 동의합니다.

그러나, 나는 1) 토론 거론을 위해 거친 모의 일 뿐이라고 강조 하고, 2) 의도적으로 추악 하지만 기능적 으로 만듭니다. 넓은 & 배경은 밝은 파란색입니다.

나는 대부분의 답변을 여기에 따르고 (따라서 따라온) 고객에 너무 집중하는 경향이 있지만, 순수한 관점에서 볼 때, 먼저 BE를 조작하기 위해 FE를 설계 할 수 없다고 주장합니다. 그 BE를 디자인.