Computer >> Hướng Dẫn Máy Tính >  >> Lập Trình >> Ruby

Làm chủ dự án Rails mới: Chiến lược chứng minh để vượt qua trì hoãn

Bạn vừa gõ rails new cho dự án tiếp theo. Bây giờ sao? Bắt đầu đâu? Viết tất cả trong một app, hay Service Oriented Architecture? Lúc này học RSpec hay không? Bắt đầu build data model, hay lấy vài action chạy end-to-end? Có ton quyết định phải làm trước, và dễ bị lạc lối, trì hoãn, bực bội, và không bao giờ hoàn thành app.

Vấn đề này siêu phổ biến. Nó đến từ việc phải làm quá nhiều lựa chọn trước, khi bạn có ít thông tin nhất để quyết định có căn cứ.

Convention Over Decision-making (Quy ước thay vì Ra quyết định)

Convention over Configuration là nguyên tắc Rails yêu thích của tôi. Trước Rails, tôi bị kẹt tìm nơi đặt file, tên bảng database, map chúng tới object, và ton quyết định nhỏ vô nghĩa khác. Tôi dành thời gian chọn hướng nhiều hơn thời gian đổi ý nếu sau này phát hiện sai.

Nhiều quyết định bạn đối mặt khi bắt đầu project sẽ giống vậy. Nhưng bạn có thể thay thế quyết định này nếu bạn mượn convention từ sách, blog, hoặc styleguide. Và bạn sẽ tiết kiệm nhiều thời gian, stress, và tranh luận vô nghĩa.

Dưới đây là một số convention tôi tuân theo khi bắt đầu app mới:

  • Bắt đầu với vài feature đầy đủ.

    App không phải làm mọi thứ bạn nghĩ ngay lập tức. Bắt đầu nhỏ, bắt đầu đơn giản. Tìm ra một hai feature bạn không thể sống thiếu, và tập trung toàn bộ chú ý vào đó trước. Build chúng thật tốt. Bạn có thể thêm thứ khác sau nếu cần. Nhưng có lẽ, YAGNI. (Và bạn thường thấy những gì bạn nghĩ cần khác hẳn những gì khách hàng nghĩ cần).

  • Bắt đầu với một app đơn lẻ.

    Tôi biết, bạn muốn tránh Monorail. Và có nửa tá RailsTalk về SOA là cách tốt nhất giữ Rails app maintainable lâu dài. Lẽ ra bạn nên tìm ra phần nào của app có thể độc lập, và build service cho mỗi phần?

    SOA là cách tuyệt vời tách app lớn, phức tạp. Nhưng nó thêm rất nhiều đau khổ, và trừ khi đau khổ build, maintain, monitor service vượt quá đau khổ làm việc trên Rails app monolithic, nó không đáng. Và nếu bạn chưa bắt đầu viết app, bạn không cảm thấy đau khổ đó. Vì vậy, bắt đầu với một app.

  • Bắt đầu với stack bạn đã dùng trước.

    Nếu bạn chưa biết stack nào, chỉ dùng Omakase stack. Nhưng bất kỳ cách nào, bạn không muốn mất nửa ngày integrate test framework chưa bao giờ dùng với Rails. Bạn không muốn đấu version conflict giữa VCR và WebMock. Bạn không muốn phải tìm ra test crash là lỗi bạn hay resque_unit. Nếu muốn thử library mới, bạn luôn có thể thêm sau (hoặc thử trên project đồ chơi).

Ship là khó. Nếu bạn muốn hoàn thành app, bạn phải móc từng lợi thế có thể có. Vì vậy bắt đầu nhỏ, bắt đầu đơn giản, và bắt đầu với điều bạn biết.

Convention có thể không hoàn hảo, nhưng chúng giúp bạn bắt đầu. Và bắt đầu là phần khó nhất.

Tiếp theo là gì?

Convention gì bạn tuân theo trên project? Và bạn quyết định feature hoặc test nào bắt đầu như thế nào? Tôi sẽ chia sẻ suy nghĩ lần sau, nhưng tôi muốn nghe của bạn.