끔찍하게 디자인 된 데이터베이스 위에 좋은 코드를 작성할 희망이 있습니까?


18

여기 내 처지가 있습니다. 최근에 상속받은 여러 프로그램 중 하나는 백엔드에 끔찍한 데이터베이스로 구축되었습니다. 존경받는 제작자는 분명히 관계 개념을 이해하지 못했습니다. 고유 한 클라이언트 ID로 이름이 지정된 각각의 모든 클라이언트에 대한 테이블입니다. 암호로 명명 된 필드 82 개. 코드는 모두 수십 개의 연결된 인라인 SQL 문으로 절차 적입니다.

동일한 데이터베이스에서 실행되는 중요한 보조 응용 프로그램이 제공되지 않았으므로 처음부터 다시 작성해야했습니다. 나는 유일한 개발자이며, 내 시간의 적어도 절반이 작업에 의해 차지되기 때문에 나의 주요 책임조차도 아닙니다. 지금부터 30 일 동안 피할 수없는 마감일이 설정되었습니다.

내 경험이 없었음에도 불구 하고이 데이터베이스와 기존 응용 프로그램을보다 훨씬 더 잘 설계 할 수 있었을 것이라고 확신하지만 데이터베이스를 변경하고 기존 응용 프로그램을 조정하고 실제로하지 않은 것이 실제로 현실적인 것은 아니라고 생각합니다. 추가 응용 프로그램을 신속하게 작성해야하는 동안 아무것도 중단하지 마십시오.

그래서 내가 끔찍한 데이터베이스에 갇혀 있다고 가정 해 봅시다. 그런 나쁜 구조로 작업해야 할 때, 내가 쓴 내용은 완전히 부러 지거나 새로운 기능이 필요할 때까지 쌓아 두어야 할 기술적 부채 더미에 추가됩니까? 이 상황에 어떻게 접근하고 희망적인 기능을 갖춘 응용 프로그램 외에 좋은 점을 얻을 수 있습니까?

편집 : 누군가 관심이 있다면,이 끔찍한 데이터베이스와 그에서 실행 된 응용 프로그램을 폐기했습니다. 우리는 보조 응용 프로그램 (이 설정에 관여하지 않았 음)의 생성을 궁극적으로 두 명의 다른 계약자에게 아웃소싱하여 결국 우리를 넘어서서 아무것도 달성하지 못했습니다. 나는 오늘날에도 여전히 사용되고있는 3 일 만에 끔찍하고 부분적으로 기능적인 핵을 해킹해야했습니다.


2
특수한 경우 "2 + 2"가 4를 반환하지 않은 라이브러리에 대해 어떻게 코드를 작성하는지 생각해보십시오. 쉽지 않습니다.

8
제가이 모든 것을 듣고있는 것은 30 일 동안 다른 일자리를 찾을 수 있다는 것입니다. careers.stackoverflow.com ;-) 시도
Steven A. Lowe


@ gnat : 심지어 가까이.
Robert Harvey

답변:


27

희망이 있지만, 특히 데이터베이스 디자인이 끔찍하다는 것을 아무도 모르는 경우에는 오르막길이 벌어집니다. 추상화 계층을 사용하여 불쾌감을 추상화하려고 시도 할 수는 있지만 그럴만 한 가치는 없습니다.

내 조언은 데이터베이스 자체에 대해 응용 프로그램 자체가 깨끗하고 적절하게 설계되었다는 충분한 추상화를 만드는 것입니다. 이런 식으로 데이터베이스를 고칠 수 있다면 데이터베이스 디자인 방식을 신경 쓰지 않기 때문에 응용 프로그램에 영향을 미치지 않습니다.

이것은 제로 생각으로 설계된 데이터베이스를 처리 할 때 일반적으로 사용하는 접근법입니다. 게이트웨이 / 리포지토리와 통신 할 일부 서비스 계층이있는 리포지토리 또는 게이트웨이 패턴의 몇 가지 선택 응용 프로그램은 열악한 디자인을 격리하는 데 도움이됩니다.


1
+1 기본적으로 답변을 완전히 읽기 전에 답변에서 동일한 내용을 말했지만 동일한 내용을 다루므로 답변을 삭제할 방법이 없습니다.
Ominus

이 제안을하는 다른 사람들에게 언급했듯이 좋은 제안이지만 데이터베이스 디자인이 불량이라면 응용 프로그램 코드도 불량 일 가능성이 큽니다. 응용 프로그램 코드를 리팩터링 해야하는 경우이 문제가 발생하는 시점을 알 수 없습니다.
maple_shaft

3
@maple_shaft 동의하지만 OP는 데이터베이스와 상호 작용할 새 응용 프로그램을 처음부터 새로 작성하라는 요청을 받았습니다. 그런 경우에는 응용 프로그램을 올바르게 작성하는 것이 좋습니다.
웨인 몰리나

1
@maple_shaft, 응용 프로그램의 유일한 쓰레기 부분은 쓰레기 데이터베이스와 상호 작용하는 부분입니다. 이것이 N-Tier 아키텍처와 SOC의 핵심입니다.
StuperUser 2016 년

1
@maple_shaft 목표는 데이터베이스를 일종의 "블랙 박스 (black box)"에 배치하고 응용 프로그램에 데이터베이스 디자인을 나타내는 것이 아니라 이상적으로 이상적인 인터페이스를 제공하는 것입니다.
Michael Dean

10

모든 DB 작업을 처리하는 인터페이스 계층을 구축 한 다음 앱과 인터페이스를 작성하십시오. 데이터베이스가 "고정"된 경우 "인터페이스"를 바꾸거나 업데이트하면됩니다. 이 접근 방식은 나쁜 데이터베이스 또는 다른 응용 프로그램을 제공하고 엉망이 될 수없는 데이터베이스를 처리 할 때 많은 시간을 절약했습니다.


자신의 답변을 어떻게 삭제할 수 있습니까? 그렇지 않습니까?
Ominus

자신의 답변을 삭제할 수 있습니다. 당신은 색조 배경으로 그들을 계속보고 "소유자에 의해 삭제"와 같은 것을 말할 것입니다. 귀하 외에는 중재자 권한을 가진 사람 만 볼 수 있습니다.
Marjan Venema 2016 년

@Ominus : 가능해야하지만 왜하고 싶습니까? 당신은 3 upvotes있어!
FrustratedWithFormsDesigner 2016 년

1
@Marjan : 중재자 및 10K 이상 응답자
Jerry Coffin 2016 년

1
이 답변을 왜 삭제 하시겠습니까? 나는 그것이 훌륭한 해결책이라고 생각합니다.
Jim G.

6

아야 .. 당신은 악몽의 혼란을 물려 받았습니다. 조직에 사용할 수 있도록 30 일이 있고 반나절은 운영 업무에 사용됩니까?

나는 당신이 리팩토링 할 수는 있지만 확실히 그 시간 안에는 아니라고 확신합니다.

귀하의 질문에 대답하기 위해 실제로 그러한 디자인에 좋은 코드를 작성할 수 있다고 생각하지 않습니다. 기술 부채가 이미 너무 많습니다. 내가 당신이라면 내가 할 수있는 기능을 해킹하고 나중에 더 나은 시간을 보내고 팀에 더 많은 사람들이있을 때 나중에 완전한 리팩토링을 누르십시오.

리팩토링을 위해 조심스럽게 밀어 넣으십시오. 때로는 고소득층이 제품 소스 코드와 소유권을 구매하기로 결정하고 쓰레기에 돈을 완전히 낭비한다고 생각하고 싶지 않습니다. 이것은 내가 가진 한 직업에서 저에게 해당되었습니다. 불행히도 관리자는 이와 같은 소프트웨어 구매에 대한 결정을 내릴 수 있으며, 구매 대상을 평가하고 유지 관리가 가능하고 많은 기술 부채가 있는지 여부를 확인하기 위해 기술적 개입을받지 않습니다. 이 경우 나쁜 결정은 정치적 결정이며 리팩토링을 추진하면 직업이 위태로워 질 수 있습니다.


다른 사람들이 프로그래밍에 익숙하지 않더라도이 코드베이스의 품질이 유지 보수성에 어떤 영향을 미치는지 분명히했습니다. 그들은 모든 것을보다 적합한 상태로 만들기 위해 엄청난 리팩토링 노력을 기울이고있어서 직업을 위태롭게 할 위험은 없지만 이번 달에 일어날 것이라고는 생각하지 않습니다.
존 스트라 카

3
때때로 프로젝트에 대한 첫 경험으로 성공적인 해킹을 수행하면 동일한 응용 프로그램에 대해 이후 프로젝트에서 리팩토링 할 수있는 유연성을 얻을 수 있습니다. 슬프지만 사실이야. 먼저 그들은 급진적 인 변화를 고려하기 전에 당신이 무엇을하고 있는지 알고 있어야합니다. 포스터는 확실한 위치에 있습니다.
HLGEM

1
@ 존, 이것이 리팩토링의 필요성을 인식하는 것이 좋습니다. 좋은 장기 관리의 표시이며 실제로 리팩토링하는 첫 번째 단계입니다.
maple_shaft

3
훌륭하고 현실적인 답변을 얻으려면 +1하십시오. 당신은 한 달이 있지만, 반 시간 동안 일하기 때문에 실제로 반달입니다. 주말에 이륙하는지 여부에 따라 11-15 일이 소요됩니다. 나는 그것을 말하는 것을 싫어하지만, 최선의 방법은 가능한 한 함께 모여서 나중에 개선 또는 다시 작성하는 방법에 대해 메모하는 것입니다. 특히 경영진이 리팩토링을 수행하고 있기 때문입니다.
밥 머피

6

다른 코드와 마찬가지로 데이터베이스를 리팩토링 할 수 있습니다. 테스트를 작성하고 작성해야하는 코드의 영향을받는 부분을 수정하여 다른 부분이 없는지 확인하십시오. 다른 리팩토링과 마찬가지로 한 번에 하나의 작은 비트를 수행하십시오. 혼란을 정리하는 데 도움이되는 데이터베이스 리팩토링에 대한 좋은 책이 있습니다. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

다른 것들도 있지만 개인적 으로이 기술을 읽고 작업했습니다.

또한 쿼리하기가 더 쉬운 구조로 전환하기 위해 뷰를 생성하여 데이터베이스를 쿼리하는 방법을 재구성 할 수 있습니다.


이것은 모두 훌륭하지만 데이터베이스 디자인이 엉망이라면 응용 프로그램 코드도 가치가 없다는 강한 의혹이 있습니다.
maple_shaft

@maple_shaft, 훌륭한 응용 프로그램 개발자조차도 끔찍한 데이터베이스를 디자인하는 것은 내 경험이지만 가능할 수 있습니다. 점진적인 리팩터링만으로도 혼란을 해결할 수 있지만, 나는 그가 좋아한다고 확신하더라도 그것을 완전히 바꿀 수는 없습니다.
HLGEM

@HLGEM +1, 이것이 좋은 포인트입니다. 응용 프로그램 코드가 제대로 설계되어 있으면 조언이 적절합니다. 부분적으로 리팩토링하는 것이 가장 좋은 방법 일지 모르지만 내 경력 전체에서 그 일을 성공적으로 보지 못했습니다. 그러나 프로젝트 관리가 좋지 않았기 때문일 수 있습니다.
maple_shaft

5

비용을 최대한 활용하려면 업데이트 가능한 뷰를 만들어 "관계 성"을 복원하고보다 의미있는 열 이름을 제공하십시오.


이것은 좋은 시작이 될 것입니다. 데이터베이스가 비정규 화되면 트리거 또는 저장 프로 시저를 추가하여 비정규 화로부터 응용 프로그램을 격리합니다.
케빈 클라인

4

한 가지 가능성은 원하는 방식으로 구조화 된 (최소한 더 가까운) 두 번째 데이터베이스를 설정하고 두 데이터베이스간에 복제를 설정하는 것입니다. 그런 다음 새 데이터베이스에 대해 코드를 작성하고 기존 데이터베이스 (및 애플리케이션)를 그대로두고 더 많은 시간이있을 때 처리 할 수 ​​있습니다.

정직하게, 그것은 여전히 열려있어 많은 당신이 ~ 일 15 일에 그렇게 할 수 있는지 여부를 질문. 특히, 양방향 복제가 필요한지 (즉, 새 응용 프로그램이 실제로 데이터를 업데이트 할 것인지) 단 한 가지 방법 (새 응용 프로그램으로 사람들이 데이터를 볼 수있게하는지)에 따라 달라질 수 있습니다. 후자의 경우는 물론 다루기가 훨씬 쉽다.

양방향 복제가 필요한 경우 작업을 수행 할 시간이 충분하지 않을 수 있습니다. 특히, 구조를 실질적으로 변환하는 양방향 복제는 결코 쉬운 일이 아니며, 사용 가능한 도구는 종종 구조를 제대로 지원하지 못합니다 (예 : 모든 데이터 변환을 위해 모든 SQL을 양방향으로 모두 작성해야 함).

당신은 단지 하나의 방법이 필요하면, 바로 그 지점에서의 수도 수있는에 국경. 또한 돈을 쓸 수 있는지 여부에 따라 크게 달라질 것입니다. 이 작업 을 정확하게 처리 하는 데이터웨어 하우징 응용 프로그램은 상당히 빠르고 쉽습니다. 관리하기는하지만 대부분은 싸지 않습니다 .


+1, 모든 응용 프로그램 데이터 액세스 코드가 다른 계층과 올바르게 분리되어 있고 새 스키마와 함께 작동하도록 데이터 액세스 코드를 리팩터링 할 수있는 한 좋은 아이디어가 될 수 있습니다
maple_shaft
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.