민첩한 개발에서 데이터베이스 전에 플랫 파일로 지속성을 시도해야합니까?

누군가는 민첩한 개발에서 지속성 방법과 같은 세부 사항보다 정책 및 응용 프로그램 논리가 더 중요하므로 지속성 결정은 마지막에 내려야한다고 나에게 설명했습니다. 따라서이 방법의 약점이 분명해질 때까지 플랫 파일과 같은 단순한 지속성으로 시작하고 관계형 데이터베이스를 사용하여 지속성을 변경하는 것이 좋습니다.

이것이 사실입니까, 아니면 개념을 잘못 이해 했습니까? 이것이 민첩한 팀이 일반적으로 응용 프로그램을 구축하는 방법입니까? 이에 대한 이론적 근거는 무엇이며 언제이 접근 방식을 취해서는 안됩니까?

전달되는 개념은 확실히 민첩하고 관련성있는 부분이며, 마지막 책임있는 순간까지 일을 추진한다는 생각입니다.

그러나 실제로 사용 된 예제는 다음과 같이 완전히 잘못된 가정에 의존합니다.

RDBMS를 사용하는 것보다 플랫 파일 데이터베이스를 구현하는 것이 더 쉽고 적은 작업입니다. - 종종 완전히 거짓

예는 다음과 같아야합니다. 지속성 계층은 부적합한 결정이 내려 질 때까지 가장 간단한 구현으로 유지됩니다.

많은 개발 팀의 경우 데이터베이스를 작동시키는 것은 1 ~ 2 시간 (또는 ORM을 사용하는 작은 데이터베이스의 경우 15 분)의 문제이지만, 계속 방해하지 않아도되는 플랫 파일 데이터베이스는 UI에서 테이블을 생성하고 몇 개의 열을 추가 한 다음 ORM이 모든 것을 생성하는 것처럼 데이터베이스가 단순 할 수있는 경우 모든 찾기 및 데이터 테이블 생성 유형 코드를 수동으로 작성해야하기 때문에 엄청난 고통과 성가심 그렇지 않으면 필요합니다.

또한 지속성 계층을 시작으로 알지 못하는 경우 팀에서 잘 알고있는 공통 RDBMS로 시작하여 나중에 플랫 파일에서 RDBMS로 변경하는 것이 이후보다 훨씬 더 큰 경우보다 적절한 조치입니다. 한 RDBMS에서 다른 RDBMS로 변경. 대부분의 일반적인 RDBMS에서 다른 것과 같은 것으로 변환하는 도구와 팁이 많이 있습니다. 플랫 파일에서 지정된 RDBMS로 변환하는 도구는 극히 적으며, 플랫 파일에는 이전에 자체 라이브러리를 제외하고 툴링이 작성되지 않은 독점 형식이 있습니다.

요약 : 개념은 정확하고 정확하지만 예제는 매우 크고 종종 (거의 항상) 부정확 한 가정을 기반으로합니다 .

DB를 사용할 것이라는 것을 알고 있으므로 플랫 파일을 처리하는 코드를 작성하는 데 별다른 의미가 없습니다. 일부 읽기 전용 CSV를 사용하여 몇 번의 반복 작업을 수행 할 수도 있지만, 버릴 것으로 알고있는 코드를 작성하는 것이 빠릅니다.

SQLite (파일에 저장된 서버리스 SQL 데이터베이스를 제공하는 라이브러리) 와 같은 것을 사용하여 초기 복잡성을 단순화하기 위해 할 수있는 한 가지 방법 . 유연한 유형 시스템을 갖추고 있으므로 스키마를 심각하게 커밋 할 필요가 없으며 DB를 구성 / 연결 및 재구성 할 서버가 파일을 삭제하는 것만 큼 간단합니다. 또한 필요한 경우 버전 제어에 코드와 함께 DB 이미지를 포함시킬 수 있습니다.

예를 들어, 개념 자체가 아니라 개념을 설명하는 데 사용됩니다.

개념은 당신이 마지막 책임 순간 까지 아키텍처 결정을 내리지 않고 나중에 는 결정하지 않는다는 것 입니다. 그러나 실제로는 초기에 사용할 데이터베이스를 결정하는 경우가 많습니다. 완벽하지는 않지만 사실입니다.

일단 결정되면 적극적으로 피하지 마십시오. 기존 데이터베이스에 무언가를 저장하는 것은 플랫 파일에 저장하는 것만 큼 쉽습니다.

그러나 Linux의 MySql에서 Windows의 SQL Server로 변경하는 것은 플랫 파일에서 Windows의 SQL Server로 변경하는 것만 큼 간단하지 않을 수 있습니다. 그게 진짜 요점입니다. 따라서 최종 솔루션에 대해서는 의문의 여지가 없지만 가장 간단한 옵션을 선택하여 변경 사항을 고려하십시오. 결정이 내려지면 결정을 고수하십시오.

무엇 을 유지하고 있습니까?

저는 민첩한 팀에 속해 있으며 한 응용 프로그램의 경우 거의 모든 것을 데이터베이스에 유지합니다. 이 응용 프로그램이 수행을 위해 우리는 다음 많이 없을 것입니다하지 않은 경우, 당신은주의한다 - 데이터베이스에 일을 지속하는 것은 그것의 큰 부분이다 존재 이유 .

그래서 : 당신은 무엇을 유지하고 있으며 응용 프로그램은 무엇을합니까? 응용 프로그램이 실제로 그렇지 않은 경우 데이터가 유지되는 위치를 신경 쓰지 플랫 파일 대 데이터베이스에 대한 결정을 내리는 작은 계층을 작성할 수 있습니다 (결정 파일은 어딘가에 구성 파일에 저장 가능). 응용 프로그램과 데이터를 평가하고 특정 경우에 데이터베이스 지속성에 시간을 투자하거나 플랫 파일을 읽거나 쓰는 것이 적합한 지 결정해야한다고 생각합니다 ( 개발 시간면에서 더 빠를 것 입니다).

많은 사람들이 민첩성의 측면이 향후 기능에 대해 미리 계획해서는 안된다는 의미로 오해하고 있습니다. 더 이상 진실에서 멀어 질 수는 없습니다. 당신이하지 않는 것은 미래의 기능을 계획하여 고객에게 가치를 제공하는 것을 지연시키는 것입니다.

지속성과 같은 것에 적용되는 방법은 응용 프로그램에 따라 크게 다릅니다. 내 현재 취미 프로젝트 중 하나는 계산기입니다. 결국, 나는 사용자 정의 상수와 함수를 저장하고 프로그램을 닫을 때 상태를 저장하고 싶습니다. 지속성이 필요하지만 어떤 형태를 취해야할지 생각조차하지 못했습니다. 내 프로그램은 지속성없이 사용할 수 있으며 지금 추가하면 첫 번째 릴리스에 상당한 지연이 추가됩니다. 나는 그것이 완벽하기를 기다리는 동안 오히려 적은 것보다 적은 기능을 가진 작동하는 계산기를 원할 것입니다.

또 다른 취미 프로젝트는 비디오 및 사진 색상 보정입니다. 이 응용 프로그램은 진행중인 작업을 저장하지 않고 완전히 사용할 수 없으며 전체 코드에 필요한 코드가 널리 퍼져 있습니다. 처음부터 제대로 이해하지 못하면 변경하기가 매우 어려울 수 있으므로 지속성에 많은 노력을 기울였습니다.

대부분의 프로젝트는 어딘가에있을 것이지만, 지금 추가 노력이 거의 또는 전혀 추가되지 않는다면 향후 기능 계획에 대해 나쁘게 느끼지 않아야합니다. 데이터베이스는 복잡 할 수 있지만 대부분의 복잡성은 테스트를 거친 견고한 인터페이스 뒤에 숨겨져 있습니다. 데이터베이스에서 무료로 제공하는 모든 기능으로 인해 응용 프로그램에서 수행해야하는 작업은 플랫 파일보다 데이터베이스에 훨씬 적을 수 있습니다. 데이터베이스 서버의 번거 로움을 아직 처리하지 않으려면 SQLite와 같은 "하이브리드"옵션이 있습니다.

나는 당신이 잘못된 가치에 집중하고 있다고 생각합니다. 민첩하게 비즈니스 가치에 중점을 둡니다. 일부 최종 사용자에게 비즈니스 가치를 제공하기 위해 제품을 만듭니다.

퍼시스턴스 레이어를 늦게 만들거나 그 길을 따라 가면 비즈니스 가치를 고객에게 제공하는 전략이됩니다. 나는 "민첩한"이라는 용어 자체가 당신이 어느 쪽을해야하는지 지시한다고 믿지 않습니다.

데이터 저장 전략 지연에 대한 관점은 Robert C. Martin (민첩한 선언문의 저자 중 한 사람) 이이 프레젠테이션 에서 옹호 합니다.

아주 좋은 프리젠 테이션입니다. 시청하시는 것이 좋습니다.

그러나 나는 그것에 동의하지 않습니다! 적어도 어느 정도는.

사용자 스토리에 지속되어야하는 데이터가 포함되어 있고 실제로 어떤 유형의 지속성이 구현되지 않은 경우 "완료"에 대한 사용자 스토리를 호출 할 수 있다고 생각하지 않습니다.

제품 소유자가 지금 가동 할 시간이라고 결정하면 그렇게 할 수 없습니다. 또한 프로젝트 후반까지 지속성을 구현하기 시작하지 않은 경우 지속성 계층을 구현하는 데 걸리는 시간에 대한 정보도 없으므로 주요 프로젝트 위험이 있습니다.

내가 작업 한 민첩한 프로젝트는 데이터 액세스 전략을 지연시키지 않았습니다. 그러나 연결이 해제되었으므로 변경 될 수 있습니다. 그리고 전체 데이터베이스 스키마는 사전에 설계되지 않았습니다. 테이블과 열은 결국 비즈니스 가치를 제공하는 저장된 사용자를 구현하기 위해 필요한대로 생성됩니다.

새로운 프로젝트를 시작할 때 어떤 질문에 먼저 대답해야하는지 판단하려면 경험과 판단이 필요합니다.

최종 제품을 여전히 알 수없는 경우, 빌드 / 프로토 타이핑을 신속하게 파악하는 데 도움이되며, 민첩하게 반복하면 도움이됩니다. 물론 지속성 구현이 이해 관계자에게 전달하는 것보다 시간이 오래 걸리는 프로세스를 늦게 발견하는 등의 위험이 발생할 수 있습니다.

최종 제품이 잘 알려진 경우 애플리케이션에서 지속성이 어떻게 작동하는지 이해하는 것이 초기에 아는 것이 더 중요 할 수 있습니다. 개발 프로세스 후반에 제품 사양에 문제가있을 위험이 있습니다.

플랫 파일은 간단하지 않습니다!

그들은 저장을 허용하고 그게 전부입니다. 데이터 구조, 액세스 경로 등은 모두 귀하에게 달려 있으며,이를 잘못 판단하는 방법은 여러 가지가 있습니다.

데이터베이스가 존재하는 이유가 있으며 그 중 하나는 개발자를 위해 일을 단순화하기위한 것입니다.

내 개발의 대부분은 대기업 내의 대규모 시스템에서 수행됩니다. 우리는 추가 설계 또는 개발을 진행하기 전에 항상 완벽하고 신중한 데이터 모델을 보유하고 있습니다. 데이터 모델을 사용하면 문제를 이해하고 깔끔하게 구현할 수 있습니다.

데이터 모델을 미리 생성하여 잊어 버린 데이터 항목, 불일치 한 데이터 구조 및 기타 악몽을 피할 수 있습니다.

데이터 모델이 끝날 때까지 데이터베이스 기술을 실제로 선택할 수 있습니다. 그러나 대부분의 "지속성"기술은 밀접한 프로그래밍과 디자인 스타일에 가깝습니다. 관계형 데이터베이스를 코딩하고 나중에 흐린 키 값으로 전환하기로 결정한 경우 코드의 절반을 완전히 다시 작성해야합니다.

플랫 파일로 시작하고 관계형 DB로 전환하면 개발자가 열악한 데이터베이스를 구현하는 데 시간을 낭비하므로 코드의 절반을 버릴 수 있습니다.

데이터베이스 전에 플랫 파일로 지속성을 시도해야합니까?

예, 시도해야합니다. 특히 전에 시도한 적이 없다면. 그것이 어떻게 되었든, 당신은 무언가를 배울 것입니다.