Nó có thể hữu ích để xây dựng một ứng dụng bắt đầu với GUI không?

Xu hướng thiết kế và phát triển ứng dụng dường như bắt đầu từ "ruột": tên miền, sau đó truy cập dữ liệu, sau đó là cơ sở hạ tầng, v.v. GUI dường như thường đến sau trong quá trình này. Tôi tự hỏi nếu nó có thể hữu ích để xây dựng GUI trước ...

Lý do của tôi là bằng cách xây dựng ít nhất một GUI nguyên mẫu, bạn sẽ hiểu rõ hơn về những gì cần xảy ra đằng sau hậu trường, và vì vậy, ở một vị trí tốt hơn để bắt đầu làm việc trên miền và mã hỗ trợ.

Tôi có thể thấy một vấn đề với thực tiễn này là nếu mã hỗ trợ chưa được viết, sẽ không có nhiều thứ cho lớp GUI thực sự làm. Có lẽ việc xây dựng các đối tượng giả hoặc các lớp vứt bỏ (hơi giống như được thực hiện trong thử nghiệm đơn vị) sẽ cung cấp vừa đủ nền tảng để xây dựng GUI trên ban đầu.

Đây có thể là một ý tưởng khả thi cho một dự án thực sự? Có lẽ chúng ta có thể thêm GDD (GUI Driven Development) vào từ viết tắt ổn định ...

Xây dựng các nguyên mẫu GUI nhanh là một ý tưởng tốt và tôi đã nghe nói nó được sử dụng trong nhiều dự án. Phản hồi sớm là có giá trị thực sự. Tuy nhiên, nó có những nguy hiểm:

• Sẽ rất hấp dẫn (đối với người quản lý / người dùng) khi sử dụng mã nguyên mẫu hơn nữa và xây dựng ứng dụng cuối cùng trên đó, điều này có thể gây ra hậu quả lâu dài rất tệ (điều này thực sự đã xảy ra trong một trong những dự án tôi đã làm việc và nó đã dẫn đến một sản phẩm "hoạt động" với kiến ​​trúc không tồn tại và rất nhiều vấn đề đau đầu về bảo trì đối với chúng tôi)
• Đối với người dùng trung bình, GUI là ứng dụng . Do đó, một khi họ thấy một GUI có giao diện đẹp, họ có xu hướng tin rằng hầu hết các công việc thực tế đã được thực hiện, do đó họ có thể rất khó chịu với "công việc nhỏ còn lại" kéo dài quá lâu: - /

Giảm thiểu những rủi ro này đòi hỏi thảo luận tích cực và có thể giáo dục người dùng và / hoặc người quản lý của bạn.

Vấn đề tôi thấy với điều đó là mục tiêu dường như hoàn toàn lạc hậu.

"Lý do của tôi là bằng cách xây dựng ít nhất một GUI nguyên mẫu, bạn sẽ hiểu rõ hơn về những gì cần xảy ra đằng sau hậu trường, và vì vậy, ở một vị trí tốt hơn để bắt đầu làm việc trên miền và mã hỗ trợ."

Theo tôi, đây là cách sai lầm khi nhìn vào tầng lớp doanh nghiệp và cách TUYỆT VỜI để tìm một thiết kế nghèo nàn, không thể mở rộng. Một lớp dữ liệu được thiết kế tốt để thể hiện dữ liệu hoàn toàn có thể được sử dụng trong bất kỳ giao diện người dùng nào. Một lớp dữ liệu được thiết kế để hoạt động cho các nhu cầu của một UI cụ thể có thể không thích ứng với bất kỳ thứ gì khác, thậm chí không phải là các tính năng bổ sung nhỏ cho UI đó.

Kinh nghiệm với các hệ thống được thiết kế theo cách bạn đang nói về tôi dẫn đến kết luận rằng hầu hết các thiết kế sử dụng phương pháp này đều có thời gian tồn tại ngắn và / hoặc quá phức tạp. Họ cũng có xu hướng tạo ra sự ghép nối giữa UI và lớp dữ liệu không bao giờ nên có ở đó.

Độc lập của lớp dữ liệu và lớp UI phải được khuyến khích. Đây là lý do tại sao việc xây dựng lớp dữ liệu để chỉ đại diện cho toàn bộ dữ liệu thay vì nhắm mục tiêu một giao diện người dùng cụ thể chỉ đơn giản là hoạt động tốt hơn trong thời gian dài.

Xây dựng một nguyên mẫu có thể tốt cho thu thập yêu cầu và thỏa thuận, nhưng sau đó nó nên được ném đi. Không thực sự sử dụng bất cứ thứ gì từ mã nguyên mẫu trong sản phẩm thực.

Tôi nghĩ @ Péter đã đúng khi đề xuất rằng xây dựng các nguyên mẫu GUI là một ý tưởng tốt. Tôi muốn bổ sung những cạm bẫy tiềm năng trong việc cung cấp trải nghiệm người dùng theo cách ngược, nghĩa là tập trung vào bản thể học, kiến ​​trúc và cơ sở hạ tầng trước tiên và trải nghiệm người dùng ngay lập tức:

• Người dùng mà bạn đã đẩy đến cuối dòng thời gian phát triển làm mất hiệu lực ước tính dữ liệu của bạn và cách ứng dụng của bạn đang được sử dụng.
• Các thiết kế phức tạp của bạn mà bạn đã phát triển sớm chứng tỏ bản thân là những mưu mô tự thanh lọc mà cuối cùng có rất ít hoặc không sử dụng được.
• Ứng dụng của bạn có thể được đưa đến trạng thái như vậy trong đó việc cung cấp trải nghiệm người dùng kém trở thành chuẩn mực.

Bạn thực hiện can đảm và sau đó người dùng nhận được những gì xuất phát từ các giả định của bạn, trong khi bạn nên quan tâm đến những gì người dùng cần và xây dựng can đảm cho phù hợp. Tại sao mọi người dùng cách khác, chỉ đơn giản là vì bài thuyết trình mà người dùng tương tác với nhau, từ đó các hành vi của ứng dụng nổi lên một cách tự nhiên, là phần phức tạp nhất của hệ thống không bao giờ được khám phá đầy đủ hoặc mọi người chỉ cảm thấy rất hạnh phúc liên quan đến bản thân với việc xây dựng mọi thứ để tránh phải thực sự phải suy nghĩ tại sao / cái gì / cho ai đang xây dựng nó. Xây dựng một cấu trúc khổng lồ có cấu trúc âm thanh là trò chơi của trẻ em, làm cho nó đáp ứng nhu cầu chức năng (và thẩm mỹ) của mọi người là phần khó nhất.

Đối với mỗi trải nghiệm điên rồ, dòng chảy kỳ quặc, thông tin được sắp xếp kém, thiếu chức năng rõ ràng, những điều hoàn toàn sai, bất cứ khi nào bạn cầu xin "thiên tài nào đã đưa ra điều đó ?", Là một điều gì đó bị bỏ qua, phủ nhận hoặc tiết lộ người dùng là người đi đầu trong các nỗ lực phát triển.

Nói chung, mô hình nên được phát triển trước khi xem. Khi bạn có một nền tảng logic của ứng dụng của mình, bạn có thể xây dựng một hoặc nhiều khung nhìn của mô hình đó (ví dụ: bạn có thể hiển thị dữ liệu trong bảng hoặc trong biểu đồ). Thông thường, mô hình quan trọng hơn GUI. Điều này đặc biệt đúng đối với phát triển doanh nghiệp nơi GUI thường được thực hiện theo cách tiêu chuẩn.

Tuy nhiên, đôi khi GUI thực sự là phần quan trọng nhất của ứng dụng. Đôi khi bạn muốn xem xét một dữ liệu theo một cách mới lạ và cụ thể - và bạn lấy nó từ đó, sau đó phát triển mô hình. Ví dụ, CashCurve là một ứng dụng như vậy trong đó điểm nằm trong GUI, trong khi chính mô hình dữ liệu là thứ nhàm chán tiêu chuẩn mà bất cứ ai cũng có thể mô hình hóa trong vài phút. (Tuyên bố miễn trừ trách nhiệm: Tôi không liên kết với CashCurve, chỉ là một người dùng rất hài lòng.)

Điều này cũng phù hợp để thiết kế các dịch vụ web hoặc các API khác - chỉ có ở đó nó được gọi là thiết kế " hợp đồng đầu tiên ".

Vì vậy, đối với tất cả mọi thứ, không có quy tắc nào là thiết kế đầu tiên; đôi khi nó là mô hình và đôi khi là GUI. Theo nguyên tắc thông thường, tôi sẽ đi với "thiết kế phần quan trọng nhất trước tiên."

Có những điều cần cân nhắc khi thiết kế GUI trước, chẳng hạn như người dùng có thể sẽ gặp khó khăn khi hiểu rằng ứng dụng chưa hoàn thiện khi chỉ tồn tại nguyên mẫu GUI, nhưng các câu trả lời khác đã trình bày khá rõ điều này vì vậy tôi sẽ không đi sâu vào chi tiết.

Tôi nghĩ rằng đó là một cách cực kỳ tốt để tiếp cận thiết kế ứng dụng, đặc biệt là trong môi trường phát triển nhanh. Hầu hết các dự án thành công mà tôi đã thực hiện đã bắt đầu với một nguyên mẫu mà cuối cùng đã trở thành hiện thực.

Bạn phải hiểu rằng GUI là cửa sổ vào hệ thống (ví dụ: cơ sở dữ liệu, hệ thống tập tin, v.v.). Trong tình huống mà các yêu cầu của dự án mơ hồ như một đống bùn, thì bạn sẽ không có hy vọng gì trong việc tìm ra giải pháp chính xác bằng cách bắt đầu vào phần phụ trợ. Hầu như luôn luôn, nhà phát triển phụ trợ có ý định tốt sẽ phát triển một loạt API không liên quan đến tương tác của người dùng.

Bằng cách bắt đầu trên GUI, khách hàng sẽ hiểu rõ hơn về những gì họ muốn. Khi giai đoạn này tiến triển, sự phát triển của GUI (sử dụng giả và sơ khai) tạo ra một mô hình miền. Mô hình miền này sau đó có thể được chuyển sang phần phụ trợ và các nhà phát triển phía sau có thể bắt đầu phát triển tính bền vững và logic giao dịch.

Và tại sao bạn lại muốn vứt bỏ protoype? Chúng tôi không đối phó với các sân vận động được xây dựng từ que diêm. Chỉ cần cấu trúc lại những thứ chết tiệt thành một cái gì đó tốt.

Hoàn toàn không tệ đối với tôi nếu người nhìn vào GUI hiểu rằng đó chỉ là một vỏ và các nút và quy trình theo nghĩa đen không hoạt động (ném NotImcellenceedException () ;;)) mới.

Nếu bạn sử dụng kiến ​​trúc kiểu MVC, tôi sẽ không thấy bất kỳ vấn đề bảo trì hoặc xây dựng nào trong tương lai vì "Chế độ xem" hoàn toàn không xác định bất kỳ điều gì trong số đó. "Bộ điều khiển" và "Mô hình" có thể đến sau với bất kỳ cơ sở hạ tầng nào bạn yêu cầu cho khả năng mở rộng / nhu cầu thiết kế, v.v.

Đối với quản lý, vẽ cho họ một biểu đồ hình tròn lớn với 3 phần, gắn nhãn "M", "V" và "C". Cho V khoảng 20% ​​và giải thích phần còn lại của chiếc bánh là "TBC";).

Trong bất kỳ hệ thống có kích thước hợp lý nào, những gì cần xảy ra đằng sau hậu trường đều liên quan một cách lỏng lẻo đến giao diện của GUI. GUI sẽ chỉ cung cấp cho bạn một số yêu cầu. Thường có nhiều thành phần không có GUI.

Sau khi hệ thống được phát triển các giao diện bổ sung (bao gồm GUI mới) có thể được yêu cầu. Hiểu và thực hiện các yêu cầu kinh doanh là rất quan trọng để điều này thành công.

Trường hợp thiết kế GUI và các cơ chế Đầu vào và Đầu ra khác có thể giúp xác thực mô hình. Các thuộc tính không bao giờ là đầu ra, có thể không được yêu cầu. (Có thể có lý do để giữ chúng, nhưng chúng có thể sẽ là yêu cầu kiểm toán hoặc điều tiết.)

Như những người khác đã đề cập, một khi bạn có GUI hoạt động, nhiều khách hàng sẽ nghĩ rằng bạn đã hoàn thành. Tuy nhiên, bạn có thể không có cơ sở hạ tầng đằng sau nó. Các nguyên mẫu giấy có thể là một lựa chọn tốt để xác nhận bố cục và nội dung của GUI.

Đừng bỏ qua rằng bạn có thể cần điều chỉnh giao diện sau khi phát triển. Tôi đã nghe báo cáo về việc thay thế giao diện thanh toán không thành công cho quy trình thanh toán năm bước. Giao diện đơn giản hơn nhiều không mang lại cho người dùng cảm giác an toàn thích hợp và có tỷ lệ hoàn thành thấp hơn nhiều. Lắng nghe Speed ​​Bumps: Thành phần kỳ diệu trong tiếp thị .