Có phải là phổ biến để tách back-end và front-end thành hai vị trí trong các dự án phát triển web?

Khi khởi động web, có phổ biến hơn không khi một kỹ sư làm việc ở mặt trước VÀ mặt sau của tính năng (về cơ bản phụ trách toàn bộ tính năng)? Hoặc có các kỹ sư tách biệt giữa back-end và front-end?

Những cái nào có lợi hơn và cho những tình huống?

Nhược điểm, tôi nhận thấy, liên quan đến việc có một kỹ sư phụ trách toàn bộ tính năng là người đó chỉ có thể đặc biệt mạnh về phát triển ngoại tuyến hoặc phụ trợ chứ không phải cả hai, do đó đôi khi bị giảm tốc độ và chất lượng.

Có các nhà phát triển frontend và backend trên một tính năng giúp tăng tốc độ của tính năng và chất lượng VÀ nó khuyến khích sự hợp tác. Nhưng tôi lo ngại về việc có 2 kỹ sư làm việc trên một tính năng có thể sử dụng tài nguyên kém vì kỹ sư 1 có thể được đặt trên một tính năng khác để làm việc.

Thực tiễn phổ biến / tốt nhất để phân bổ tài nguyên kỹ thuật phụ trợ / frontend ở một giai đoạn khởi đầu nhỏ là gì? Và sau đó nó sẽ thay đổi như thế nào khi nó phát triển?

Đây là sự khôn ngoan của tôi từ 14 năm kinh nghiệm:

• nếu bạn có một khởi nghiệp, đừng phân công vai trò. Hy vọng tốt hơn rằng bạn tập hợp một nhóm tự tổ chức tốt. Nếu mọi người biết nhau, mọi người đều biết ai làm điều tốt nhất. Một người quản lý dự án sẽ chỉ cản trở.
• sau này, sự khác biệt giữa front-end và back-end có ý nghĩa. Trong phần phụ trợ, chất lượng là một. Mã phải được thực hiện, an toàn và giao dịch an toàn. Trong front-end, thời gian thực hiện vấn đề. Và bạn phải có khả năng dựa vào một back-end tốt. Các mục tiêu khác nhau của front-end và back-end không phối hợp tốt với nhau.
• back-end đã tồn tại trước khi bộ mã hóa front-end bắt đầu hoạt động. Nếu không, bộ mã hóa phía trước sẽ bị làm chậm quá nhiều.
• phụ trợ phải có khả năng phản ứng nhanh theo yêu cầu của người dùng để không làm chậm chúng

Câu trả lời tốt nhất là từ @Shark, nhưng chỉ phần cuối "Nó phụ thuộc". Theo kinh nghiệm của tôi, khoảng 16 năm hoặc lâu hơn, tôi đã thấy cả hai tùy chọn đã thử trong nhiều cấu hình khác nhau. Là một nhà phát triển stack đầy đủ bản thân mình, đây là những gì tôi đã tìm hiểu:

* (BE = Back End, FE = Front End)

Tổng thể phát triển ngăn xếp chia nhỏ:

1. Thực tiễn phát triển Agile (một chiến lược phổ biến hiện nay) khuyến nghị phát triển tính năng, trong đó tính năng này là một chức năng có giá trị duy nhất theo quan điểm của khách hàng. Từ quan điểm này, bạn nên có nhà phát triển của bạn thực hiện cả hai.

2. Việc chia ngăn xếp dọc theo ranh giới máy chủ sẽ tạo ra một điểm tích hợp giữa hai nhà phát triển. Trừ khi họ giao tiếp hiệu quả và làm việc tốt với nhau, điều này sẽ gây ra một số lỗi khá lớn khi hai tính năng này kết hợp với nhau.

3. Áp dụng quy tắc giao tiếp n (n-1) / 2 từ Tháng huyền thoại và bạn sẽ thấy rằng các tính năng chia thành hai phần giữa hai người sẽ tăng khối lượng công việc chung của bạn. Cấp quy tắc đó cũng áp dụng cho các tính năng, nhưng chia ngăn xếp sẽ nhân đôi số lượng giao tiếp.

4. Một nhà thiết kế sẽ giải quyết các vấn đề của các nhà phát triển BE không thể tạo ra các giao diện hấp dẫn từ đầu. Điều này giả định rằng ít nhất họ biết html & css và có thể tạo ra một giao diện phù hợp với các ảnh chụp màn hình được tạo bởi nhà thiết kế.

5. Các tính năng thường là các thành phần biệt lập tương tác rất ít với các tính năng khác. Điều này không phải lúc nào cũng đúng nhưng thường thì điểm tương tác ở mức thấp như cơ sở dữ liệu hoặc hệ thống tập tin. Vì vậy, không có nhiều ngăn cản nhà phát triển full-stack thực hiện tính năng của họ. Nhưng nếu một nhà phát triển FE phải đợi một nhà phát triển BE hoàn thành một nhiệm vụ, thì nó sẽ thêm sự chậm trễ hơn nữa so với mức giảm năng suất ở điểm 3.

6. Web2.0 làm mờ sự khác biệt giữa FE & BE hơn nữa. Với các khung MVC và toàn bộ các ứng dụng được xây dựng ở phía máy khách, giờ đây cần có nhiều kiến ​​thức BE để thực hiện các ứng dụng FE an toàn và hiệu quả.

7. Nắm bắt lớn nhất của tôi đối với thực tiễn này là nó giới hạn khả năng của tất cả mọi người tham gia vào dự án. Mặc dù đây là một thông lệ phổ biến vào đầu những năm 2000 nhưng nó đã được thực hiện vì không cần thiết bởi vì việc tìm kiếm các nhà phát triển có thể làm cả hai khá khó khăn (hoàn toàn là vì sự mới mẻ không phải vì một số khó khăn nội tại trong việc học cả hai.) một thập kỷ sau chúng ta vẫn có những "nhà phát triển web" không biết CSS.

8. Nắm bắt lớn thứ hai của tôi là nó có thể dễ dàng phân khúc một nhóm phát triển. Một nhà phát triển FE tạo ra một lỗi sau khi sửa đổi mã BE và nhóm bỏ phiếu để hạn chế bán buôn phát triển chồng chéo. Trong khi các đánh giá mã và giáo dục có thể giải quyết vấn đề, thay vào đó mọi người trở thành lãnh thổ.

Lợi ích / trường hợp sử dụng của việc phát triển ngăn xếp chia nhỏ:

1. API RESTful hoàn hảo cho việc phân định này vì không có FE. Thường thì một công ty sẽ làm việc trên API RESTful trước, sau đó phát triển các ứng dụng web của họ lên hàng đầu. Trong trường hợp này, có một trường hợp mạnh mẽ để giữ cho nhóm BE tập trung vào phiên bản chính tiếp theo trong khi FE đang hoàn thiện ứng dụng. Nhưng sự nguy hiểm của việc khuấy đảo vẫn tồn tại - đặc biệt là nếu thông tin mới được phát hiện trong giai đoạn phát triển FE yêu cầu sửa đổi không tầm thường đối với API BE.

2. Khối lượng công việc không cân bằng giữa FE & BE cũng là một trường hợp tốt để tạo nhóm chỉ FE. Một lần nữa, điều này rất tình huống khi có lẽ sự phát triển chính được thực hiện thông qua một ứng dụng máy tính để bàn và công ty đang cố gắng phát triển giao diện web 'lite'.

3. Đào tạo nhà phát triển mới / cơ sở. Nếu bạn đang thuê một thực tập sinh hoặc một nhà phát triển cơ sở và lo ngại về việc ném chúng vào sâu, thì đó là một lựa chọn tốt để đầu tư một số chi phí truyền thông / tích hợp đó vào một hệ thống phát triển ngang hàng.

Mối quan tâm về câu trả lời được chấp nhận của @ Ralf trên trang này:

1. Điểm đầu tiên khá táo bạo - và nó sẽ thất bại nhanh chóng nếu bạn không có một trong những "đội tự tổ chức tốt" đó. Ngay cả khi bạn có nhóm đó, bạn và họ sẽ vượt qua ranh giới của họ. Và các nhóm tự tổ chức tốt không phải lúc nào cũng tự tạo động lực để làm điều đó.

2. Điểm thứ hai của bạn là sai. Phát triển web hiện đại yêu cầu mã FE có hiệu suất, an toàn, an toàn không đồng bộ, chống XSS, trình duyệt chéo và được phát triển nhanh chóng. Các mục tiêu đơn giản là không cạnh tranh với BE, chúng có hiệu quả tương đương.

3. Điểm thứ ba cũng là một giả định tồi - phát triển FE có thể bắt đầu với html / css / js thuần túy mà không có bất kỳ công việc nền tảng BE nào. Từ đó, chỉ có một nỗ lực tầm thường để chia nó thành các mẫu để hiển thị BE. Thông thường, tốt nhất là bắt đầu với công việc FE vì nó sẽ mang lại cho các bên liên quan cảm giác ấm áp và mờ nhạt để thấy sự tiến bộ trực quan lên phía trước.

Phần kết luận:

Nếu bạn là một người khởi nghiệp và bạn không có nhiều thời gian hay tiền bạc để đốt, thì đừng thuê các nhà phát triển FE hoặc BE. Thuê các nhà phát triển web cấp cao và một ux / designer giỏi, và họ sẽ đưa ứng dụng của bạn lên mặt đất nhanh nhất có thể. Chúng có giá cao hơn, nhưng chúng có năng suất cao hơn nhiều và bạn sẽ cần ít hơn.

Tôi nghĩ rằng câu hỏi là sai.

Tất cả các phần khởi động tôi tham gia không có kiến ​​trúc chỉ có FE-BE.

Hầu hết các công ty khởi nghiệp tôi biết đều có:

• Core - sản phẩm thực tế trưng ra giao diện
• UI - BE và FE. BE sử dụng API của Core.

API không trạng thái và dễ bị chế giễu - ngay cả khi không cần Core Developer. Chết tiệt, nếu tôi phải bắt đầu một dự án từ đầu, tôi có thể bắt đầu với toàn bộ giao diện người dùng hoạt động hoàn toàn trên các mô hình - sẽ rất tốt cho các bài thuyết trình. Hầu hết các phản hồi là do UI. Khách hàng lưu ý rằng nhiều hơn - (phụ thuộc vào đối tượng mục tiêu của bạn.)

Ví dụ: Google Search có thành phần Core thu thập thông tin trên web, lập chỉ mục cho nó, v.v. và UI của Google là một thế giới hoàn toàn khác. Lõi này có thể dễ dàng hỗ trợ các tìm kiếm không WWW, trong khi UI không thể.

Bằng cách này, giao diện người dùng của bạn là "có thể cắm được" và bạn có những mối quan tâm riêng biệt.

Bạn đã tham khảo kiến ​​thức Phát triển, tuy nhiên bạn đang xem xét các khía cạnh quản lý dự án. Mặc dù nhóm nòng cốt có thể cần thời gian chạy nước rút 2 tuần, nhóm UI sẽ sử dụng CI - mọi thứ đều được tải lên mọi lúc. Nhóm Core sẽ cần khả năng tương thích ngược trong khi UI thì không.

Ngôn ngữ khác nhau. Bạn có thể sẽ muốn các nhà phát triển C cho thành phần Core - và bạn sẽ ổn nếu nó chạy trên một HĐH duy nhất, trong đó giao diện người dùng sẽ được viết bằng Ngôn ngữ hệ điều hành chéo.

Các xét nghiệm khác nhau. Thế giới kiểm tra UI là một trong những điều phức tạp nhất mà tôi biết trong phát triển phần mềm. Hầu hết các công ty khởi nghiệp bỏ bê nó và hối tiếc quyết định này sau này. Bạn không thể tách BE và FE khi kiểm tra. Nó phải là một đơn vị duy nhất xử lý nó.

UI nguồn mở - một trong những lợi ích lớn nhất của việc tách hai loại này là bạn có thể mở UI của mình. Dự án UI cần hỗ trợ nguồn mở.

Tôi không thể tưởng tượng một nhà phát triển UI không thể hiểu toàn bộ session tính năng. Bạn biết - nơi bạn đăng nhập và duy trì đăng nhập giữa các yêu cầu khác nhau. Đúng là họ có thể biết PHP chứ không phải Java .. nhưng khái niệm BE phải rõ ràng (ví dụ: sử dụng cookie được mã hóa). Rào cản ngôn ngữ cụ thể là sai - mọi nhà phát triển nên sẵn sàng làm việc với bất kỳ ngôn ngữ nào. Ai có thể nghĩ rằng họ sẽ viết BE bằng JavaScript vài năm trước?

Nếu bạn tiếp tục có 3 đội: Core, BE và FE, thì thật lãng phí tài nguyên. Thế còn DB? bạn nên có DBA? Tại sao nhà phát triển BE nên biết DB và nhà phát triển FE không biết BE và DB? Không có giới hạn.

Nếu bạn yêu cầu các chuyên gia, và bạn sẽ, gia công cho họ hoạt động khá tốt. Họ thường cung cấp mã chất lượng và họ làm điều đó khá nhanh. Bạn không nhất thiết muốn họ ở trong nhà vì bạn sẽ bị lạc nếu họ rời đi. Bên cạnh đó bạn có thể nhận được lời khuyên tuyệt vời trực tuyến ngày hôm nay. Công cụ cắt cạnh có thể yêu cầu cách tiếp cận khác nhau.

Vì vậy, kết quả về cơ bản là một BE rất mỏng trong UI mà mọi nhà phát triển FE có thể phát triển. Nếu bạn có BE dày trong UI, rất có thể bạn có một số chức năng API được yêu cầu trong Core.

Luôn có ít nhất một nhà phát triển nổi bật so với phần còn lại. Với một FE mỏng như vậy, anh ấy / cô ấy có thể quản lý việc hỗ trợ (không phát triển) các nhà phát triển khác trong mã BE. Ý kiến ​​của tôi là nhà phát triển này ở một vị trí rất tốt và nên được trao giải thích hợp (mặc dù không phải là tiền lương, một cái gì đó khác). Tôi cũng tin tưởng rằng họ sẽ có thể xử lý quá trình xây dựng và xây dựng đúng cách.

Mô hình này cung cấp cho bạn một sự linh hoạt tuyệt vời về phát triển BE. Thế giới BE đã biết một số bước ngoặt trong vài năm qua, vì vậy tôi không khuyên bạn nên dựa vào sự ổn định của BE quá nhiều. Core là một câu chuyện khác nhau.

Vẫn còn câu hỏi - liệu FE và BE có phải là cùng một dự án không? Bạn cần lưu ý những điều sau

• Tài nguyên tĩnh được phục vụ tốt nhất từ ​​máy chủ trước. Vì các máy chủ Front-End (ví dụ nginx) rất mạnh và vì bạn có thể sử dụng Cache cho tài nguyên tĩnh, nên bạn có thể quản lý bằng một triển khai tài nguyên tĩnh (phải là tất cả nội dung HTML, JS, CSS, Hình ảnh).
• Mã cuối cùng không có cùng mức độ xa xỉ, vì vậy bạn phải có một hệ thống phân tán - cũng được quản lý bởi một máy chủ phía trước.
• Mã FE rất được sử dụng lại với tất cả các công nghệ mới hỗ trợ JavaScript. Bây giờ bạn có thể viết các ứng dụng Máy tính để bàn và Di động bằng JavaScript.
• Quá trình xây dựng là hoàn toàn khác nhau - và thậm chí có thể bao gồm phân phối bản vá, nâng cấp, cài đặt, v.v.

Tôi có thể tiếp tục, nhưng tôi hy vọng rõ ràng rằng tôi nghĩ BE và FE nên là cùng một đội, nhưng có thể là các dự án khác nhau.

Tôi nghĩ việc thực hiện thành công có thể là một vài điều. Nếu có một nhà phát triển duy nhất có phần phụ trợ mạnh mẽ nhưng cũng nắm bắt tốt về giao diện người dùng và tất cả các phần "front-end", thì có lẽ nó có thể thành công. Tuy nhiên, đó không phải là trường hợp điển hình (theo kinh nghiệm cá nhân của tôi). Ví dụ, tôi coi mình là một nhà phát triển back-end. Nhưng tôi làm việc trên rất nhiều dự án một mình. Tôi có làm việc trên bản trình bày và các phần phía khách hàng không? Chắc chắn rồi. Chúng có đẹp như một nhà thiết kế tài năng thực sự và nhà phát triển phía khách hàng sẽ làm không? Tuyệt đối không.

Tất cả là cho và nhận. Nhưng đừng để sự hợp tác của hai nhà phát triển khiến bạn ngần ngại. Có những cách đã được thử và đúng để tối đa hóa sản xuất giữa nhà phát triển và nhà thiết kế.

Nói cách khác ... Nó phụ thuộc