Bạn lập kế hoạch ứng dụng Rails của mình như thế nào?

Question

Tôi đang bắt đầu ứng dụng Rails cho khách hàng và đang cân nhắc tạo bản đồ tư duy hoặc chuyển thẳng đến thông số kỹ thuật của Cucumber.

Bạn lập kế hoạch ứng dụng Rails của mình như thế nào?

Là câu hỏi bổ sung, giả sử bạn cũng bắt đầu bằng dưa chuột, tại thời điểm nào bạn sẽ viết bài kiểm tra Đơn vị? Trước khi đáp ứng các thông số kỹ thuật?

Answer 1

Tôi không nghĩ rằng chỉ viết các tính năng dưa chuột làm thông số kỹ thuật là một ý tưởng hay. Viết mã thử nghiệm mà không thể kiểm tra nó vượt qua các lỗi dẫn đến lỗi trong các thử nghiệm và tăng thời gian bạn cần sửa chúng sau này.

Vì vậy, tôi muốn làm như sau:

• Viết một số bản đồ tư duy. Nhưng hãy giữ nó đơn giản với những ý tưởng chính của dự án.
• Bắt đầu viết các bài kiểm tra và viết mã vào thời gian rảnh rỗi (viết một bài kiểm tra, vượt qua bài kiểm tra, viết bài kiểm tra khác, ...).

Vì vậy, bạn sẽ viết thông số kỹ thuật của mình trong khi lái xe ứng dụng. Giữ cho nó sạch sẽ nhưng cũng nhanh nhẹn và có thể thay đổi một số ý tưởng ở giữa dự án.

Answer 2

Tôi bắt đầu với các bản phác thảo giao diện người dùng và sau đó tiến tới các mô hình HTML. Khi thiết kế giao diện người dùng được hoàn thành, tôi có thể xác định các tài nguyên RESTful trong ứng dụng và các mối quan hệ của chúng.

Answer 3

Tôi đã có quy trình 6 bước.

1. Tôi muốn tìm ra mối quan hệ và sử dụng mô hình trước khi thực hiện bất kỳ điều gì. Nói chung, tôi cố gắng xác định các mô hình thành các đơn vị có chứa các khối thông tin mạch lạc. Thông thường, điều này bắt đầu bằng cách xác định các tài nguyên trực giao mà ứng dụng của tôi sẽ cần (Người dùng, Bài đăng, v.v.). Sau đó tôi tìm ra thông tin mà mỗi tài nguyên đó cần (các thuộc tính) và có khả năng cần (các liên kết), và thông tin đó sẽ được vận hành như thế nào (các phương pháp), từ đó tôi xác định một tập hợp các quy tắc để điều chỉnh tính thống nhất tài nguyên (các xác nhận hợp lệ)).

   Tôi thường lặp lại thiết kế của mình một vài lần vì hành động xác định các mô hình khác thường làm cho tôi suy nghĩ lại những gì tôi đã thực hiện. Một khi tôi có một thiết kế mô hình tôi thích, tôi sẽ bắt đầu tái cấu trúc hoặc chuyên (subclassing) mô hình để làm rõ thiết kế.

2. Tôi viết di chuyển và tạo bộ xương cho các kiểu máy của mình. Tôi thường sẽ không viết các bài kiểm tra cho đến khi tôi có bản thảo đầu tiên về các phương pháp và xác thực được thực hiện. Nó không phải luôn luôn rõ ràng như thế nào để thực hiện những điều cho đến khi cho nó một số suy nghĩ vừa phải.

3. Tiếp theo là bộ thử nghiệm. Không quan trọng những gì tôi sử dụng để viết các bài kiểm tra, miễn là tôi có thể chắc chắn phụ trợ là lành mạnh.

4. Đây là khi tôi kết hợp với luồng điều khiển. Điều gì xảy ra với yêu cầu thành công? Yêu cầu không thành công? Hành động điều khiển nào sẽ liên kết với người khác? Thông thường có một ánh xạ 1-1 giữa các bộ điều khiển và các mô hình (không tính các lớp con của mô hình), tôi thường gặp phải các tình huống mà tôi cần phải thực hiện trên nhiều kiểu mô hình, vì vậy tôi có thể tạo một bộ điều khiển mới. Tùy thuộc vào mức độ phức tạp của ứng dụng của tôi, tôi có thể mô hình luồng như một máy trạng thái.

5. Cuối cùng tôi tạo chế độ xem.Tôi bắt đầu bằng cách phác thảo giao diện người dùng dựa trên đó bị ảnh hưởng nặng nề bởi các mối quan hệ và thuộc tính của mô hình của tôi. Tóm tắt các phần phổ biến, sau đó viết các khung nhìn.

6. Đánh dấu giao diện người dùng. Tôi tạo một CSS và bắt đầu thay thế các liên kết bằng các cuộc gọi từ xa hoặc thậm chí chỉ cần javascript khi thích hợp.

Tôi có thể xen kẽ các bước 2 và 3. Tôi thấy rất dễ dàng để viết bài kiểm tra ngay sau khi tôi viết mã cần kiểm tra. Đặc biệt là bởi vì tôi thường thử nghiệm mọi thứ trong một bàn điều khiển như tôi viết, và một nửa thử nghiệm được viết bằng cách dán từ giao diện điều khiển.

Tôi cũng có thể chia nhỏ các bước 4 và 5 cho mỗi mô hình/bộ điều khiển. Bất kỳ điểm nào tôi có thể quay trở lại và sửa đổi, một quyết định trước đó, và tuyên truyền những thay đổi đó thông qua các bước của tôi.