Vấn đề về nhóm lựa chọn kiến ​​trúc và khung

Question

Chúng tôi đang trong quá trình lập kế hoạch viết lại một trong các ứng dụng cơ bản của chúng tôi. Nó dựa trên web và chúng tôi bị khóa vào PHP. Tuy nhiên nó không phải là một trang web 2.0. Nó gần hơn với một ứng dụng doanh nghiệp.

Điều đó không hề đơn giản. Có ít nhất 2 giao diện chính (tôi nghĩ có 4, nhưng đó là một chủ đề khác). Nó cần phải được cấu hình cao và tùy biến cao. Tôi dự kiến ​​khoảng từ 50 đến 200 lượt cài đặt mỗi năm, vì vậy việc bảo trì dễ dàng là mối quan tâm chính.

Vì vậy, sự cố có trong kiến ​​trúc. Tôi muốn làm một kiến ​​trúc cao cấp chính thức trước tiên. Trước khi bất cứ điều gì khác. Sau đó, chúng tôi sẽ chọn một khung phù hợp (một khung phù hợp với kiến ​​trúc) hoặc chọn một khung và sử dụng nó làm thư viện. Tôi cảm thấy phương pháp này sẽ đảm bảo một hệ thống khả thi trong thời gian dài (vì ít nhất là kiến ​​trúc đầy đủ được xem xét)

Tuy nhiên, phần còn lại của nhóm muốn chọn khung (họ muốn sử dụng YII) trước và bỏ qua kiến trúc cấp cao hoàn toàn. Lập luận của họ là khuôn khổ đã làm kiến ​​trúc mức cao đầu tiên và cho phép bạn "chỉ bắt đầu viết mã".

Về cơ bản, tôi nghĩ điều này giống như đặt giỏ hàng trước con ngựa hoặc xây dựng ngôi nhà của bạn mà không có nền tảng trên đỉnh hố. Tôi biết quan điểm này là phổ biến trong những ngày sau ROR của phát triển ứng dụng nhanh chóng vì nhiều hơn có thể được thực hiện nhanh hơn. Nhưng tôi thực sự lo sợ rằng đối với một ứng dụng cốt lõi nhiệm vụ quan trọng, điều này được nhìn thấy rõ ràng ở mức tốt nhất (và không quan tâm đến điều tồi tệ nhất).

Tôi thực sự lo sợ rằng chúng tôi đang đi sai đường dẫn.

Quản lý coi tôi là nhà phát triển cấp cao. Vì vậy, về mặt kỹ thuật tôi có thể overrule hầu hết những người khác. Nhưng tôi không ở trên họ, vì vậy trong thực tế làm như vậy sẽ là xấu. Một đề cập đến rằng có một rào cản ngôn ngữ chính (họ nói tiếng Ba Lan, tôi nói tiếng Anh).

Và tôi nghĩ tôi nên đề cập đến rằng tôi thực sự không thích hầu hết các khuôn khổ RAD PHP. Không phải vì chúng xấu bởi bất kỳ phương tiện nào, nhưng bởi vì chúng có xu hướng (IMHO) thực thi tâm lý rằng kiến ​​trúc không quan trọng vì chúng làm điều đó cho bạn. Chưa kể rằng họ thường muốn bạn làm việc theo cách của họ (Rails nổi tiếng với điều đó) chứ không phải là một cách có ý nghĩa cho dự án trong tầm tay. Vì vậy, tôi thường chỉ sử dụng một khung làm bộ thư viện. Sử dụng các lớp khi chúng có ý nghĩa, và xây dựng của riêng tôi khi các yêu cầu dự án ra lệnh như vậy).

Vì vậy, câu hỏi của tôi như sau:

1. Am Tôi có ngay trong mối quan tâm của tôi? Hay họ đúng và tôi chỉ phản ứng quá mức?
2. Nếu tôi đúng, có lời khuyên nào về cách xử lý tình huống không?
3. Làm cách nào để tôi có được đội bóng ở bên cạnh mình mà không gây ra một cuộc đột biến?

Answer 1

Bạn có thể quan tâm đến bài đăng blog gần đây của tôi: Don't Put the Cart Before the Horse nơi tôi nói về tầm quan trọng của việc xác định sự cố bạn đang cố giải quyết trước khi giải quyết bất kỳ lựa chọn kiến ​​trúc nào.

Để nhận được đội bóng ở bên cạnh bạn, có nhiều giải pháp vì có nhiều lý do đề kháng.

Tôi đề xuất sách này: Driving Technical Change: Why People On Your Team Don't Act On Good Ideas, and How to Convince Them They Should bởi Terrence Ryan. Sắp ra mắt, nhưng bạn có thể đặt mua sách điện tử beta ngay lập tức và điều này áp dụng cho sách điện tử cuối cùng khi sách sẵn sàng.

(từ chối trách nhiệm:. Tôi xem xét một dự thảo của cuốn sách đó, và nó đã được xuất bản bởi cùng một công ty người đưa ra cuốn sách của riêng tôi)

Answer 2

Tôi đang gặp rắc rối hình dung ra kiến ​​trúc cao cấp mà không cần bất kỳ thông tin chi tiết, nhưng cho những gì nó có giá trị, điều này:

Tôi muốn làm một kiến ​​trúc mức cao chính thức trước tiên. Trước bất cứ điều gì khác

nghe có vẻ khá lành mạnh với tôi. Trước khi chọn một khung công tác, cần phải rõ ràng liệu cấu trúc của nó có phù hợp với những gì bạn cần làm hay không mà không phải bẻ cong nó đến mức nó không còn là khung công tác nữa.

Với số cách ... Tôi chắc chắn những người khác đủ điều kiện để trả lời hơn tôi. Tuy nhiên, nếu thời gian là điều cốt yếu, và phần lớn các đội muốn đi "chúng ta hãy bắt đầu ngay lập tức" tuyến đường, tôi sẽ cố gắng thuyết phục họ làm ít nhất một số lượng nhỏ các phiên kiến ​​trúc đầu tiên - và nếu nó chỉ một hoặc hai buổi chiều.

Nếu bạn không thực sự có thẩm quyền đối với họ (và ngay cả khi bạn có), hãy yêu cầu họ hài lòng bạn trong một khoảng thời gian giới hạn. Theo kinh nghiệm của tôi, những thiếu sót và vấn đề kiến ​​trúc có xu hướng xuất hiện khá nhanh khi bạn vào được nó ("Chúng ta cần phải làm xyz. Làm thế nào để chúng ta làm điều này trong Framework X?"). Một phiên họp chuyên sâu về các kịch bản mô phỏng (và các vấn đề) có thể làm cho mọi người muốn suy nghĩ hai lần về nền tảng họ chọn.

Answer 3

Tôi muốn nói cả hai đều đúng. Xem xét kiến ​​trúc là tốt. Nhưng các kiến ​​trúc sư thường có khuynh hướng làm quá nhiều thứ. Việc các nhà phát triển buộc tội các Kiến trúc sư đang sống trong một tháp Ngà không phải là điều hiếm thấy, trong khi họ đang ở trong các chiến hào. Tuy nhiên, trong một rãnh là khá thấp xuống mặt đất, do đó, các nhà phát triển thường không nhìn thấy rừng cho cây, có thể dẫn đến kiến ​​trúc ad-hoc không mong muốn hoặc các giải pháp đảo không kết nối quá tốt.

Đối với các khung cung cấp kiến ​​trúc mức cao hơn, vâng, vâng. Họ làm. Nhưng điều đó không có nghĩa đó là kiến ​​trúc bạn cần. Những điều bạn sẽ tìm thấy trong các khuôn khổ (hy vọng) được mô hình hóa sau khi các mẫu thiết kế đã được thiết lập. Các mẫu thiết kế là các giải pháp được đề xuất cho các vấn đề chung. Nếu bạn không cần phải giải quyết những vấn đề này, bạn không sử dụng một khung giải quyết các vấn đề này. Đó là sự lựa chọn sai lầm. Bây giờ, đó là khá chung chung, nhưng bạn có được ý tưởng.

Lời khuyên của tôi sẽ không lạm dụng vị trí nhà phát triển cấp cao của bạn và đưa ra quyết định cho họ. Tìm một thỏa hiệp. Tham gia họ trong quyết định nhưng mong đợi họ thảo luận. Tôi không biết môi trường làm việc tại chỗ của bạn, nhưng có thể xem xét việc áp dụng một số quy trình nhanh, như Scrum. Có thể làm cho một số mã thám hiểm đầu tiên với các khuôn khổ khác nhau để xem những gì là phù hợp hơn. Tốt hơn là thất bại với một khuôn khổ sớm hơn để nhận ra đó là con ngựa sai cuối cùng.

Answer 4

Trạng thái bạn đang ở, bạn đều biết bạn cần xây dựng một tòa nhà 40 tầng. Nhưng bạn không bao giờ xây dựng cấu trúc thượng tầng trên cát. Nhận được sự đồng thuận chỉ trì hoãn mọi thứ. Cách tiếp cận tốt nhất là để mọi người xây dựng một bằng chứng về khái niệm trong thời gian ngắn nhất có thể với nhiều tính năng như bạn có thể nhận được từ sản phẩm dự kiến ​​sử dụng cùng một đường cơ sở/thời hạn. Sau đó, có một nhóm đánh giá độc lập để xem xét các phương pháp tiếp cận của bạn. Sau đó đưa ra quyết định. Khung và lưới chỉ là cấu trúc hỗ trợ cho nền tảng của bạn.

Answer 5

Có bất kỳ nhà phát triển nào khác đã triển khai một ứng dụng trong YII tương tự như ứng dụng cần xây dựng ngay bây giờ không? Nếu không thì bạn ít nhất có một số cơ sở để đẩy lùi và a) tìm hiểu điểm mạnh và điểm yếu của YII là gì (yêu cầu họ nói cho bạn) và b) cách đo lường này theo yêu cầu của dự án của bạn.Nếu bạn đang sử dụng một khung công tác mà bạn đã quen thuộc đã có một hồ sơ theo dõi đã được chứng minh để xây dựng loại ứng dụng mà bạn muốn, nhưng với một khung công tác mới (không quen thuộc với nhóm của bạn), bạn có thể sử dụng một khung công tác mới. nó hoàn toàn có ý nghĩa để đánh giá đầu tiên, với ít nhất một nguyên mẫu xương, như là một phần của sự tích cực của bạn - đặc biệt nếu đó là một ứng dụng quan trọng, thương mại, nhiệm vụ. Hãy chắc chắn rằng nó có thể đáp ứng tất cả các bạn phải có yêu cầu kinh doanh.

Về đẩy lùi, bạn luôn có thể yêu cầu doanh nghiệp đặt câu hỏi cho nhóm phát triển "cho chúng tôi biết (lý do) tại sao chúng tôi sử dụng khung này để xây dựng ứng dụng quan trọng của chúng tôi".

Answer 6

Bạn và nhóm của bạn không đồng ý, nhưng cả hai đều đúng. Bạn đi viết một số tài liệu, và để cho họ bắt đầu cắt răng của họ trên một khuôn khổ như CakePHP hoặc bất cứ điều gì. Lý tưởng nhất, bạn sẽ nhận được một số kinh nghiệm với nhiều hơn một khuôn khổ. Điều này sẽ cho phép bạn thực hiện các lựa chọn có kiến ​​thức hơn về việc chọn nền tảng của bạn.

Lý do bạn muốn thực hiện một loạt công việc thiết kế trước hết là rất tốt - bạn cần phải biết mình đang làm gì trước khi thực hiện. Nhưng nó cũng khá hợp lệ đối với các nhà phát triển khác để bắt đầu học và sử dụng các khung công tác. Kiến thức đó sẽ giúp bạn đưa ra quyết định và cũng sẽ cho phép nhóm của bạn bắt đầu tạo ra kết quả nhanh hơn.

Tôi khuyên bạn không nên căng thẳng quá nhiều về việc đặt giỏ hàng trước con ngựa. Hãy suy nghĩ của vài tuần đầu tiên như giáo dục chính mình, và tạo mẫu, với mục đích ném kết quả ban đầu của bạn đi. Phần khó nhất trong việc sử dụng một khung hoặc phương pháp mới là học nó, trở nên thành thạo đủ để bạn chủ yếu suy nghĩ về ứng dụng của mình chứ không phải là phương tiện mà bạn đang làm việc. Người của bạn có thể bắt đầu với điều đó trong khi bạn suy ngẫm về các vấn đề thiết kế .

Bạn thậm chí có thể tìm ra một số mô hình dữ liệu sớm và cho phép họ bắt đầu tạo các trang giao diện người dùng cho những mô hình đó. Tất nhiên bạn sẽ cần phải thay đổi chúng khi bạn tinh chỉnh thiết kế, nhưng làm thế nào dễ dàng để thực hiện những thay đổi như vậy là một phần của những gì làm cho một khuôn khổ tốt.

Nguy cơ tạo mẫu là khuynh hướng tự nhiên của mọi người để gắn bó với thứ gì đó "đang hoạt động" và không muốn loại bỏ nó. Nhưng cũng có những rủi ro khi làm quá nhiều công việc thiết kế trong phần tóm tắt mà không có bất cứ điều gì cụ thể để tương tác và sinh ra ý tưởng.

Tôi sẽ không đi sâu vào một luận thuyết về Thác so với lặp lại. Nhưng tôi khuyên bạn nên mở ra sự nhiệt tình của người dân để lặn ngay, và để họ vượt qua bạn khi thử và học một vài khung công tác trong khi bạn làm công việc thiết kế. Sau đó, bạn có thể đến với nhau như một nhóm, thảo luận về kiến ​​trúc của bạn, và có một cuộc thảo luận mang tính giáo dục hơn với nhau về khung mà bạn muốn sử dụng.