Bạn vừa nhập rails new trong dự án tiếp theo của bạn. Giờ thì sao? Bạn bắt đầu từ đâu? Bạn viết mọi thứ trong một ứng dụng hay sử dụng Kiến trúc hướng dịch vụ? Đây có phải là thời điểm tốt để học RSpec? Bạn nên bắt đầu xây dựng tất cả các mô hình dữ liệu của mình hay thực hiện một vài thao tác làm việc từ đầu đến cuối? Bạn phải đưa ra rất nhiều quyết định và bạn dễ cảm thấy mất hứng thú, trì hoãn và nản lòng và không bao giờ hoàn thành ứng dụng của mình.
Vấn đề này là siêu phổ biến. Nó xuất phát từ việc bạn phải đưa ra quá nhiều lựa chọn, khi bạn có ít thông tin nhất cần thiết để đưa ra một quyết định có hiểu biết.
Quy ước về việc ra quyết định
Quy ước trên cấu hình là nguyên tắc Rails yêu thích của tôi. Trước khi có Rails, tôi gặp khó khăn trong việc tìm ra vị trí đặt tệp, đặt tên cho bảng cơ sở dữ liệu, cách ánh xạ chúng với các đối tượng và rất nhiều quyết định nhỏ vô nghĩa khác. Tôi sẽ dành nhiều thời gian để chọn một hướng đi hơn là tôi sẽ phải thay đổi quyết định nếu sau đó tôi phát hiện ra rằng mình đã sai.
Rất nhiều quyết định bạn phải đối mặt khi bắt đầu một dự án mới sẽ như thế này. Nhưng bạn có thể thay thế các quyết định này nếu bạn mượn quy ước từ sách, blog hoặc hướng dẫn định kiểu. Và bạn sẽ tiết kiệm cho mình rất nhiều thời gian, căng thẳng và cuộc tranh luận vô nghĩa.
Dưới đây là một số quy ước tôi tuân theo khi bắt đầu một ứng dụng mới:
-
Bắt đầu với một vài tính năng đầy đủ.
Ứng dụng của bạn không cần phải làm mọi thứ mà bạn có thể nghĩ ra ngay lập tức. Bắt đầu nhỏ, và bắt đầu đơn giản. Tìm ra một hoặc hai tính năng mà bạn không thể thiếu và tập trung toàn bộ sự chú ý vào những tính năng đó trước. Bạn có thể thêm những thứ khác sau nếu cần. Nhưng có lẽ, YAGNI. (Và bạn thường sẽ thấy rằng những gì bạn nghĩ rằng bạn cần hoàn toàn khác với những gì khách hàng của bạn nghĩ rằng bạn cần).
-
Bắt đầu với một ứng dụng.
Tôi biết, bạn muốn tránh xây dựng một tàu điện một ray. Và có khoảng nửa tá RailsConf nói về cách SOA là cách tốt nhất để giữ cho các ứng dụng Rails có thể duy trì trong thời gian dài. Bạn không nên tìm ra phần nào trong ứng dụng của mình có thể độc lập và xây dựng dịch vụ cho mỗi phần?
SOA là một cách tuyệt vời để phá vỡ một ứng dụng lớn và phức tạp. Nhưng nó thêm một tấn đau đớn và trừ khi nỗi đau của việc xây dựng, duy trì và giám sát các dịch vụ lớn hơn nỗi đau khi làm việc trên ứng dụng Rails nguyên khối của bạn, điều đó không đáng phải làm. Và nếu bạn chưa bắt đầu viết ứng dụng của bạn, bạn không cảm thấy đau đớn. Vì vậy, hãy bắt đầu với một ứng dụng.
-
Bắt đầu với ngăn xếp mà bạn đã sử dụng trước đây.
Nếu bạn chưa biết ngăn xếp, chỉ cần sử dụng ngăn xếp Omakase. Nhưng dù theo cách nào thì bạn cũng không muốn dành nửa ngày để tích hợp khung thử nghiệm mà bạn chưa từng sử dụng trước đây với Rails. Bạn không muốn chống xung đột phiên bản giữa VCR và WebMock. Bạn không muốn phải tìm hiểu xem các thử nghiệm của bạn bị lỗi là do lỗi của bạn hay do resque_unit. Nếu bạn muốn dùng thử một thư viện mới, bạn luôn có thể thêm nó vào sau (hoặc thử nó trong một dự án đồ chơi).
Vận chuyển là khó. Nếu bạn muốn hoàn thiện ứng dụng của mình, bạn phải cố gắng tận dụng mọi lợi thế mà bạn có thể nhận được. Vì vậy, hãy bắt đầu từ việc nhỏ, bắt đầu đơn giản và bắt đầu với những gì bạn biết.
Các quy ước có thể không phải lúc nào cũng hoàn hảo, nhưng chúng sẽ giúp bạn bắt đầu. Và bắt đầu là phần khó nhất.
Tiếp theo là gì?
Bạn tuân theo quy ước nào về các dự án của mình? Và làm thế nào để bạn quyết định những tính năng hoặc thử nghiệm bạn nên bắt đầu? Tôi sẽ chia sẻ suy nghĩ của mình vào lần tới, nhưng tôi muốn nghe một số suy nghĩ của bạn.