Khi thiết kế một hệ thống, cách tốt nhất là phục vụ thiết kế xung quanh khung bạn sẽ sử dụng?

37

Khi phát triển một hệ thống hoặc ứng dụng mà bạn dự định sử dụng với một khung nhất định, cách tốt nhất là thiết kế hệ thống mà không có khung, hoặc tốt hơn là thiết kế hệ thống với tư duy "tốt, khung sẽ có thời gian dễ dàng hơn Với cái này".

development-process  systems 
— Robert Pounder
nguồn
4
Bạn đang nói về loại khung nào? Bạn có nghĩa là một số khung cụ thể cho doanh nghiệp thích hợp được thiết kế để giải quyết các vấn đề rất cụ thể về tên miền cho một ngành cụ thể? (ví dụ y tế, hạt nhân, quốc phòng, hàng không, v.v.). Hay bạn đang nói về các khung công tác chung được thiết kế để giải quyết các vấn đề kỹ thuật?
— Ben Cottrell
1
các khung mục đích chung được thiết kế để giải quyết các vấn đề kỹ thuật
— Robert Pounder
2
Quy mô nhỏ vì thiếu thời gian (tôi đang làm việc, có thể giải thích sau): Tôi đang viết một hệ thống tạo email dựa trên các thiết kế. - Nếu tôi viết bài này bằng Laravel, có lẽ tôi sẽ sử dụng "lưỡi dao" động cơ tạo khuôn mẫu của họ để thiết kế các email, điều này sẽ giúp việc thiết kế hệ thống đơn giản hơn rất nhiều về mặt dòng chảy. Tuy nhiên, tôi sẽ phải viết về một công cụ tạo khuôn mẫu nếu tôi đang thực hiện nó vanilla PHP hoặc tìm một hệ thống tạo khuôn thay thế phù hợp khác. Nó sẽ thêm vào quá trình thiết kế, mà câu hỏi được đề cập quá.
— Robert Pounder
3
Câu hỏi này sẽ tạo ra một loạt các câu trả lời khác nhau vì cả "khung" và "thiết kế" đều là những từ bị quá tải với nhiều nghĩa trong ngành của chúng tôi. Hơn nữa, ngay cả đối với một định nghĩa duy nhất về khung là "các khung mục đích chung được thiết kế để giải quyết các vấn đề kỹ thuật", nó sẽ phụ thuộc vào khung cụ thể - một số khung được đánh giá cao hơn các khung khác.
— stannius
1
Sẽ là quá tệ khi bị xe buýt đâm vào trong khi đang suy nghĩ cố gắng thiết kế một phương tiện giao thông công cộng có bánh xe.

Câu trả lời:

51

Thiết kế của bạn phải đáp ứng nhu cầu của khách hàng càng sát càng tốt. Hãy nhớ rằng thiết kế bao gồm những điều nhỏ như:

  • Kinh nghiệm người dùng
  • Chức năng
  • Làm thế nào các phần của ứng dụng của bạn giao tiếp (với chính nó hoặc các thực thể bên ngoài)

Không ai trong số những điều này nên được quyết định bởi khuôn khổ. Nếu rõ ràng rằng bạn sẽ chiến đấu với khung của mình để hoàn thành các mục tiêu này, thì bạn chọn một khung mới sẽ giúp bạn hoàn thành các mục tiêu đó trước khi bạn bắt đầu viết mã.

Khi bạn đã chọn một bộ công cụ thích hợp (khung là một công cụ), thì tôi khuyên bạn nên sử dụng các công cụ theo cách chúng được thiết kế để sử dụng. Bạn càng đi chệch khỏi thiết kế khung, bạn càng tăng thời gian học tập cho nhóm của mình và khả năng xảy ra sự cố sẽ càng cao.

Nói ngắn gọn

  • Thiết kế cho người dùng của bạn
  • Chọn các công cụ thích hợp để thực hiện thiết kế của bạn
  • Sử dụng các công cụ của bạn theo cách chúng được thiết kế để sử dụng

Suy nghĩ thêm:

Sau hơn 20 năm công nghệ phần mềm và sử dụng một số khung công tác, tôi đã học được một vài bài học. Tất cả các khung là một con dao hai lưỡi: cả hai đều hạn chế và cho phép. Vấn đề với việc quyết định khuôn khổ của bạn trước khi bạn nhìn vào 3 điều tôi đã đề cập ở trên là bạn có thể đang làm tổn hại đến trải nghiệm người dùng tốt cho một người tầm thường (tốt nhất). Hoặc bạn có thể bị buộc phải đi chệch khỏi thiết kế khung để thực hiện một số chức năng cụ thể.

— Berin Loritsch
nguồn
3
Sau đó, bạn cần phải thực hiện một số cuộc đàm phán với khách hàng. Giải thích những gì bạn có thể và không thể làm với các ràng buộc mà họ đã áp đặt. Đề xuất làm thế nào điều đó có thể thay đổi nếu bạn chọn khung X. Họ có thể không sẵn sàng thay đổi và sẵn sàng sống với trải nghiệm xuống cấp. Hoặc họ có thể quyết định rằng bạn biết những gì bạn đang làm và tin tưởng bạn. Điều đó phụ thuộc vào khách hàng. Vào cuối ngày, bạn quản lý kỳ vọng của họ.
— Berin Loritsch
4
Dường như có một số nhầm lẫn giữa các cấp thiết kế khác nhau ở đây: thiết kế hệ thống và thiết kế chi tiết. Đối với tôi, câu hỏi này là về thiết kế chi tiết (phương thức thực hiện) thay vì hệ thống (giao diện, đồng thời, khối lượng dữ liệu, giao diện người dùng, loại người dùng).
— Gusdor
2
Nếu câu hỏi xoay quanh "thiết kế kỹ thuật", thì ngôn ngữ và HĐH có thể có một số suy luận trong thiết kế. Nhưng vẫn vậy, thiết kế không được thực hiện. Nếu bạn đang nghĩ về các khả năng của Framework, thì đó không phải là thiết kế, đó là ý nghĩa. Nếu bạn căn cứ vào các quyết định thiết kế của mình trên các khung công tác, hãy chuẩn bị tinh thần cho việc chịu đựng điểm yếu của nó. Và khi điểm yếu đáp ứng yêu cầu, bạn có một vấn đề rất lớn. Các công ty lớn nhất đã không xây dựng khuôn khổ của họ cho niềm vui.
— Laiv
1
@Laiv Nhận xét tuyệt vời! Thực sự, đó là "một số và một số". Cả súng bắn đinh và súng bắn vít đều có thể buộc chặt đồ đạc, một loại có thể đảo ngược hơn loại kia và cũng hoạt động chậm hơn và phức tạp hơn. Mỗi sự lựa chọn mọi người đưa ra là không thể tránh khỏi một sự đánh đổi. Bạn trả tiền của bạn và bạn có cơ hội của bạn.
1
@RobertPounder, Đây là một công cụ phù hợp với giải pháp cần được quyết định trong khi thiết kế hệ thống. Tôi hiểu làm thế nào các khung có thể ảnh hưởng đến thiết kế, nhưng họ không nên ra lệnh cho nó.
— Berin Loritsch
27

Các khung ảnh hưởng một cách tự nhiên đến việc thiết kế các mô-đun và hệ thống con cụ thể (như giao diện người dùng GUI). Như câu trả lời khác đã đề cập, bạn sẽ có một khoảng thời gian khó khăn nếu bạn thấy mình chiến đấu chống lại (các) khuôn khổ đã chọn.

Tuy nhiên, rộng hơn, bạn nên tránh để cho bất kỳ khuôn khổ hoặc công nghệ nào ra lệnh hoặc điều khiển "bức tranh lớn" của kiến ​​trúc hệ thống tổng thể của bạn. Hầu hết các khung ứng dụng cho mục đích chung không khuyến khích điều này, vì vậy nếu bạn thấy mình viết toàn bộ hệ thống của mình xung quanh một khung thì có lẽ bạn đang làm điều gì đó mà các tác giả của khung đó không có ý định.

Bạn có thể sẽ sử dụng nhiều khung khác nhau để giải quyết các vấn đề khác nhau; khi hệ thống của bạn trở nên phức tạp hơn, bạn cần cẩn thận để không xây dựng The Big Ball Of Mud . Nếu có thể, hãy giữ cho hệ thống của bạn được mô đun hóa và kết nối lỏng lẻo. Một số khung công tác có thể được giữ tốt hơn đằng sau sự trừu tượng bằng cách viết các trình bao bọc và bộ điều hợp 'ẩn' các luồng công việc dành riêng cho Khung khỏi các thành phần khác. Bộ công cụ GUI có xu hướng chỉ phục vụ chức năng GUI phía trước, vì vậy các mô-đun GUI đó nên được tránh xa phần còn lại của hệ thống.

Các khung công tác chung (như khung UI, khung lớp dữ liệu, v.v.) không tồn tại để quy định kiến ​​trúc hoàn chỉnh của hệ thống của bạn - nhiều nhất họ có thể quy định thiết kế của một thành phần hoặc mô-đun; ví dụ, một số công nghệ GUI hướng đến các mẫu MV * cụ thể.

Kiến trúc tổng thể của hệ thống của bạn nên được điều khiển chủ yếu bởi các yêu cầu kinh doanh của bạn . Bạn có thể thấy mình dựa nhiều vào một công cụ cụ thể (ví dụ: công cụ phần mềm trung gian nhắn tin hoặc khung ORM) để gắn kết mọi thứ lại với nhau, nhưng nếu bạn đã gói gọn khung trong một bản tóm tắt, chẳng hạn như lớp 'dịch vụ', bạn Sẽ ít có khả năng thấy mình bị hạn chế bởi khuôn khổ đó khi bạn gặp phải những hạn chế của nó.

Cố gắng ghi nhớ những điều sau đây cho thiết kế bức tranh lớn của bạn:

— Ben Cottrell
nguồn
Đôi khi, có vẻ như một số tác giả khung không bận tâm đến việc người dùng của họ viết mã ứng dụng chặt chẽ cùng với khung.
— ĐẾN TỪ
2
@COMEFROM - Việc liên kết chặt chẽ mã của bạn với một khung sẽ được các nhà phát triển khuyến khích vì họ cho rằng bạn đã chọn khung của họ để giải quyết các vấn đề tương tự mà họ đã thiết kế cho nó ngay từ đầu.
— JeffO
Bạn đã đi lạc đề một chút, từ nguyên tắc thiết kế đến nguyên tắc mã hóa, nhưng tôi hiểu ý chính của bạn, nếu yêu cầu kinh doanh là một khuôn khổ nhất định được sử dụng thì sao? (nghĩ rằng việc thuê ngoài công ty và các nhà phát triển nội bộ chỉ biết một ngôn ngữ) Tôi nghĩ rằng tôi nên làm cho điều này rõ ràng hơn trong bài viết gốc.
— Robert Pounder
1
@RobertPounder Điểm thực sự mà tôi đang cố gắng đạt được (có lẽ không tốt lắm) là đôi khi có xu hướng mọi người sử dụng các khung cụ thể làm 'nền tảng' cho toàn bộ ứng dụng của họ - điều này chắc chắn dẫn đến logic kinh doanh và khác mã không liên quan được kết hợp không phù hợp với khung đó - ví dụ logic kinh doanh được kết hợp với các điều khiển UI chỉ vì nó nhanh chóng vào thời điểm đó. Thật dễ dàng để làm điều đó, vì vậy đó là điều cần cảnh giác
— Ben Cottrell
2
Tôi phải không đồng ý với @nocomprende ở đây; không phải tất cả các yêu cầu trong tương lai đều có thể dự đoán được, nhưng đôi khi các hệ thống được viết lại đơn giản vì phần mềm trước đó quá khó để mở rộng / bảo trì .
— SeldomNeedy
7

Có, bạn nên bám sát nhất có thể vào những gì khung "bảo" bạn làm.

Lý do đơn giản là bạn càng bám sát cách "suy nghĩ" của khung, bạn càng dễ nói chuyện với các nhà phát triển khác về các vấn đề / ý tưởng của bạn cũng sử dụng khung đó.

Bạn tăng khả năng tương tác và dễ sử dụng cho những người khác sử dụng nó sau này, bạn sẽ hiểu và kết hợp các hướng dẫn hoặc giải pháp chung tốt hơn nếu bạn tuân thủ triết lý cơ bản của bất cứ điều gì bạn đang sử dụng.

Lý do chính đáng duy nhất tôi có thể nghĩ về lý do tại sao bạn sẽ "phá vỡ" khung là bạn hoàn toàn cần thứ gì đó không thể cung cấp cho cấu hình / ứng dụng nguyên tắc "mặc định" của nó. Nhưng sau đó, nó có thể không phải là khuôn khổ phù hợp để bắt đầu.

Về cơ bản, điều này có thể áp dụng cho các quyết định khác là tốt. Bạn nên sử dụng ngôn ngữ bạn đang sử dụng gần như dự định sẽ được sử dụng, bởi vì nó giúp mọi việc dễ dàng hơn nếu bạn nói cùng ngôn ngữ với mọi người khác.

— Chi cục Kiểm lâm
nguồn
Có thể bạn nên xem lại câu trả lời của mình do những thay đổi của câu hỏi. Câu trả lời của bạn thực sự không trả lời câu hỏi của OP.
— Laiv
1
@Laiv Tôi không thấy cách nó không trả lời câu hỏi, mặc dù nó có thể không phù hợp với ý kiến ​​của bạn về chủ đề này, nó vẫn là một câu trả lời. Bạn được chào đón nhất để viết câu trả lời của riêng bạn để hiển thị bản chất mâu thuẫn của chủ đề được đề cập.
— FP
Xin lỗi nếu tôi không giải thích rõ bản thân mình. Tôi không thông thạo tiếng Anh như tôi muốn. Tôi chỉ muốn nói rằng, IMO, câu hỏi và câu trả lời của bạn nói về những điều khác nhau. Nếu bạn nghĩ rằng họ không, nó ổn. Tôi sẽ không tranh luận rằng. Đó là nó.
— Laiv
1
Điều này là hoàn toàn nó. Nó tương tự như cách các Ngôn ngữ cụ thể miền và các ý tưởng tương tự hoạt động. Sản phẩm của bạn được định hình bởi công cụ (Khung) không phải theo cách khác. Khung "thắng". Nếu bạn không thể kết hôn với nó, sau đó chọn một người khác. (Gợi ý: không có Khung lý tưởng . Chỉ cần nói '.)
1
Thiết kế của bạn sẽ ảnh hưởng đến khung bạn chọn (nếu có!), Chứ không phải theo cách khác.
— RubberDuck
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.