표본 크기가 프로젝트 길이에 영향을 미치지 않는다고 설명하는 방법

일반적으로 소스 데이터베이스에서 대상 데이터베이스로 데이터를 복사 한 다음이 데이터 등을 동기화하는 여러 가지 추가 응용 프로그램을 설정하는 대규모 엔터프라이즈 프로젝트가 있습니다.

마지막 프로젝트에는 250,000 개의 항목 (데이터 행)이 포함되었습니다. 다음 프로젝트에는 4,000 개의 항목 만 포함됩니다. 프로젝트 관리자 / 사업자들은 프로젝트가 마지막 프로젝트 크기의 일부에 불과하기 때문에 프로젝트 완료 시간의 1/10이되어야한다고 생각합니다.

한 시스템에서 다른 시스템으로 데이터를 전송하기 위해 코드를 작성하는 것은 숫자 항목에 관계없이 동일한 양을 취한다는 것을 설명하는 데 사용할 수 있는 좋은 비유 는 무엇입니까? 관점.

그들에게이 나라의 외곽 지역에 새로운 4 차선 고속도로를 건설하는 것과 같다고 말합니다. 그 도로가 하루에 100 대 또는 하루 1000 대에 의해 사용 되든, 도로를 만드는 노력은 거의 같습니다.

물론, 하루에 1,000,000 대의 자동차를 지원할 경우 도로를 좀 더 견고하게 만들어야하지만, 어느 쪽이든 같은 나무를 잘라 내고 같은 산을 뚫고 같은 양을 밟아야합니다 이 활동은 많은 차량이 도로를 사용하더라도 고정 된 비용입니다.

그들에게 계산기를주고 시간이 얼마나 걸리는지 1238783423을 9858238483에 더 해달라고 부탁하십시오. 그런 다음 그들에게 3423에 8483을 더해달라고 대답하면 약 100000 배 더 빨리 답변 할 것으로 예상합니다.

또한 개발 시간이 아닌 소프트웨어를 실행하는 데 걸리는 시간에 영향을 미치는 데이터 양에 대해 설명 할 수도 있습니다 .

관리자 발언에 넣습니다.

초당 1 개 위젯으로 위젯을 작성하기 위해 머신을 빌드하는 경우 100 위젯 또는 10000 위젯을 작성하는 데이를 사용하더라도 머신 자체를 빌드하는 데 동일한 시간이 걸립니다.

차이점은 런타임이 아니라 빌드 시간입니다.

모든 관리 클래스는 가상 위젯 팩토리에서 이와 같은 문제점에 대해 작업합니다.

비유를 사용하지 마십시오. 그냥 설명해주세요.

• 매우 적은 수의 항목 (10?)의 경우 수동으로 변환하는 것이 가장 저렴합니다. 프로그램을 전혀 쓰지 마십시오.
• 소수의 항목 (100?)의 경우 프로그램을 작성하는 것이 좋습니다. 이론적으로는 가능하지만 작은 데이터 세트에는 실제로 나타나지 않는 데이터의 일부 순열을 무시하여 비용을 절약 할 수 있습니다. 또는 프로그램이 거부 할 수있는 작은 숫자로 표시되면 수동으로 변환 할 수 있습니다. 코너 케이스가 실제로 데이터에 나타나는지 확인하기 위해 데이터에 대한 빠른 분석을 실행하는 것이 가능합니다. 표시되지 않으면 무시할 수 있습니다.
• 이 지점을 통과하면 실제 데이터 크기는 영향을 미치지 않습니다. 가능한 모든 입력을 처리 할 수있는 심각한 프로그램을 작성해야합니다. 이 프로그램은 1,000 개 항목 또는 100,000 개를 처리 할 수 ​​있습니다. 실행하는 데 시간이 더 걸립니다.

교육은 이야기하는 것보다 낫습니다 :)

실제로는 비유가 아니지만, 여전히이 주장을 다루는 좋은 방법이 있다고 믿습니다. 치명적인 결함이 있음을 보여줍니다.

이전 프로젝트에는 데이터를 수정하여 복사하는 작업이 포함되었습니다.

내가 제대로한다면, 그것은 몇 달 안에 100 명의 회계사로 구성된 팀입니다. 그렇다면 왜 문제에 소프트웨어 개발자를 던졌습니까?

생성 한 소프트웨어는 1 천만 또는 1 천만 개의 데이터를 처리할지 여부를 신경 쓰지 않기 때문에 (정확하지는 않지만 관리자가 O(n)복잡성을 걱정하는 것은 의심됩니다 ). 따라서 더 저렴하고 빠르며 깨끗합니다 (오류가 발생하기 쉬운 프로세스).

더 급진적 인 경우 소프트웨어 팀의 속도가 마음에 들지 않으면 항상 회계사에게 직접 전화하여 작업을 수행 할 수 있다고 제안 할 수도 있습니다.

이를 통해 마지막 프로젝트를 개발하는 동안 관리자의 삶이 훨씬 쉬워졌으며 이제는 동일한 논리를 적용하여 다음 소프트웨어가 10 백만 또는 4 대에서 작동하는지 여부를 신경 쓰지 않아도됩니다. 000 행, 그들은 갑자기 잊어 버립니다.

귀하의 경우 관리자는 단순히 추정 게임을 하고 4000과 250000의 차이를 지적하고 일부 '죄책감'을 기대함으로써 팀이 더 빨리 일하도록 강요하려고합니다. 내가 틀렸을 수도 있지만, 이전에이 일을 보았습니다.

프로그래머 팀 (실제로는 모든 유형의 크리에이티브 팀)을 관리하는 끔찍한 방법이며 누구에게도 도움이되지 않습니다.

나는 당신이 비유를 요구한다는 것을 알고 있지만, 그것이 잘못된 기술이라고 생각합니다.

다른 사람들이 전달에서 언급했듯이 데이터 크기는 빌드 시간이 아니라 런타임에 영향을 미친다는 점을 강조해야한다고 생각합니다 . 따라서 그것들을 분해하십시오. 실제로 두 개의 하위 프로젝트, 즉 빌드와 실행이 있습니다. 건물 프로젝트는 (대부분) 실행되는 데이터의 양과 관련이 없으며 데이터 유형 만 중요합니다 . 런타임과 관련하여 데이터 크기에 따라 요소를 고려할 수 있습니다 (사소한 고정 오버 헤드 제외).

마치 멜버른으로 운전해야하는 것과 같습니다. 그러나 먼저 차를 만들어야합니다.
물론 시드니로 운전하는 것이 더 빠를 수도 있지만 차량을 만드는 데는 같은 시간이 걸립니다.
_{좋아, 나는 결국 당신에게 비유를 주었다.}

전화 일까? 고객이 맞춤형 전화를 원합니다. 하루에 0 번 전화를하거나 하루에 100 번 전화를 걸면 전화를 만드는 데 같은 시간이 걸립니다.

전화가 전송하는 데이터는 프로그램에서 복사 한 데이터와 유사합니다.

관리자는 실시간을 프로그램의 실제 런타임과 혼동하는 것 같습니다. 그러나 그들의 오해는 다를 수 있습니다. 그들은 관련된 "필드"가 더 적다고 가정 할 수 있습니다. 적은 데이터 레코드가 아닙니다. 100000 개의 개별 데이터 필드가있는 경우 10 개의 필드에 비해 막대한 노력이 필요합니다. 시스템에서 시스템으로 더 많은 매핑 작업. 이 경우 실제로 정확할 수 있지만 여전히 일정한 오버 헤드가 발생하며 시간을 얻기 위해 필드 수로 나눌 수는 없습니다.

내가 설명하는 것처럼 데이터에는 길이와 너비가 2 차원입니다. 길이는 레코드 수이고 너비는 모든 테이블의 총 열 수입니다.

이제 데이터를 가져 오려면 구멍을 통해 블록을 얻는 것과 같습니다. 가장 작은 치수에 충분한 구멍을 뚫고 블록을 통과시켜야합니다.

이제 천만 및 천만으로 가장 작은 치수는 여전히 너비입니다. 따라서 구멍을 만드는 데 걸리는 시간이 결정되는 폭입니다.

은유를 완성하려면 더 작은 길이 인 경우 수동으로 데이터를 입력하면됩니다

매주 수백 개의 클라이언트 파일을 가져옵니다.

내가 찾은 한 가지는 작은 파일이 일반적으로 다음과 같은 이유로 데이터 가져 오기를 개발하는 데 더 오래 걸린다는 것입니다.

• 그들은 규칙을 따르지 않을 것입니다 (우리는 표준 파일 구조를 가지고 있습니다. 작은 클라이언트가 우리가 요구하는 표준 형식으로 데이터를 제공하는 것을 보지 못했지만 큰 사람들은 왜 그것이 중요한지 이해합니다)
• 데이터 무결성 규칙이 이미 내장되어있는 데이터베이스 (대용량 파일이 생성되는 위치)가 아닌 Excel 파일에서 오는 경우 특히 데이터 무결성 문제가 더 많은 경향이 있습니다.
• 매번 같은 형식으로 제공 될 가능성이 적습니다.

우리는 표준 자식 프로세스를 가진 부모 자식 SSIS 패키지를 구축함으로써 개발에 많은 시간을 절약하고 표준 형식으로 데이터를 가져 오는 데 필요한 조작을 부모에서 수행 할 수 있음을 발견했습니다. 그렇게하면 추정 할 때 레코드 수가 얼마나 많은 문제가 아니라 표준 파일에 얼마나 가까운 지 문제가됩니다. 작은 것들이 표준에 맞지 않기 때문에 개발하는 데 시간이 오래 걸리더라도 불만이 많지 않습니다.

프로그램 작성은 새로운 직원을 고용하는 것과 같습니다. 데이터를 어디에서 찾을 수 있는지, 어떻게해야하는지, 결과를 제공하는 방법을 가르쳐 주어야합니다. 그들이 제대로하고 있는지 확인하기 위해 잠시 동안 그들을 지켜봐야합니다. 복잡한 / 중요한 직업이 있거나 매우 많은 양의 작업을 수행하려는 경우 교육하는 데 시간이 조금 더 걸릴 수 있지만, 시간이 많이 걸리더라도 시간이 많이 걸립니다.

많은 관리자들이 신입 사원 교육과 관련된 오버 헤드에 대해 잘 알고 있으므로 이해가 될 수 있습니다.

(신규 직원이 기록을 몇 개나 버리더라도 사소한 시간에 작업을 수행 할 수있는 강력한 로봇 인 한 비유는 무너지지 만, 그때까지는 당신의 입장을 밝혔습니다.)