최근에 나는 프로그램 개발 중에 정기적으로 테이블과 열을 정기적으로 만들고 삭제하면서 새로운 기능을 수행하고 민첩한 개발 프로세스를 사용할 때 이것이 정상이라고 말하면서 사물을 정당화한다고 언급 한 개발자와 토론을했습니다.
내 배경의 대부분이 폭포 개발 환경에 있기 때문에 이것이 애자일 개발에서 실제로 적절하다고 생각되는지 또는 이것이 프로그램 아키텍처 또는 애자일 프로세스의 후속으로 근본적인 문제의 징조인지 궁금합니다.
답변
날마다 “민첩한”생각이 나쁘고, 혼란스럽고, 서두르고, 바지와 동의어가되고 있다는 것이 나에게 점점 더 명백 해지고 있습니다. 그리고 그 중 어느 것도 내가 이해하는 것처럼 애자일 접근 방식과 호환되지 않습니다.
효과적이고 반복 가능한 민첩한 프로세스를 갖는 것은 쉬운 일이 아니며, 그것이 더 나은 제품으로 이어질 수는 있지만 수행해야 할 총 작업량을 본질적으로 줄이는 것으로 생각하지 않습니다.
데이터베이스를 “리팩토링”할 시간이 없다고 말하면 데이터베이스의 버전 관리 및 마이그레이션을 설정할 시간이 없을 것입니다. 아마도 일련의 기능 테스트를 작성하는 데 시간이 걸리지 않았을 것입니다. 그 모든 것들은 성공을 향한 확실한 민첩한 프로세스를 생각할 때 내가 생각하는 것입니다.
결국 애자일은 한 단어 일뿐입니다. 당신이 매일하고있는 일이 당신의 성공 여부를 결정합니다.
답변
디자인이 발전함에 따라 테이블을 작성하고 삭제하는 것은 드문 일이 아니지만 데이터베이스가 실제로 모든 테이블을 사용하도록하기 위해 일부 정리가 필요할 수 있습니다.
예, 애자일은 리팩토링에 관한 것이지만, 이제 시스템이 리팩토링하기에 너무 크다고 말하는 경우, 애자일 수행을 중단했으며 이제는 카우보이 프로그래밍입니다. 개발팀은 그렇게 부르기를 좋아하지 않지만 그것이하는 일입니다. 움직이는 모든 것을 촬영하는 범위를 타고.
DBA는 개발과 애자일 개발을 이해하는 DBA를 얻는 데 도움이됩니다. 개발팀은 교도소에 갇히지 말고 재조정해야합니다.
답변
일반적으로 프로그래밍과 데이터베이스 관리가 엄격하게 분리되지 않은 프로세스에서는 종종 새 테이블을 만들고 새 열을 추가하는 것이 매우 일반적입니다. 새로운 기능은 새로운 데이터를 생성하여 어딘가에 가야합니다. 이를 피하기 위해 너무 엄격하게 시도하면 내부 플랫폼 모델이 생깁니다 .
잘 작성된 소프트웨어는 이러한 새 데이터베이스 개체를 거의 인식하지 못하므로 일부 테이블의 새 열로 인해 아무 것도 깨지지 않습니다.
반면에 정기적으로 열이나 테이블을 삭제하는 것은 의심됩니다. 새로운 기능은 테이블을 제거 할 필요가 없으므로 완전히 계획이없는 사람들의 신호일 수 있습니다.
답변
데이터베이스를 쉽게 버전을 지정하고 마이그레이션 할 수 있고 변경 사항이 문제가되지 않았 음을 입증하는 테스트를받은 경우에는 매우 민첩한 프로세스가 진행된 것입니다.
의견에 비추어 볼 때, 일반적으로 이러한 효과는 민첩한 것으로 자신을 정당화하는 많은 카우보이들입니다. 빠른. 그리고 당신은 우리가 모두 당신의 공포를 즐길 수 있도록 당신은 dailywtf.com에 게시 할 수 있습니다.
답변
StackExchange의 대부분의 답변과 마찬가지로 회신은 ‘의존적’이어야합니다. 민첩한 개발에서 요구 사항 및 사양은 구현 중에 발견됩니다.
그러나 민첩한 개발이 제공되면 관계형 모델이 제대로 정규화 될 때 관계에 새로운 속성을 추가 할 필요가 거의 없으며, 새로운 모델 은 일반적으로 적절한 모델이 주어지면 오래된 것을 참조해야합니다 .
대부분의 개발자는 시간 제약, 게으름, 무능 또는 쿼리 복잡성으로 인해 DB를 정규화하지 않습니다. 재 정규화에는 기존 데이터의 전송, DAO의 수정 등이 위험 요소를 생성해야합니다.
답변
귀하의 질문에 대답하는 것은 아닙니다. 민첩한 프로세스에서는 정상이 아닙니다.
애자일의 태도에서 비롯된 것으로 보이는 곳 은 애자일의 짧은 반복 설계 / 개발 / 테스트주기와 알려진 요구 사항을 충족하지만 새로운 요구 사항을 충족 할 수 있도록 잘 구성된 경량 솔루션에 대한 애자일의 강조입니다. 최소한의 변화. 이 두 가지를 감안할 때 개발자는 줄을 모르는 것이 무엇인지 모르지만 변경 사항을 알면 취소 할 수없는 방식으로 DB에 영향을 미치지 않아야한다는 것을 말할 수 있습니다. 가능한 가장 “가벼운”방법으로, 간격을두고 몇 가지 “가벼운”변경 사항이보다 영구적이고 안정적인 것으로 리팩토링됩니다.
나는 애자일 이론과 방법론에 가입 한 개발자와 함께 일하지 않았으며, 어떤 이유로 든 스키마에서 테이블을 일상적으로 생성하고 삭제해야한다고 생각했다. 애자일은 슬랩-대시 또는 볼트-온을 의미하지 않습니다. 특정 레코드에 속하는 새로운 데이터 필드를 추가해야하는 스토리가 제공되면 해당 필드를 테이블에 추가합니다. 변경 사항이 문제가 발생하면 이유를 파악하고 필요에 따라 다른 변경을 수행하십시오 (쿼리되는 DB에 열을 추가하여 중단 될 수있는 것들이 거의 없다고 생각할 수 있습니다. 더 큰 문제가 있습니다). 리팩토링은 일반적으로 코드로 제한됩니다. 스키마를 변경하는 것은 일반적으로 코드를 변경하는 것보다 더 복잡한 프로세스이므로 스키마를 변경해야 할 때는 일반적으로 더 신중하게 수행해야합니다. 그리고 프로젝트의 미래 방향에 대한 지식에 적어도주의를 기울였습니다. 데이터베이스의 일부 또는 전부를 재구성해야하는 것은 디자인의 근본적인 실패를 나타냅니다. 애자일 (Agile)이라고해서 프로그램과 데이터 구조를 유기적으로 구축하는 동안 따라야 할 기본 아키텍처와 설계 규칙에 대한 “마스터 플랜”이 없다는 의미는 아닙니다.
이제 애자일에는 지금 “알고있는”내용이 나중에 배울 내용과 모순되는 경우가 있습니다. 시스템에 모든 사람의 주소가 있어야한다는 요구 사항이 있다고 가정하십시오. 이 관계는 1 : 1 관계이므로 대부분의 경우 데이터가 필요하므로 주소 필드를 개인 테이블에 추가하기 만하면됩니다. 일주일 후, 개인이 하나 이상의 주소를 가질 수 있다는 요구 사항을받습니다. 이제는 1 : N 관계이며 올바르게 모델링하려면 필드를 새 주소 테이블로 분할하여 이전 변경 사항을 실행 취소해야합니다. 이것은 특히 고위 개발자들에게는 일상적인 일이 아닙니다. 숙련 된 개발자는 개인이 주소를 가지고 있고, 개념적으로 분리 된 것으로 간주하고, 개인 테이블과 주소 테이블을 작성하여 개인과 주소를 FK 참조를 AddressID에 연결하여 연결합니다. 이와 같은 스키마는 관계의 특성이 변경되면 변경하기가 더 쉽습니다. 전체 “와이드”데이터 테이블을 작성하거나 삭제하지 않고 개인과 주소 간의 관계를 1 : 1에서 1 : N에서 N : N으로 쉽게 수정할 수 있습니다.
답변
애자일 환경에서 작업 할 때 초기 설계에 초점을 두지 않기 때문에 이것이 첫 번째 릴리스에서 큰 문제라고 생각하지 않습니다.
내가 보지 못한 700 개의 테이블이있는 시스템에 대해서는 언급하기가 어렵습니다. 모든 테이블이 필요할 수도 있지만 데이터베이스가 충분히 관리되지 않은 경우 일 수도 있습니다.
민첩한 환경에서도 대규모 시스템의 경우 스키마를 담당하는 사람 / 팀이 여전히있는 것이 일반적입니다.