Là liên tục tạo và xóa các bảng là một dấu hiệu của một lỗ hổng kiến ​​trúc?

Gần đây tôi đã thảo luận với một nhà phát triển đã đề cập rằng trong quá trình phát triển chương trình, họ thường xuyên tạo và xóa các bảng và cột một cách thường xuyên trong khi làm việc với các tính năng mới và những điều hợp lý bằng cách nói rằng điều này là bình thường khi sử dụng quy trình phát triển nhanh.

Vì hầu hết nền tảng của tôi là trong môi trường phát triển thác nước, tôi tự hỏi liệu điều này có thực sự được coi là phù hợp với sự phát triển nhanh hay không, nếu đây có thể là dấu hiệu của một vấn đề tiềm ẩn, với kiến ​​trúc chương trình hoặc với quy trình nhanh của chúng.

Nó ngày càng trở nên rõ ràng hơn đối với tôi mỗi ngày rằng "nhanh nhẹn" đang trở thành một từ đồng nghĩa với suy nghĩ kém, hỗn loạn, vội vã và ngồi trên quần của bạn. Và không ai trong số những điều đó tương thích với cách tiếp cận Agile như tôi hiểu.

Có một quy trình Agile hiệu quả và có thể lặp lại là không dễ dàng và tôi không tin rằng nó vốn đã làm giảm tổng số công việc phải hoàn thành mặc dù nó rất có thể dẫn đến các sản phẩm tốt hơn.

Nếu họ đã nói rằng họ không có thời gian để "cấu trúc lại" cơ sở dữ liệu thì có lẽ họ cũng không có thời gian để thiết lập phiên bản và di chuyển cho cơ sở dữ liệu. Có lẽ họ đã không dành thời gian để tạo ra một bộ thử nghiệm chức năng cho nó. Tất cả những điều đó là những gì tôi nghĩ khi tôi nghĩ về một quy trình Agile vững chắc hướng đến thành công.

Cuối cùng, Agile chỉ là một từ. Những gì bạn đang làm hàng ngày sẽ quyết định bạn sẽ thành công hay không.

Mặc dù không có gì bất thường khi tạo và xóa các bảng khi thiết kế phát triển, một số dọn dẹp có thể để đảm bảo cơ sở dữ liệu của bạn thực sự sử dụng tất cả các bảng đó.

Vâng, Agile là tất cả về tái cấu trúc, nhưng nếu bây giờ họ nói hệ thống này quá lớn để tái cấu trúc, họ đã ngừng làm Agile và giờ chỉ là lập trình Cowboy. Nhóm phát triển sẽ không thích được gọi như vậy, nhưng đó là những gì họ đang làm. Cưỡi tầm bắn bất cứ thứ gì di chuyển.

Một DBA sẽ giúp, chỉ cần đảm bảo bạn có được một DBA hiểu được sự phát triển cũng như phát triển Agile. Nhóm phát triển của bạn cần được kiểm soát, không bị tống vào tù.

Nói chung, việc thường xuyên tạo các bảng mới và thêm các cột mới là rất bình thường trong một quy trình mà việc lập trình và quản trị cơ sở dữ liệu không được tách biệt nghiêm ngặt. Một tính năng mới có thể tạo dữ liệu mới phải đi đâu đó. Cố gắng quá nghiêm ngặt để tránh điều đó và bạn kết thúc với một mô hình nền tảng bên trong .

Phần mềm được viết tốt hầu như không nhận thấy các đối tượng cơ sở dữ liệu mới này, vì vậy không có gì phá vỡ chỉ vì một cột mới trong một số bảng.

Mặt khác, việc thường xuyên thả các cột hoặc thậm chí các bảng là đáng ngờ. Một tính năng mới không bao giờ cần xóa bảng, vì vậy đây có thể là dấu hiệu của những người làm việc hoàn toàn vô kế hoạch.

Nếu cơ sở dữ liệu của bạn có thể dễ dàng được phiên bản và di chuyển và bạn đã có các bài kiểm tra để chứng minh rằng việc thay đổi mọi thứ không phá vỡ mọi thứ thì có lẽ bạn đã có một quy trình khá nhanh.

Trong các ý kiến ​​- nói chung với tác động của những điều này là một nhóm cao bồi tự cho mình là nhanh nhẹn - chạy la hét. Nhanh. Và đăng tất cả những gì bạn có thể lên thed Dailywtf.com để tất cả chúng ta có thể tận hưởng nỗi kinh hoàng của bạn.

Giống như hầu hết các câu trả lời ở đây trên StackExchange, câu trả lời phải là 'nó phụ thuộc'. Trong phát triển nhanh, các yêu cầu và thông số kỹ thuật được phát hiện trong quá trình thực hiện.

Tuy nhiên, với sự phát triển nhanh, khi một mô hình quan hệ được chuẩn hóa đúng cách, việc thêm các thuộc tính mới vào các mối quan hệ hiếm khi là một điều cần thiết, các thực thể mới thường nên tham chiếu đến các mô hình cũ hơn, được đưa ra một mô hình thích hợp.

Hầu hết các nhà phát triển không bình thường hóa DB của họ vì hạn chế về thời gian, sự lười biếng, không đủ năng lực hoặc độ phức tạp của truy vấn. Việc tái chuẩn hóa đòi hỏi phải chuyển dữ liệu hiện có, sửa đổi DAO, v.v ... tạo ra yếu tố rủi ro.

Để trả lời câu hỏi của bạn, không, điều đó không bình thường trong quy trình Agile.

Trường hợp dường như xuất phát từ thái độ Agile là từ chu trình thiết kế / phát triển / thử nghiệm ngắn của Agile và nhấn mạnh vào các giải pháp nhẹ đáp ứng các yêu cầu đã biết của Agile, nhưng được cấu trúc tốt để có thể đáp ứng các yêu cầu mới với thay đổi tối thiểu. Với hai điều này, bạn có thể nói rằng một nhà phát triển, không biết điều gì có thể xảy ra nhưng biết thay đổi của anh ta không nên tác động đến DB theo cách không thể hoàn tác, chỉ cần thực hiện các thay đổi cần thiết cho lược đồ trong Cách "nhẹ nhất" có thể, và sau đó, một vài bộ thay đổi "ánh sáng" sẽ được tái cấu trúc thành một thứ gì đó lâu dài và ổn định hơn.

Có nói rằng, tôi chưa làm việc với một nhà phát triển đã đăng ký lý thuyết và phương pháp Agile, và cũng nghĩ rằng việc tạo và xóa các bảng trong lược đồ là cần thiết vì bất kỳ lý do nào. Agile không có nghĩa là slap-dash hoặc bolt-on. Nếu bạn được cung cấp một câu chuyện yêu cầu thêm một trường dữ liệu mới thuộc về một bản ghi cụ thể, bạn thêm trường vào bảng. Nếu sự thay đổi đó phá vỡ điều gì đó, bạn sẽ hiểu tại sao và thực hiện các thay đổi khác là cần thiết (tôi có thể nghĩ ra rất ít điều sẽ phá vỡ bằng cách thêm một cột vào DB được truy vấn; nếu nó phá vỡ với loại thay đổi này bạn có vấn đề lớn hơn). Tái cấu trúc thường được giới hạn trong mã; thay đổi lược đồ thường là một quá trình liên quan nhiều hơn thay đổi mã, và vì vậy khi thay đổi lược đồ phải xảy ra, chúng thường được thực hiện cẩn thận hơn, và ít nhất một số chú ý đến kiến ​​thức về định hướng tương lai của dự án. Phải cấu trúc lại một số hoặc tất cả các cơ sở dữ liệu cho thấy sự thất bại cơ bản của thiết kế; Là Agile không có nghĩa là không có "kế hoạch tổng thể" về các quy tắc thiết kế và kiến ​​trúc cơ bản để tuân theo trong khi xây dựng một cách hữu cơ chương trình và cấu trúc dữ liệu.

Bây giờ, có những trường hợp trong Agile nơi mà những gì bạn "biết" bây giờ sẽ bị mâu thuẫn bởi những gì bạn sẽ học sau này. Giả sử bạn có một yêu cầu rằng hệ thống của bạn phải có Địa chỉ cho mỗi người. Vì đây là mối quan hệ 1: 1 và dữ liệu sẽ cần trong phần lớn các trường hợp, bạn chỉ cần thêm các trường Địa chỉ vào bảng Person. Một tuần sau, bạn nhận được yêu cầu một Người có thể có nhiều Địa chỉ. Bây giờ, đó là mối quan hệ 1: N và để mô hình hóa chính xác, bạn phải hoàn tác các thay đổi trước đó của mình, tách các trường ra thành một bảng Địa chỉ mới. Đây không phải là thường lệ, đặc biệt là trong số các nhà phát triển cao cấp. Nhà phát triển có kinh nghiệm sẽ thấy rằng một Người có Địa chỉ, coi những người này là riêng biệt về mặt khái niệm và tạo bảng Người và bảng Địa chỉ, liên kết Người với Địa chỉ với tham chiếu FK với Địa chỉ. Một lược đồ như thế này dễ thay đổi hơn nên bản chất của mối quan hệ thay đổi; mà không tạo hoặc xóa toàn bộ bảng dữ liệu "rộng", mối quan hệ giữa Người và Địa chỉ có thể được sửa đổi khá dễ dàng từ 1: 1 thành 1: N thành N: N.

Không có quá nhiều sự tập trung vào thiết kế trước khi làm việc dưới Agile, vì vậy tôi không thấy đây là một vấn đề lớn, chắc chắn là cho phiên bản đầu tiên.

Thật khó để bình luận về một hệ thống có 700 bảng tôi chưa từng thấy, nó cũng có thể cần tất cả chúng, nhưng cũng có thể là trường hợp cơ sở dữ liệu chưa được quản lý đủ tốt.

Ngay cả dưới sự nhanh nhẹn, đối với một hệ thống lớn, điều khá phổ biến là vẫn có ai đó / nhóm phụ trách lược đồ.

Nếu họ đang thực hiện các thay đổi như vậy thường xuyên - đặc biệt là bỏ các bảng và cột trong các ứng dụng trực tiếp - đó có vẻ như là một dấu hiệu của sự thiếu kinh nghiệm. Nó không có gì để làm với bất kỳ quá trình mà họ đang tuyên bố tuân theo. 'Agile' không phải là lý do để không ngồi xuống và suy nghĩ về dữ liệu bạn cần lưu trữ và cách nó liên quan trước khi bạn bắt đầu viết mã. Nếu họ thấy họ đang thay đổi hơn 10-20% cấu trúc ban đầu, với tôi đó là một chỉ số họ sẽ không suy nghĩ mọi thứ hoặc họ không có nhiều kinh nghiệm phân tích các yêu cầu và thiết kế cơ sở dữ liệu, và vì vậy họ chỉ đơn giản là nhận được nhiều sai lầm khi bắt đầu

Mặc dù có vẻ như nhóm của bạn thực sự chỉ đơn giản là mã hóa cao bồi, nhưng thực sự không có gì sai khi tái cấu trúc cơ sở dữ liệu HOẶC cơ sở dữ liệu. Nó không bị mất việc - nó thích nghi với một thực tế mới học được.

Tôi muốn đề xuất những gì nhóm cần là một hộp cát để thử các thay đổi, thực hiện một số thử nghiệm, đưa chúng ra khỏi người dùng và quyết định xem chúng có hợp lý hay không. Tại thời điểm đó, việc tích hợp các thay đổi có ý nghĩa - với thử nghiệm hồi quy thích hợp - vào lược đồ của bạn sẽ ổn.

Agile là về mã hóa, Cơ sở dữ liệu không phải là mã. Thay đổi cơ sở dữ liệu nên được xử lý như tu sửa một ngôi nhà. Mọi người bằng cách nào đó có niềm tin rằng nhanh nhẹn có nghĩa là hành động lập kế hoạch sau này, điều này là hoàn toàn sai sự thật. Ngay cả theo phương pháp nhanh, thời gian cần phải được đưa ra để lập kế hoạch, đặc biệt đối với một cái gì đó quan trọng như thiết kế cơ sở dữ liệu.

Công việc cuối cùng của tôi là ở một đội như thế này. Khi sử dụng một yêu cầu quá trình nhanh nhẹn thay đổi. Đôi khi các thay đổi có nghĩa là một thực thể hiện tại cần một thuộc tính mới dẫn đến một cột mới trong một bảng hiện có hoặc một thực thể hoàn toàn mới được yêu cầu dẫn đến một bảng mới có mối quan hệ với các bảng hiện có. Những loại thay đổi này đi kèm với lãnh thổ và không thể bỏ qua chỉ vì bạn không muốn chạm vào lược đồ. Thành công được xác định bằng cách duy trì tính toàn vẹn của dữ liệu của bạn khi di chuyển từ một phiên bản cơ sở dữ liệu sang thử nghiệm đơn vị phù hợp và tiếp theo.

Chỉ cần cố gắng không thực hiện các thay đổi không cần thiết cho lược đồ của bạn. Ví dụ: nếu một tính năng yêu cầu tạo bảng mới, hãy đảm bảo bạn hài lòng với định nghĩa của bảng đó trước khi bạn kiểm tra và đưa nó ra môi trường thử nghiệm của bạn. Phải hoàn tác một thay đổi đối với lược đồ cơ sở dữ liệu của bạn sau khi dữ liệu của bạn đã được di chuyển có thể gây đau đớn.