Trong phát triển nhanh, tôi có nên thử kiên trì trong tệp phẳng trước cơ sở dữ liệu không?

Ai đó đã giải thích cho tôi rằng vì trong phát triển nhanh, chính sách và logic ứng dụng nên quan trọng hơn các chi tiết như phương pháp kiên trì, nên đưa ra quyết định kiên trì vào cuối. Vì vậy, có thể là một ý tưởng tốt để bắt đầu với sự kiên trì đơn giản hơn như các tệp phẳng, cho đến khi chúng ta đạt đến điểm yếu của phương pháp này, và chỉ sau đó chúng ta thay đổi tính bền vững, ví dụ: bằng cách sử dụng cơ sở dữ liệu quan hệ.

Điều này có đúng không, hay tôi đã hiểu nhầm khái niệm này? Đây có phải là cách nhóm nhanh nhẹn thường xây dựng ứng dụng? Các lý do cho nó là gì và khi nào tôi không nên thực hiện phương pháp này?

Khái niệm được truyền đạt là một cái gì đó chắc chắn là một phần của nhanh nhẹn và có liên quan, ý tưởng đẩy mọi thứ đến thời điểm có trách nhiệm cuối cùng.

Tuy nhiên , ví dụ được thực hiện dựa trên một giả định hoàn toàn sai lầm để bắt đầu bằng:

rằng việc triển khai cơ sở dữ liệu tệp phẳng dễ dàng hơn / ít hơn so với sử dụng RDBMS. - Thường là hoàn toàn sai

Ví dụ nên là: Lớp kiên trì được giữ ở mức thực hiện đơn giản nhất có thể cho đến khi có quyết định được đưa ra là không thỏa đáng.

Đối với nhiều nhóm phát triển, việc có được một cơ sở dữ liệu đứng lên để thực hiện việc này chỉ mất một hoặc hai giờ (hoặc 15 phút cho cơ sở dữ liệu nhỏ với ORM) trong khi cơ sở dữ liệu tệp phẳng mà họ không cần phải can thiệp có thể là một Đau đớn và khó chịu vô cùng vì họ phải viết tay tất cả mã loại xây dựng bảng tìm kiếm và dữ liệu theo cách thủ công, khi cơ sở dữ liệu có thể đơn giản như tạo bảng trong UI, thêm một vài cột và sau đó ORM tạo mọi thứ khác bạn cần.

Hơn nữa, nếu bạn không biết lớp kiên trì của mình để bắt đầu thì đó là một hành động thậm chí phù hợp hơn để bắt đầu với một RDBMS chung mà nhóm của bạn biết rõ, để làm cho thay đổi sau này từ tệp phẳng sang RDBMS lớn hơn nhiều so với sau này thay đổi từ RDBMS này sang RDBMS khác. Có nhiều công cụ để chuyển đổi từ hầu hết mọi RDBMS thông thường sang các công cụ khác, và các mẹo và như vậy bởi vì đó là một con đường được truyền đi tốt. Có rất ít công cụ để chuyển đổi từ tệp phẳng sang bất kỳ RDBMS cụ thể nào, nơi tệp phẳng của bạn có một số định dạng độc quyền mà công cụ trước đây chưa được viết cho các thư viện của riêng bạn.

Tóm lại: Khái niệm này là chính xác và chính xác, nhưng ví dụ này dựa trên một giả định cực kỳ lớn và thường (hầu như luôn luôn) không chính xác .

Vì bạn biết bạn sẽ sử dụng DB, nên không có nhiều điểm trong việc viết mã để xử lý các tệp phẳng. Bạn có thể vượt qua một vài lần lặp lại bằng cách sử dụng một số CSV chỉ đọc nhưng bạn sẽ nhanh chóng thấy mình viết mã mà bạn biết bạn sẽ vứt đi.

Một điều bạn có thể làm để đơn giản hóa sự phức tạp ban đầu bằng cách sử dụng một cái gì đó như SQLite (một thư viện cung cấp cho bạn một cơ sở dữ liệu SQL không có máy chủ được lưu trữ trong một tệp). Nó có một hệ thống loại linh hoạt để bạn không phải nghiêm túc cam kết với một lược đồ, không có máy chủ nào để định cấu hình / kết nối và xây dựng lại DB của bạn đơn giản như xóa một tệp. Nó cũng cho phép bạn chỉ cần bao gồm hình ảnh DB cùng với mã trong kiểm soát phiên bản nếu cần.

Đó là một ví dụ, được sử dụng để thể hiện một khái niệm, chứ không phải là một khái niệm trong chính nó.

Khái niệm là bạn không đưa ra quyết định kiến ​​trúc cho đến giây phút chịu trách nhiệm cuối cùng , nhưng không muộn hơn. Nhưng, trong thực tế, bạn thường có quyết định về cơ sở dữ liệu mà bạn sẽ sử dụng từ rất sớm. Điều đó có thể không hoàn hảo, nhưng đó là sự thật.

Một khi quyết định đó được đưa ra, bạn không chủ động tránh nó. Lưu trữ một cái gì đó trong cơ sở dữ liệu hiện có thường dễ dàng như lưu trữ nó trong một tệp phẳng.

Nhưng việc thay đổi từ MySql trên Linux sang SQL Server trên Windows có thể không đơn giản như thay đổi từ một tệp phẳng ở bất kỳ đâu sang SQL Server trên Windows. Đó là điểm thực sự. Vì vậy, trong khi có nghi ngờ về giải pháp cuối cùng, hãy chọn phương án đơn giản nhất có thể, tính toán cho sự thay đổi. Một khi quyết định được đưa ra, hãy bám vào nó.

Bạn đang kiên trì điều gì?

Tôi thuộc nhóm nhanh nhẹn và trong một ứng dụng, chúng tôi tồn tại hầu hết mọi thứ cho cơ sở dữ liệu. Tâm trí bạn, nếu chúng ta không thì sẽ không có nhiều cho ứng dụng này để làm - kiên trì điều cần một cơ sở dữ liệu là một phần lớn của nó raison d'être .

Vì vậy: Bạn đang kiên trì và ứng dụng của bạn làm gì? Nếu ứng dụng không thực sự quan tâm đến việc dữ liệu của nó được duy trì ở đâu, thì bạn có thể viết một lớp nhỏ để đưa ra quyết định (quyết định đó có thể được lưu trữ trong tệp cấu hình ở đâu đó) của tệp phẳng so với cơ sở dữ liệu. Tôi nghĩ rằng bạn cần phải đánh giá ứng dụng của bạn và dữ liệu của bạn và quyết định xem nó có ý nghĩa trong trường hợp cụ thể của bạn để đầu tư thời gian trong cơ sở dữ liệu bền bỉ, hoặc chỉ đọc / ghi tập tin phẳng (mà sẽ có thể được nhanh hơn về thời gian phát triển).

Rất nhiều người hiểu sai rằng khía cạnh của nhanh nhẹn có nghĩa là họ không nên lập kế hoạch trước cho các tính năng trong tương lai. Không gì có thể hơn được sự thật. Những gì bạn không làm là cho phép lập kế hoạch cho các tính năng trong tương lai để trì hoãn việc cung cấp giá trị cho khách hàng của bạn ngay bây giờ.

Làm thế nào điều đó áp dụng cho một cái gì đó như sự kiên trì phụ thuộc rất nhiều vào ứng dụng của bạn. Một trong những dự án sở thích hiện tại của tôi là một máy tính. Cuối cùng, tôi muốn có thể lưu trữ các hằng số và hàm do người dùng xác định và lưu trạng thái khi tôi đóng chương trình. Điều đó đòi hỏi sự kiên trì, nhưng tôi thậm chí chưa bắt đầu nghĩ về hình thức nào sẽ diễn ra. Chương trình của tôi sẽ rất hữu dụng nếu không có sự kiên trì và thêm nó ngay bây giờ sẽ thêm độ trễ đáng kể cho bản phát hành đầu tiên của tôi. Tôi thà có một máy tính làm việc với ít tính năng hơn không có gì trong khi tôi chờ nó hoàn hảo.

Một dự án sở thích khác của tôi là chỉnh sửa màu sắc video và hình ảnh. Ứng dụng này sẽ hoàn toàn không sử dụng được mà không thể lưu công việc của tôi trong tiến trình và mã cần thiết để làm như vậy là phổ biến trong toàn bộ chương trình. Nếu tôi không hiểu nó ngay từ đầu, thì việc thay đổi nó có thể cực kỳ khó khăn, vì vậy tôi đã dành khá nhiều nỗ lực để kiên trì lên phía trước.

Hầu hết các dự án sẽ nằm ở đâu đó giữa, nhưng bạn sẽ không bao giờ cảm thấy tồi tệ khi lập kế hoạch cho các tính năng trong tương lai nếu bây giờ nó không thêm chút nỗ lực nào. Cơ sở dữ liệu có thể phức tạp, nhưng hầu hết sự phức tạp đó được ẩn đằng sau một giao diện được kiểm tra tốt. Công việc bạn sẽ phải làm trong ứng dụng của mình có thể rất ít cho cơ sở dữ liệu hơn là một tệp phẳng, vì tất cả các tính năng mà cơ sở dữ liệu cung cấp cho bạn miễn phí. Có các tùy chọn "lai" như SQLite nếu bạn chưa muốn giải quyết rắc rối của máy chủ cơ sở dữ liệu.

Tôi nghĩ rằng bạn đang tập trung vào các giá trị sai. Trong nhanh nhẹn, giá trị kinh doanh là trọng tâm. Bạn tạo một sản phẩm để cung cấp giá trị doanh nghiệp cho một số người dùng cuối.

Nếu bạn tạo lớp kiên trì muộn, hoặc tạo ra nó trên đường đi là chiến lược của bạn để cung cấp giá trị kinh doanh cho khách hàng. Tôi không tin rằng chính thuật ngữ "nhanh nhẹn" ra lệnh nếu bạn nên làm cái này hay cái khác.

Quan điểm về chiến lược lưu trữ dữ liệu trì hoãn được ủng hộ trong bài trình bày này của Robert C. Martin (một trong những tác giả của bản tuyên ngôn nhanh).

Đó là một bài thuyết trình rất tốt, tôi có thể khuyên bạn nên xem nó.

Nhưng tôi không đồng ý với nó! Ít nhất là đến một mức độ.

Tôi không tin rằng bạn có thể gọi câu chuyện của người dùng là "Xong", nếu câu chuyện của người dùng liên quan đến dữ liệu cần được duy trì và bạn thực sự không có bất kỳ loại kiên trì nào được triển khai.

Nếu chủ sở hữu sản phẩm quyết định rằng bây giờ là thời gian để phát hành trực tuyến, bạn không thể làm điều đó. Và nếu bạn chưa bắt đầu thực hiện kiên trì cho đến cuối dự án, bạn cũng không có thông tin về việc mất bao lâu để thực hiện lớp kiên trì, khiến nó có rủi ro lớn cho dự án.

Các dự án nhanh mà tôi đã làm việc đã không trì hoãn chiến lược truy cập dữ liệu. Nhưng nó đã được tách ra, cho phép chúng ta thay đổi nó trên đường đi. Và toàn bộ lược đồ cơ sở dữ liệu không được thiết kế trước. Các bảng và cột được tạo dọc đường khi chúng được yêu cầu để triển khai người dùng được lưu trữ, cuối cùng, cung cấp giá trị doanh nghiệp.

Cần có sự đánh giá và kinh nghiệm tốt để xem những câu hỏi nào cần trả lời trước khi bắt tay vào một dự án mới.

Nếu sản phẩm cuối cùng vẫn chưa được biết thì việc xây dựng / tạo mẫu nhanh chóng giúp bạn tìm ra điều đó, và có lặp lại theo cách nhanh nhẹn sẽ giúp ích. Điều đó tất nhiên sẽ gây ra rủi ro như phát hiện muộn trong quá trình thực hiện kiên trì sẽ mất nhiều thời gian hơn bạn đã truyền đạt cho các bên liên quan.

Nếu sản phẩm cuối cùng được biết đến thì việc hiểu sự kiên trì sẽ hoạt động như thế nào trong ứng dụng của bạn có thể quan trọng hơn để biết sớm. Rủi ro ở đây là tìm thấy các vấn đề với đặc điểm kỹ thuật sản phẩm của bạn sau này trong quá trình phát triển.

Tập tin phẳng không đơn giản!

Họ cho phép lưu trữ và đó là tất cả. Cấu trúc của dữ liệu, đường dẫn truy cập, vv tùy thuộc vào bạn, và, có rất nhiều cách để làm điều này sai.

Có nhiều lý do cơ sở dữ liệu tồn tại và một trong số đó là làm cho mọi thứ đơn giản hơn cho các nhà phát triển.

Hầu hết sự phát triển của tôi được thực hiện cho các hệ thống lớn trong các công ty lớn. Chúng tôi luôn có một mô hình dữ liệu đầy đủ và được cân nhắc kỹ lưỡng trước khi tiến hành bất kỳ thiết kế hoặc phát triển nào nữa. Một mô hình dữ liệu giúp bạn hiểu vấn đề của mình và cho phép thực hiện rõ ràng.

Các mục dữ liệu bị lãng quên, cấu trúc dữ liệu không khớp và các cơn ác mộng khác đều có thể tránh được bằng cách tạo ra một mô hình dữ liệu ở phía trước.

Bạn có thể để sự lựa chọn thực tế của bạn về công nghệ cơ sở dữ liệu cho đến sau mô hình dữ liệu. Nhưng hầu hết các công nghệ "kiên trì" là lập trình chặt chẽ và thậm chí là phong cách thiết kế. Nếu bạn mã cho một cơ sở dữ liệu quan hệ và sau đó quyết định chuyển sang một giá trị khóa có mây, bạn sẽ cần phải viết lại hoàn toàn một nửa mã của mình.

Nếu bạn bắt đầu với các tệp phẳng và chuyển sang DB quan hệ, có thể bạn sẽ vứt bỏ một nửa mã của mình vì các nhà phát triển của bạn sẽ lãng phí thời gian để thực hiện cơ sở dữ liệu kém.

Bạn có nên thử kiên trì trong một tập tin phẳng trước cơ sở dữ liệu?

Vâng, bạn nên thử nó. Đặc biệt là nếu bạn chưa bao giờ thử nó trước đây. Bất kể nó diễn ra như thế nào, bạn sẽ học được điều gì đó.