연속적인 테이블 작성 및 삭제가 건축 결함의 징후입니까?

최근에 나는 프로그램 개발 중에 정기적으로 테이블과 열을 정기적으로 만들고 삭제하면서 새로운 기능을 수행하고 민첩한 개발 프로세스를 사용할 때 이것이 정상이라고 말하면서 사물을 정당화한다고 언급 한 개발자와 토론을했습니다.

내 배경의 대부분이 폭포 개발 환경에 있기 때문에 이것이 애자일 개발에서 실제로 적절하다고 생각되는지 또는 이것이 프로그램 아키텍처 또는 애자일 프로세스의 후속으로 근본적인 문제의 징조인지 궁금합니다.

날마다 "민첩한"생각이 나쁘고, 혼란스럽고, 서두르고, 바지와 동의어가되고 있다는 것이 나에게 점점 더 명백 해지고 있습니다. 그리고 그 중 어느 것도 내가 이해하는 것처럼 애자일 접근 방식과 호환되지 않습니다.

효과적이고 반복 가능한 민첩한 프로세스를 갖는 것은 쉬운 일이 아니며, 그것이 더 나은 제품으로 이어질 수는 있지만 수행해야 할 총 작업량을 본질적으로 줄이는 것으로 생각하지 않습니다.

데이터베이스를 "리팩토링"할 시간이 없다고 말하면 데이터베이스의 버전 관리 및 마이그레이션을 설정할 시간이 없을 것입니다. 아마도 일련의 기능 테스트를 작성하는 데 시간이 걸리지 않았을 것입니다. 그 모든 것들은 성공을 향한 확실한 민첩한 프로세스를 생각할 때 내가 생각하는 것입니다.

결국 애자일은 한 단어 일뿐입니다. 당신이 매일하고있는 일이 당신의 성공 여부를 결정합니다.

디자인이 발전함에 따라 테이블을 작성하고 삭제하는 것은 드문 일이 아니지만 데이터베이스가 실제로 모든 테이블을 사용하도록하기 위해 일부 정리가 필요할 수 있습니다.

예, 애자일은 리팩토링에 관한 것이지만, 이제 시스템이 리팩토링하기에 너무 크다고 말하는 경우, 애자일 수행을 중단했으며 이제는 카우보이 프로그래밍입니다. 개발팀은 그렇게 부르기를 좋아하지 않지만 그것이하는 일입니다. 움직이는 모든 것을 촬영하는 범위를 타고.

DBA는 개발과 애자일 개발을 이해하는 DBA를 얻는 데 도움이됩니다. 개발팀은 교도소에 갇히지 말고 재조정해야합니다.

일반적으로 프로그래밍과 데이터베이스 관리가 엄격하게 분리되지 않은 프로세스에서는 종종 새 테이블을 만들고 새 열을 추가하는 것이 매우 일반적입니다. 새로운 기능은 새로운 데이터를 생성하여 어딘가에 가야합니다. 이를 피하기 위해 너무 엄격하게 시도하면 내부 플랫폼 모델이 생깁니다 .

잘 작성된 소프트웨어는 이러한 새 데이터베이스 개체를 거의 인식하지 못하므로 일부 테이블의 새 열로 인해 아무 것도 깨지지 않습니다.

반면에 정기적으로 열이나 테이블을 삭제하는 것은 의심됩니다. 새로운 기능은 테이블을 제거 할 필요가 없으므로 완전히 계획이없는 사람들의 신호일 수 있습니다.

데이터베이스를 쉽게 버전을 지정하고 마이그레이션 할 수 있고 변경 사항이 문제가되지 않았 음을 입증하는 테스트를받은 경우에는 매우 민첩한 프로세스가 진행된 것입니다.

의견에 비추어 볼 때, 일반적으로 이러한 효과는 민첩한 것으로 자신을 정당화하는 많은 카우보이들입니다. 빠른. 그리고 당신은 우리가 모두 당신의 공포를 즐길 수 있도록 당신은 dailywtf.com에 게시 할 수 있습니다.

StackExchange의 대부분의 답변과 마찬가지로 회신은 '의존적'이어야합니다. 민첩한 개발에서 요구 사항 및 사양은 구현 중에 발견됩니다.

그러나 민첩한 개발이 제공되면 관계형 모델이 제대로 정규화 될 때 관계에 새로운 속성을 추가 할 필요가 거의 없으며, 새로운 모델 은 일반적으로 적절한 모델이 주어지면 오래된 것을 참조해야합니다 .

대부분의 개발자는 시간 제약, 게으름, 무능 또는 쿼리 복잡성으로 인해 DB를 정규화하지 않습니다. 재 정규화에는 기존 데이터의 전송, DAO의 수정 등이 위험 요소를 생성해야합니다.

귀하의 질문에 대답하는 것은 아닙니다. 민첩한 프로세스에서는 정상이 아닙니다.

애자일의 태도에서 비롯된 것으로 보이는 곳 은 애자일의 짧은 반복 설계 / 개발 / 테스트주기와 알려진 요구 사항을 충족하지만 새로운 요구 사항을 충족 할 수 있도록 잘 구성된 경량 솔루션에 대한 애자일의 강조입니다. 최소한의 변화. 이 두 가지를 감안할 때 개발자는 줄을 모르는 것이 무엇인지 모르지만 변경 사항을 알면 취소 할 수없는 방식으로 DB에 영향을 미치지 않아야한다는 것을 말할 수 있습니다. 가능한 가장 "가벼운"방법으로, 간격을두고 몇 가지 "가벼운"변경 사항이보다 영구적이고 안정적인 것으로 리팩토링됩니다.

나는 애자일 이론과 방법론에 가입 한 개발자와 함께 일하지 않았으며, 어떤 이유로 든 스키마에서 테이블을 일상적으로 생성하고 삭제해야한다고 생각했다. 애자일은 슬랩-대시 또는 볼트-온을 의미하지 않습니다. 특정 레코드에 속하는 새로운 데이터 필드를 추가해야하는 스토리가 제공되면 해당 필드를 테이블에 추가합니다. 변경 사항이 문제가 발생하면 이유를 파악하고 필요에 따라 다른 변경을 수행하십시오 (쿼리되는 DB에 열을 추가하여 중단 될 수있는 것들이 거의 없다고 생각할 수 있습니다. 더 큰 문제가 있습니다). 리팩토링은 일반적으로 코드로 제한됩니다. 스키마를 변경하는 것은 일반적으로 코드를 변경하는 것보다 더 복잡한 프로세스이므로 스키마를 변경해야 할 때는 일반적으로 더 신중하게 수행해야합니다. 그리고 프로젝트의 미래 방향에 대한 지식에 적어도주의를 기울였습니다. 데이터베이스의 일부 또는 전부를 재구성해야하는 것은 디자인의 근본적인 실패를 나타냅니다. 애자일 (Agile)이라고해서 프로그램과 데이터 구조를 유기적으로 구축하는 동안 따라야 할 기본 아키텍처와 설계 규칙에 대한 "마스터 플랜"이 없다는 의미는 아닙니다.

이제 애자일에는 지금 "알고있는"내용이 나중에 배울 내용과 모순되는 경우가 있습니다. 시스템에 모든 사람의 주소가 있어야한다는 요구 사항이 있다고 가정하십시오. 이 관계는 1 : 1 관계이므로 대부분의 경우 데이터가 필요하므로 주소 필드를 개인 테이블에 추가하기 만하면됩니다. 일주일 후, 개인이 하나 이상의 주소를 가질 수 있다는 요구 사항을받습니다. 이제는 1 : N 관계이며 올바르게 모델링하려면 필드를 새 주소 테이블로 분할하여 이전 변경 사항을 실행 취소해야합니다. 이것은 특히 고위 개발자들에게는 일상적인 일이 아닙니다. 숙련 된 개발자는 개인이 주소를 가지고 있고, 개념적으로 분리 된 것으로 간주하고, 개인 테이블과 주소 테이블을 작성하여 개인과 주소를 FK 참조를 AddressID에 연결하여 연결합니다. 이와 같은 스키마는 관계의 특성이 변경되면 변경하기가 더 쉽습니다. 전체 "와이드"데이터 테이블을 작성하거나 삭제하지 않고 개인과 주소 간의 관계를 1 : 1에서 1 : N에서 N : N으로 쉽게 수정할 수 있습니다.

애자일 환경에서 작업 할 때 초기 설계에 초점을 두지 않기 때문에 이것이 첫 번째 릴리스에서 큰 문제라고 생각하지 않습니다.

내가 보지 못한 700 개의 테이블이있는 시스템에 대해서는 언급하기가 어렵습니다. 모든 테이블이 필요할 수도 있지만 데이터베이스가 충분히 관리되지 않은 경우 일 수도 있습니다.

민첩한 환경에서도 대규모 시스템의 경우 스키마를 담당하는 사람 / 팀이 여전히있는 것이 일반적입니다.

이러한 변경을 자주 수행하는 경우 (특히 라이브 응용 프로그램에서 테이블과 열을 삭제하는 경우) 이는 경험 부족의 징후 인 것 같습니다. 그들이 따르고 있다고 주장하는 프로세스와는 아무런 관련이 없습니다. 'Agile'은 저장해야 할 데이터와 코드를 시작하기 전에 데이터가 어떻게 관련되어 있는지 생각 하지 않아도됩니다. 그들이 초기 구조의 10-20 % 이상을 변경하는 것을 발견하면, 나에게 그것들은 생각하지 않거나 요구 사항을 분석하고 데이터베이스를 설계하는 경험이 많지 않기 때문에 단순히 나옵니다. 처음에 많은 잘못.

팀이 실제로 카우보이 코딩 인 것처럼 들리지만 코드 또는 데이터베이스 리팩토링에는 아무런 문제가 없습니다. 잃어버린 일이 아니라 새로 배운 현실에 적응하고 있습니다.

팀에 필요한 것은 변경을 시도하고, 테스트를 수행하고, 사용자를 반송하고, 합당한 지 결정하기위한 샌드 박스입니다. 이 시점에서 적절한 회귀 테스트와 함께 의미있는 변경 사항을 스키마에 통합하는 것이 좋습니다.

애자일은 코딩에 관한 것이며 데이터베이스는 코드가 아닙니다. 데이터베이스를 변경하는 것은 집을 리모델링하는 것처럼 취급해야합니다. 사람들은 어떻게 든 민첩한 수단이 이제 나중에 계획 할 것이라는 믿음을 얻었습니다. 민첩한 방법을 사용하더라도 계획, 특히 데이터베이스 디자인만큼 중요한 작업에는 시간이 필요합니다.

저의 마지막 직업은 이런 팀이었습니다. 민첩한 프로세스 요구 사항 변경 사용 때로는 변경 사항에 따라 기존 엔터티에 기존 테이블의 새 열이 생성되는 새 특성이 필요하거나 기존 테이블과의 관계가있는 새 테이블이 생성되는 완전히 새로운 엔터티가 필요합니다. 이러한 종류의 변경 사항은 영역과 함께 제공되며 스키마를 터치하고 싶지 않기 때문에 무시할 수 없습니다. 한 데이터베이스 버전에서 다음 적절한 단위 테스트로 마이그레이션 할 때 데이터의 무결성을 유지하여 성공 여부를 결정합니다.

스키마를 불필요하게 변경하지 마십시오. 예를 들어, 기능에 새 테이블을 작성해야하는 경우 테이블을 체크인하고 테스트 환경에 롤아웃하기 전에 해당 테이블의 정의에 만족하는지 확인하십시오. 데이터가 마이그레이션 된 후 데이터베이스 스키마 변경을 취소해야하는 것은 고통 스러울 수 있습니다.