Làm thế nào khả thi để có một ứng dụng web trên một số kho nhỏ riêng tư?

Chúng tôi là một nhóm ngân sách thấp làm việc trên một ứng dụng web. Do một số biến chứng, chúng tôi có thể cần phải làm việc từ xa từ tháng 1 trở đi. Sau một số tư vấn và googling, chúng tôi đã kết luận rằng một số kho lưu trữ nhỏ là lựa chọn rẻ hơn. Chúng tôi đang suy nghĩ trong:

Phần cuối và dịch vụ
Middleware
Mặt trước

Bằng cách này, chúng tôi có thể tách trong các nhóm có liên quan, mỗi nhóm làm việc từ xa trong kho lưu trữ của họ. Làm thế nào khả thi để có ứng dụng của chúng tôi trong một số kho nhỏ tư nhân?

Ngoài ra, chúng ta nên cân nhắc những gì nếu chúng ta làm việc theo cách này?

Lưu ý: Tôi đang hỏi về một dự án lớn, đơn lẻ được chia thành nhiều kho nhỏ. Điều này khác với các câu hỏi liên quan được hỏi trên trang web này , bởi vì họ đang yêu cầu nhiều dự án trong một hoặc một số kho lưu trữ. Ngoài ra, chúng tôi đã chọn để lặn dự án, chủ yếu là vì chúng tôi không sẵn sàng đầu tư một kho lưu trữ tư nhân lớn trừ khi chúng tôi sẽ gắn bó với nó.

project-management team repository

— Bạc
nguồn

Theo kho lưu trữ, bạn có nghĩa là kho lưu trữ mã (ala git hoặc svn)?

— Jay Elston

Scant là chính xác trong đó chia tách nhóm là một vấn đề lớn hơn nhiều so với việc chia repo. Đội tôi làm việc có vài chục repos nhưng chúng tôi vẫn là một đội.

— Ixrec

Câu trả lời:

"... chúng tôi đã kết luận rằng một số kho lưu trữ nhỏ là lựa chọn rẻ hơn."

Thật tuyệt. Phân chia và chinh phục. Bạn chia nỗ lực thành những mảnh hợp lý, đưa từng mảnh cho một nhóm khó tính khác nhau, làm việc như điên trong vài tháng, mang mọi thứ lại với nhau, và ...

và ...

Chà, nó sẽ là một cơn ác mộng chết tiệt. Nó chắc chắn sẽ không rẻ hơn. Tại sao nó sẽ là?

"Chi phí" lớn nhất trong bất kỳ dự án phần mềm nào là truyền thông. Bạn không tiết kiệm tiền bằng cách viết mã nhanh hơn. Đó là những lập trình viên bí mật sẽ không thừa nhận. ( Psst. Đừng nói với ai. Thực sự không quan trọng bạn viết mã nhanh như thế nào. ) Thời gian viết mã hoàn toàn bị thu hẹp bởi thời gian dành cho việc lên kế hoạch và nói chuyện và đàm phán và chiến đấu và nói chuyện và gặp gỡ và nói chuyện nhiều hơn và thỏa hiệp và nhận ra bạn không nên thỏa hiệp và hứa sẽ làm tốt hơn và la hét và ước muốn và "giải quyết" (đó không phải là một từ, chết tiệt) và lặp đi lặp lại và vỗ về và nói chuyện và không thể ngủ.

Vì vậy, bạn chia công việc của bạn thành các phần riêng biệt và trao từng phần cho một nhóm riêng biệt. Bạn vừa làm gì vậy? Bạn thêm gánh nặng giao tiếp. Nếu bạn may mắn vàcác nhóm của bạn rất hoàn hảo, hoàn toàn không có sự khác biệt về chi phí giữa một kho lưu trữ lớn và một vài kho nhỏ. Nếu bạn không may mắn (một số ít), việc chia thành các nhóm riêng biệt sẽ thực sự tốn kém hơn. Nó đủ khó để duy trì đồng bộ khi tất cả các bạn ở trong cùng một cơ sở mã, bước lên từng ngón chân của nhau. Bây giờ hãy tưởng tượng sẽ khó đến mức nào khi ba đội khác nhau nghĩ rằng các yêu cầu có nghĩa là hơi khác một chút (không có cách nào sửa nhanh vì họ không phá vỡ nội dung của các đội khác), có văn hóa hơi khác nhau, và cuối cùng, là Rất có động lực để tránh đổ lỗi khi mọi thứ đi sai, vì vậy họ sẵn sàng ném các đội khác xuống xe buýt.

Tôi biết, tôi biết ... đội của bạn tốt hơn thế. Nhưng họ có thực sự? Bạn có đủ tự tin để đặt cược tiền vào nó?

Hãy nhìn xem, trong cả hai cách tiếp cận (repo lớn / nhiều repos nhỏ) bạn sẽ phải chế giễu một đống tào lao ngay từ đầu. Bạn bắt đầu làm việc mù. Càng sớm càng tốt, ngay khi chúng có sẵn, bạn nên bắt đầu sử dụng các triển khai cụ thể từ các lớp khác. Điều này sẽ xác định vấn đề và hiểu lầm sớm. Chắc chắn, nó sẽ có một chút gập ghềnh, nhưng đó là một địa ngục ít gập ghềnh hơn là phát triển độc lập với một thông số run rẩy và một cái bắt tay, và sau đó gấp mọi thứ lại với nhau muộn.

Quan điểm của tôi là, repo lớn / repos nhỏ không phải là vấn đề. Điều quan trọng là cách bạn cấu trúc các đội của bạn. Lý tưởng nhất, các nhóm của bạn có bản sắc độc lập nhỏ trong một bản sắc gắn kết lớn hơn. Kinda giống như các cơ quan trong một sinh vật hoặc có thể là nấm mốc . Bất kể bạn cấu trúc mã như thế nào, hãy cho mọi người cơ hội va vào nhau. Làm cho giao tiếp dễ dàng. Cùng mắc lỗi và sửa chúng sớm và thường xuyên.

— Scant Roger
nguồn

Tôi không đồng ý với hầu hết câu trả lời này. Truyền thông tất nhiên là quan trọng, nhưng; chỉ vì bạn chia cơ sở mã thành nhiều kho lưu trữ, có: 1. cộng tác - cộng tác viên có thể xem cơ sở mã (và sửa đổi nếu họ thực sự cần), 2. tài liệu . Nếu bạn đang xây dựng API REST tách biệt với giao diện, API có thể được lập thành tài liệu rất tốt và không có rắc rối nào xảy ra (trừ khi bạn thực sự mới làm quen với các nhà phát triển giao diện người dùng hoặc tài liệu tào lao). Làm sao tôi biết? Tôi viết / duy trì API REST được sử dụng bởi các nhà phát triển bên thứ ba và tôi có thể nhận được một email mỗi tuần về cách sử dụng API.

— Chris Cirefice

@ChrisCirefice Đó là một cách tiếp cận hoàn toàn khác. Đó là một loại quái thú khác để cùng phát triển một hệ thống hơn là phát triển một phần của nó. Trong trường hợp của bạn, các nhà phát triển front-end thích ứng với các quyết định của bạn, nhưng trong trường hợp của op, các quyết định phụ trợ được thực hiện song song với nhu cầu và mong muốn của front-end

— Machinarius

@Machinarius Điều đó ít nhiều đúng. Sếp của tôi chế nhạo frontend và đưa ra tất cả các quyết định về cách ứng dụng sẽ trông / chức năng. Các nhà phát triển frontend bắt đầu làm việc với bộ xương, tôi phát triển các điểm cuối API cần thiết trong phần phụ trợ và các anh chàng frontend sau đó cắm các lệnh gọi API để có được dữ liệu song song. Điều này được thực hiện trên cơ sở hàng tuần, vì vậy tôi không thấy nhiều sự khác biệt trong trường hợp của mình và nó vẫn hoạt động tốt. Các nhà phát triển riêng biệt đang làm việc trên các khía cạnh khác nhau song song, mặc dù điều đó rõ ràng không được đề cập trong bình luận trước đây của tôi.

— Chris Cirefice

Nhóm của chúng tôi có một người trực tiếp, một anh chàng viết và duy trì các dịch vụ, hai người đi trước, hai người làm việc trên phiên bản di động, và trưởng nhóm, cũng là ông chủ của chúng tôi, người chịu trách nhiệm làm cho mọi thứ hoạt động. Chúng tôi hầu như không chạm vào bất kỳ mã nào ngoài khu vực của họ. Các vấn đề giao tiếp là có thật, như với bất kỳ nhóm nào, nhưng việc chia tách nhóm sẽ không thành vấn đề, vì chúng tôi đã làm việc độc lập. Cảm ơn câu trả lời của bạn, vì nó đã cho tôi một cái nhìn sâu sắc để hiển thị với trưởng nhóm.

— Bạc

Trong mắt tôi, việc phân chia kho lưu trữ phụ thuộc rất nhiều vào mục tiêu của bạn và các công cụ bạn đang sử dụng.

Ví dụ: nếu bạn đang viết ứng dụng web Ruby on Rails mà không có API công khai (hoặc riêng tư) mà giao diện của bạn sẽ sử dụng (ví dụ như AJAX), thì tôi thực sự không thấy cách bạn có thể chia kho lưu trữ mà không cần gây đau đầu lớn cho đội của bạn. Khung Rails thực sự hoạt động tốt nhất với kiến trúc kiểu nguyên khối trong trường hợp đó.

Tuy nhiên, nếu bạn có kế hoạch viết API bằng Rails hoặc Node.js, nhưng muốn frontend của bạn được viết bằng Ember.js hoặc một cái gì đó khác, thì sẽ rất hợp lý khi chia kho lưu trữ. Điều tương tự cũng áp dụng nếu dữ liệu ứng dụng web của bạn sẽ được chia sẻ trong tương lai bởi các khách hàng khác (như thông qua ứng dụng Android / iOS). Nếu bạn dự định viết một API sẽ được nhiều khách hàng sử dụng, hãy chia repo của bạn. Một số người sẽ lập luận rằng thậm chí tách API hoàn toàn sang một ứng dụng khác hoàn toàn là một ý tưởng tồi, một điều mà tôi hoàn toàn không đồng ý (và dường như đó là lý do chính đáng !

Tách kho lưu trữ nếu bạn đã lên kế hoạch phá vỡ ứng dụng web như tôi mô tả là tùy chọn hợp lý duy nhất. Tuy nhiên, hãy nhớ rằng vì mọi người sẽ khó duyệt mã của nhau hơn, bạn cần đảm bảo rằng bạn có khả năng giao tiếp tuyệt vời , nhưng thậm chí quan trọng hơn là tài liệu . Ví dụ, nếu không ghi lại API, hai nhóm khác của bạn sẽ rất tức giận vì nhóm API không ghi lại kiến trúc và nhóm API của bạn sẽ tức giận vì mọi người cứ hỏi họ câu hỏi. Điều này thậm chí còn đúng hơn đối với các đội từ xa .

Vì vậy, tất cả phụ thuộc vào cách bạn muốn cấu trúc ứng dụng ở nơi đầu tiên. Nếu bạn đang xây dựng một ứng dụng web nguyên khối (và bạn biết hoặc chắc chắn rằng nó sẽ chỉ là một ứng dụng web ), thì hãy có một kho lưu trữ. Nếu bạn dự định tạo ra những thứ như microservice hoặc API REST được sử dụng bởi nhiều khách hàng (hoặc bạn đang lập kế hoạch này cho tương lai ), hãy chia lại repo.

— Chris Cirefice
nguồn

Một repo duy nhất không phải là một nguyên khối. Các lớp vật lý và logic có thể được lưu trữ trong các repos riêng biệt, nhưng chúng không phải như vậy. Một repo duy nhất có thể chứa API phụ trợ cũng như các lớp khác. Gánh nặng của truyền thông (tài liệu là một phần của giao tiếp) không nhiều hơn hoặc ít hơn với một repo lớn hoặc một vài repos nhỏ. Đó là quan điểm của tôi - repos không thành vấn đề. Vấn đề là làm thế nào nhóm / nhóm của bạn nghĩ về các vấn đề và làm việc cùng nhau để giải quyết chúng.

— Scant Roger

Chúng tôi có các ứng dụng đã được tách ra trong các thực thể riêng biệt. Các phụ trợ và các dịch vụ là ở một bên. Mặt trước chỉ tiêu thụ các dịch vụ thông qua khách hàng. Front enders của chúng tôi chỉ biết làm thế nào các dịch vụ hoạt động. Nhóm của chúng tôi có một backender, một anh chàng để viết các dịch vụ, hai front end và hai anh chàng làm việc trên phiên bản di động và họ hầu như không chạm vào bất kỳ mã nào ngoài khu vực của họ.

— Bạc