Quy trình phát triển của Ruby on Rails


8

Chúng tôi là một nhóm nhỏ sắp bắt đầu phát triển phiên bản địa phương hóa của một ứng dụng web thành công của Hoa Kỳ tại Hàn Quốc, sử dụng RoR.

Câu hỏi của chúng tôi là: Quá trình nào bạn muốn giới thiệu chúng tôi sử dụng để phát triển ứng dụng?

Chúng ta có nên bắt đầu với các mô hình dữ liệu? Các quan điểm trong HTML và sau đó mã chúng? Lấy một tính năng duy nhất, phát triển nó và sau đó thêm các tính năng bổ sung khi cần thiết?

Một vài chi tiết về dự án:

  1. nó là một ứng dụng web cho các chủ doanh nghiệp nhỏ
  2. nó bao gồm các tính năng quản trị tài liệu tài liệu quản trị người dùng crm-báo cáo-bảng điều khiển thông thường mà hầu hết các ứng dụng biz nhỏ thường có
  3. quy mô nhóm ban đầu chỉ có 2 người: một lập trình viên và một nhà thiết kế / CSS guru (chỉ một lập trình viên)
  4. mức độ kinh nghiệm là trung bình. kiến thức tốt về Git, Ruby, Rails và XHTML / CSS, ít kinh nghiệm với các vấn đề triển khai. đây là dự án đầu tiên thuộc loại mà chúng tôi đang làm cùng nhau

Câu trả lời:


2

Tôi muốn giới thiệu mô hình phát triển theo hướng hành vi,

Nếu bạn không quen, hãy để tôi cung cấp cho bạn một cái nhìn tổng quan:

Bắt đầu tại các đai ốc và bắt vít "sân thang máy" của ứng dụng ..

"Thứ này chúng ta đang xây dựng là gì? Nó mang lại giá trị gì?"

Và sau đó chọn "tính năng" yêu cầu tối thiểu tuyệt đối và bắt đầu "chỉ định" nó ra .. id 'khuyên bạn nên sử dụng Cucumber: http://cukes.info/ và Rspec: http://rspec.info/ để mô tả tính năng này như thế nào phải hành xử .. chạy thử nghiệm / thông số kỹ thuật và xem chúng thất bại ..

Sau đó đi sâu vào và bắt đầu thực hiện tính năng và xem các bài kiểm tra vượt qua 1 ..

Khi tính năng này được thực hiện (tất cả các bài kiểm tra vượt qua) lặp lại quy trình .. chuyển sang "tính năng" yêu cầu tối thiểu tiếp theo, v.v.

Đối với khối lượng công việc tập trung vào tính năng xây dựng của bạn cùng nhau, lập trình viên làm việc dựa trên hành vi và nhà thiết kế làm việc về giao diện cho đến khi cả hai làm việc hoàn hảo với nhau ..


cảm ơn! Bất kỳ đề xuất về một hướng dẫn / cuốn sách tốt về rspec / dưa chuột sẽ không khiến chúng ta bị sa lầy bởi các chi tiết?
Kai EV

Bản thân tôi đã tìm kiếm điều tương tự cách đây không lâu .. Không thể sai với "cuốn sách rspec": pragprog.com/title/achbd/the-rspec-book Tôi nghĩ rằng điều quan trọng về BDD là làm cho nó hoạt động với bạn .. Khi tôi bắt đầu, tôi đã dành quá nhiều thời gian để lo lắng về việc bộ công cụ kiểm tra này đẹp đến mức nào tôi chưa bao giờ hoàn thành công việc .. Ngoài ra, đoạn ghi âm tuyệt vời này từ ryan bates thực sự hữu ích: railscasts.com/episodes/155-beginning-with- dưa chuột
Daniel Upton

0

Vấn đề lớn nhất bạn sẽ gặp phải là quản lý các bản cập nhật từ sản phẩm chính - bạn sẽ cần hợp nhất các thay đổi của mình với nó nếu bạn muốn theo kịp các bản phát hành của chúng. Tất cả các yếu tố khác là IMHO không liên quan.

Vì vậy, hãy chắc chắn rằng bạn lấy sản phẩm chính, sau đó tạo một bản sao của nó để làm việc. Khi họ phát hành phiên bản mới, hãy cập nhật bản gốc của bạn với phiên bản của họ và sau đó bạn có thể thấy những thay đổi họ đã thực hiện và hợp nhất chúng với phiên bản của bạn. Tái cấu trúc sản phẩm là một vấn đề rất lớn - đừng làm điều đó, vì mọi tệp mới đều khiến mọi thứ trở nên khó khăn để xem sự thay đổi so với ban đầu xảy ra. Nó cũng dễ dàng hơn nếu bạn có thể giữ các thay đổi của mình trong các tệp riêng biệt.

Mặt khác, để phát triển tính năng tôi thực hiện theo tính năng, sau đó bạn có một cách tốt để kiểm tra tính năng này trước khi chuyển sang tính năng tiếp theo. Cố gắng mọi thứ trong một lần khó khăn hơn nhiều. Giữ một hệ thống kiểm tra tại chỗ để bạn có thể phát hành từng tính năng cho nó và đảm bảo rằng nó hoạt động (tức là trên một hộp không phải là nhà phát triển)


lại quá trình dev - chúng tôi nghe thấy bạn! Dường như rất đồng ý với đề xuất của Daniel, vì vậy chúng tôi sẽ xem xét như bạn đề xuất. tuy nhiên không chắc chắn chúng tôi hiểu đầy đủ đoạn quản lý cập nhật ... bạn có đang đề cập đến thử thách sau triển khai thêm / thay đổi tính năng không? Tại sao một hệ thống kiểm soát nguồn đơn giản sẽ xử lý những thay đổi này?
Kai EV
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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.