ChatGPT가 프로그래머의 핵심 역량을 위협하기 시작했습니다!

더 중요한 질문은 답변이 올바른지 확인하는 방법입니다. 이제 표준 답변이 준비되어 있으며 이를 평가할 수 있습니다. 실제 프로젝트에서 우리는 미지의 것에 직면하게 되는데, 경험이 없다면 GPT-4가 제시한 디자인이 효과적인지 어떻게 알 수 있습니까? 문제를 해결할 수 있나요?​

​ChatGPT는 프로그래머에게 좋은 도우미인가요? 아니면 프로그래머를 죽이고 싶나요?

코드 생성 능력뿐만 아니라 더 중요한 것은 강력한 디자인 역량을 갖추고 있는지 여부라고 생각합니다.

설계 역량에는 두 가지 수준이 있는데, 하나는 아키텍처 설계와 시스템 설계와 같은 높은 수준입니다.

One은 상대적으로 낮은 수준의 디자인 기능으로 주로 특정 클래스와 인터페이스를 디자인합니다.

오늘 우리는 이 두 가지 측면에서 어떻게 작동하는지 살펴보겠습니다.

ChatGPT 답변이 너무 길어서 일부 내용은 삭제하고 중요한 부분만 남겨두겠습니다.

회사 기밀로 인해 실제 프로젝트는 사용할 수 없으며 책에 있는 공개 사례만 테스트용으로 사용할 수 있습니다.

1. 건축 설계

여기서 사용한 사례는 "프로그래머에서 건축가까지"라는 책에서 발췌한 고객 서비스 티켓 시스템입니다. , 그런데 저는 모든 사람에게 추천합니다.

고객 서비스 작업 주문 시스템의 대략적인 요구 사항은 다음과 같습니다.

MySQL 데이터베이스를 사용하는 고객 서비스 시스템이 매년 3천만 개 이상의 작업 주문이 생성되며 각 작업 주문에는 5개가 있습니다. 6개 작업까지 기록해야 하므로 매년 1억 5천만 건 이상의 작업 기록이 있게 됩니다.

이제 고객 서비스에서 작업 주문을 보기 위해 시스템을 열면 속도가 매우 느리고 여는 데 10초가 걸립니다. 이제 SQL 문, 인덱스 등이 극도로 최적화되어 더 이상 개선할 수 없습니다. .

이제 시스템 성능이 고객 서비스 처리 효율성에 심각한 영향을 미치고 있습니다. 고객은 매우 짧은 시간인 일주일 이내에 이 문제를 해결해야 한다고 요구합니다.

비즈니스 프로세스를 분석한 결과 작업 주문이 처리되면 "종료됨" 상태가 추가되는 것으로 나타났습니다. 이러한 작업 주문은 1년에 몇 번만 열 수 있습니다.

팀은 이전에 데이터베이스 파티셔닝을 사용해 본 적이 없었고, 일주일 안에 해결될 수 있다는 확신도 없이 데이터베이스 파티셔닝 계획을 포기했습니다.

이 문제에 대한 책의 해결책은 "핫 및 콜드 분리", "핫 데이터베이스"의 일상적인 운영, "닫힌" 작업 주문을 새로운 "콜드 데이터베이스"로 이동하는 것입니다. 그러나 핫 및 콜드 데이터를 처리하는 과정에서 분리하려면 데이터 일관성 문제를 처리해야 합니다.

이 요구 사항을 GPT-4에 적용하고 어떻게 응답하는지 확인하세요.

GPT-4: 이 경우 성능 문제를 해결하기 위해 다음 두 가지 방법을 권장합니다.

1. 데이터베이스 보관: 기본적으로 대부분의 마감된 티켓에 더 이상 액세스할 필요가 없으므로 이 티켓 데이터는 기본 데이터베이스에서 아카이브 데이터베이스로 이동할 수 있습니다. 이러한 방식으로 기본 데이터베이스의 크기가 크게 줄어들어 쿼리 속도가 향상됩니다. 아카이브 데이터베이스를 정기적으로(예: 월별 또는 분기별) 업데이트하여 마감된 작업 주문을 아카이브 데이터베이스로 이동할 수 있습니다...

구체적인 단계는 다음과 같습니다.

a. 보관된 데이터.

b. 마감된 작업 주문 및 관련 작업 기록을 마스터 데이터 라이브러리에서 아카이브 데이터베이스로 정기적으로 이동하고 데이터 일관성을 보장하는 스크립트를 작성합니다.

c. 기본적으로 기본 데이터베이스에 보관되지 않은 데이터만 쿼리하도록 고객 서비스 시스템을 수정합니다.

d. 고객 서비스 직원이 필요할 때 보관된 데이터 라이브러리의 데이터를 쿼리할 수 있는 별도의 인터페이스 또는 도구를 제공합니다.

2. 캐시:...약간...

나쁘지 않게 핵심 내용을 바로 파악하고 데이터베이스 아카이빙 계획과 구체적인 운영 단계를 알려준다.

그러나 요구 사항에는 특정 힌트가 있으며 이 솔루션은 생각하기 쉽습니다.

Liu Xin: 작업 단계에서 데이터 일관성을 보장하는 방법은 무엇입니까? 여기서 두 개의 데이터베이스를 운영해야 합니다

GPT-4: 데이터 일관성을 보장하는 것이 매우 중요합니다. 두 개의 데이터베이스를 운영할 때 다음 방법을 사용하여 데이터 일관성을 보장할 수 있습니다.

1. 트랜잭션 사용: 트랜잭션은 일련의 작업이 모두 성공하거나 모두 실패하도록 보장할 수 있습니다. .....약간....

Liu Xin: 트랜잭션을 사용할 때 두 데이터베이스에 걸쳐 있는 트랜잭션을 어떻게 시작할 수 있습니까?

GPT-4: 죄송합니다. 이전 답변에서 실수를 했습니다. MySQL에서는 서로 다른 두 데이터베이스 간에 단일 트랜잭션을 직접 사용할 수 없습니다. 이 경우 데이터 일관성을 보장하기 위해 다른 전략을 사용하는 것이 좋습니다. 한 가지 가능한 접근 방식은 2PC(2단계 커밋)를 사용하는 것입니다. .... 약간...

Liu Xin: 2단계 커밋 프로토콜은 매우 취약합니다. 기본 데이터베이스에서 아카이브 데이터베이스로 데이터를 이동하는 다른 안전한 방법이 있습니까?

GPT-4: 죄송합니다. 이전 솔루션이 귀하의 요구 사항을 완전히 충족하지 못했습니다. 여기서는 데이터 마이그레이션 프로세스의 일관성을 보장하기 위해 메시지 대기열(예: RabbitMQ, Kafka 또는 Amazon SQS)을 사용하는 새로운 솔루션을 제공합니다. 이 접근 방식은 데이터 마이그레이션 프로세스를 두 개의 별도 단계로 나누어 문제가 발생할 경우 쉽게 롤백할 수 있도록 합니다. .....약간...

Liu Xin: MQ를 사용하지 않고 직접 코드를 작성하는 경우 데이터 마이그레이션 프로세스 중에 일관성을 어떻게 보장할 수 있나요?

GPT-4: 메시지 큐를 사용하지 않으려면 다음 방법을 사용하여 데이터 마이그레이션 중에 일관성을 보장하기 위해 자체 코드를 작성할 수 있습니다.

1. 잠금 및 표시 필드 사용:

a. 티켓 만들기 레코드가 마이그레이션되었는지 여부를 표시하기 위해 테이블과 작업 레코드 테이블에 각각 "is_ migrationd"라는 부울 필드가 추가됩니다.

b 마이그레이션 기준을 충족하는 레코드에 대해 마스터 데이터베이스를 쿼리하는 스크립트 또는 프로그램을 작성합니다(예: 종료된 티켓 및 "is_ migrationd"가 false임).

...약간...

이 시점에서 마침내 해결책을 찾았는데, 이는 책과 다소 유사한데, 필드를 사용하여 "이전되었는지 여부"를 표시하는 것입니다.

그런데 아무리 프롬프트를 쳐도 멱등성으로 만드는 방법이 제시되지 않아서 포기했습니다.

Liu Xin: 아카이브 데이터베이스에는 많은 양의 데이터가 있고 쿼리가 매우 느리지만 쿼리는 기본적으로 "고객 ID를 기반으로 작업 주문을 찾은 다음 해당 작업의 모든 처리 기록을 알아냅니다. 작업지시 ID를 기준으로 작업지시가 발생합니다." 이런 현상을 해결할 수 있는 방법이 있나요?

GPT-4: 이 쿼리 모드에서는 아카이브 데이터베이스의 쿼리 성능을 최적화하기 위해 다음 전략을 채택할 수 있습니다.

1. 고객 ID 및 작업 주문 ID에 대한 인덱스 생성: ...생략됨.... ..
2. 데이터베이스 테이블 파티션: ... 약간...
3. 데이터베이스 보기: ... 약간...
4. 결과 캐시:... 약간...
5. 읽기 및 쓰기 로드 분할:... 약간...
6. 하드웨어 및 구성 최적화:...약간...

이러한 솔루션 중 어느 것도 문제를 효과적으로 해결할 수 없습니다. 올바른 솔루션은 예상치 못한 HBase와 같은 NoSQL 데이터베이스를 사용하는 것입니다.

2. 상세 설계

제가 사용하는 사례는 여전히 급여 지급입니다. 이는 고전 책 "Agile Software Development: Principals, Patterns and Practices"에서 발췌한 것입니다.

이 사건의 요구 사항은 다음과 같습니다.

시스템은 회사 데이터베이스와 직원 관련 데이터로 구성됩니다. 시스템은 규칙에 따라 직원에게 제때에 급여를 지급해야 합니다

세 가지가 있습니다. 직원 유형

1. 시간제 근로자는 시간당 고정 급여를 받으며, 하루에 8시간 이상 근무한 날짜와 시간을 기록합니다. 1.5배로 지급됩니다. 매주 금요일에 지급됩니다.

2. 월급은 고정되어 있으며, 매월 마지막 근무일에 지급됩니다.

3. 영업사원은 고정된 급여를 받지만, 급여에 따라 일정 금액을 지급받습니다. 판매 커미션의 경우 판매 날짜와 수량을 기록한 판매 영수증을 제출합니다. 격주 금요일에 지급됩니다.

직원은 수표를 지정된 우편 주소로 우편으로 보낼 수도 있고, 재무 부서에 저장한 후 언제든지 인출할 수도 있고, 지정된 은행 계좌로 직접 입금하도록 요청할 수도 있습니다.

이 요구 사항을 읽은 후 일반적인 디자인은 다음과 같습니다.

Employee가 기본 클래스로 사용되며 다양한 유형의 직원 클래스가 이 클래스에서 상속됩니다.

그러나 이 요구사항은 변경될 예정입니다. 고객은 직원 유형을 시간제 직원에서 월간 직원으로 변경할 수 있도록 요구하므로 위의 디자인은 작동하지 않습니다.

이때 추상화를 하고 PaymentClassification 클래스를 사용하여 지불 분류를 표현한 다음 Employee 클래스가 이 인스턴스를 보유하도록 해야 합니다. 간단히 말해서 상속 대신 조합을 사용하십시오.

이것은 ChatGPT를 위해 파낸 함정이자 구멍입니다. 어떻게 처리하는지 봅시다.

공식적으로 시작해서 요구사항을 알려주고 디자인하게 됐습니다.

의외로 Python 코드가 나오자마자 바로 작성해 주었고, 세부 사항이 너무 많아서 즉시 출력을 중단했습니다.

Liu Xin: 코드를 보여줄 필요 없이 클래스만 설명하면 됩니다.

GPT-4 : 좋습니다. 필요에 따라 다음 클래스와 관련 속성 및 메서드를 설계할 수 있습니다.

1. 기본 클래스 Employee: ... 약간...
2. HourlyEmployee 클래스, Employee 클래스에서 상속됨: ... 약간...
3. SalariedEmployee 클래스, Employee 클래스에서 상속됨: ... 약간...
4. SalesEmployee SalariedEmployee 클래스에서 상속된 클래스: ... 약간...
5. PaymentMethod 클래스: 약간

정말로 요구 사항을 "이해"하고 명사를 추출하여 클래스를 디자인합니다. , SalesEmployee는 첫 번째 UML 다이어그램과 거의 동일합니다.

객체 지향 디자인의 기본 수준에 도달했습니다.

그럼 파헤쳐 보겠습니다.

Liu Xin: 위 클래스는 잘 디자인되었지만, 시급 직원으로 시작해서 나중에 월급 직원이 되면 위 디자인은 이러한 변화를 지원할 수 없습니다. , 어떻게 해야 하나요?

GPT-4: 언급한 문제를 해결하기 위해 Employee 클래스에서 직원의 급여 계산 전략을 분리하고 전략 패턴을 사용하여 설계할 수 있습니다. 이러한 방식으로 Employee 클래스의 급여 계산 전략을 수정하지 않고도 동적으로 변경할 수 있습니다.

이 디자인에서는 원래 클래스 구조를 일부 조정해야 합니다.

• 기본 클래스 Employee 유지:

새 메서드: set_salary_strategy, 직원의 급여 계산 전략을 설정하는 데 사용됨

• Move In 급여 계산 전략을 Employee 클래스에서 분리했기 때문에 원래 하위 클래스인 HourlyEmployee, SalariedEmployee 및 SalesEmployee에 추가되었습니다.
• 급여 계산 전략의 기본 클래스인 새로운 추상 클래스 SalaryStrategy
• 새로운 특정 전략 클래스:

SalaryStrategy 클래스에서 상속된 HourlySalary 클래스

SalariedSalary 클래스, SalaryStrategy 클래스

S alesSal 아리 수업 , SalaryStrategy 클래스에서 상속됨

위의 조정을 통해 이제 Employee 클래스에 대한 급여 계산 전략을 수정하지 않고도 동적으로 변경할 수 있습니다. 직원이 시급에서 월급으로 변경되면 해당 직원에 대한 새로운 급여 계산 정책을 설정하면 됩니다.

GPT-4는 매우 강력하다고 말씀드리고 싶습니다!

전략 패턴을 사용하여 급여 계산 전략 SalaryStrategy를 추상화합니다.

두 번째 UML 다이어그램과 비교하면 이름이 다른 것 외에는 기본적으로 동일합니다.

이렇게 하면 많은 프로그래머를 능가할 수 있다고 할 수 있습니다.

결제 주기를 처리하지 않은 것으로 확인되었습니다. 나는 계속 질문하기 시작했습니다.

Liu Xin: 원래 요구에는 지불 시간도 포함되었습니다. 예를 들어, 시간당 근로자는 매주 금요일에 급여를 지불해야 합니다.

GPT-4: 다양한 유형의 직원의 지불 시간을 처리하기 위해 SalaryStrategy 기본 클래스에 현재 날짜를 기준으로 급여를 지불해야 하는지 여부를 결정하는 추상 메서드 should_pay_today를 도입할 수 있습니다. 다음으로 특정 전략 클래스에서 이 메서드를 구현합니다.

...조금...

여기서는 급여 산정 전략에 지급 주기를 넣는 실수를 했고, "유지 관리 및 확장이 쉽다"고 칭찬하기도 했습니다.

Liu Xin: 지급 시간과 급여 계산 전략은 서로 잘 어울리지 않는 두 가지 개념입니다. 어떻게 하면 유연성을 극대화할 수 있을까요?

GPT-4: 맞습니다. 지급 시간과 급여 계산 전략은 서로 다른 개념입니다. 디자인을 보다 유연하게 만들기 위해 급여 계산 전략에서 지불 시간을 분리하고 지불 시간 논리를 처리하는 새로운 추상 클래스 PaymentSchedule을 만들 수 있습니다. 이런 식으로 직원별로 급여 계산 전략과 지급 시기 전략을 별도로 설정할 수 있습니다.

다음은 조정된 클래스 구조입니다.

기본 클래스 Employee 유지:

• 속성: 이름, ID, 주소

메서드: set_pay_method, 직원의 지불 방법을 설정하는 데 사용

메서드: set_salary_strategy, use 직원의 급여 계산 전략 설정용

새 메소드: set_paid_schedule, 직원의 지불 시간 전략 설정에 사용

• 추상 클래스 SalaryStrategy 및 해당 특정 전략 클래스를 변경 없이 유지합니다.
• 결제 시간 전략의 기본 클래스로 추상 클래스 PaymentSchedule을 추가했습니다:... 약간...
• PaymentSchedule을 상속하는 새로운 특정 결제 시간 전략 클래스를 추가했습니다:

WeeklyPayment 클래스... 약간...

MonthlyPayment 클래스...약간...

BiweeklyPayment 클래스...약간...

• PaymentMethod 클래스와 해당 하위 클래스를 변경 없이 유지합니다.

대박! 내 생각을 알 것 같네요. PaymentSchedule과 SalaryStrategy가 분리되어 있어요!

지금까지 책에서 아마도 최고의 디자인을 달성했습니다.

요약

III. 디테일한 디자인에서는 수준에서 GPT-4의 성능은 건축 설계보다 훨씬 강력합니다.

프로그래머가 된 오래된 독자들은 제가 작년에 급여 지불 케이스를 사용하여 GPT-3.5를 테스트했다는 것을 알고 있습니다. 그 당시에는 답변을 낭독하고 심지어 요구 사항 이상의 디자인까지 제공했습니다.

그러나 GPT-4는 프로그래머의 지시에 따라 설계 능력이 한 단계 더 발전했습니다.

건축 설계 측면에서 GPT-4는 많은 지식을 습득했지만 복잡한 문제에 효과적으로 적용할 수는 없다고 생각합니다. 그것이 만들어내는 솔루션은 매우 혼란스럽고 우리가 원하는 것과 거리가 멀습니다.

더 중요한 질문은 답변이 올바른지 확인하는 방법입니다. 이제 표준 답변이 준비되어 있으며 이를 평가할 수 있습니다. 실제 프로젝트에서 우리는 미지의 것에 직면하게 되는데, 경험이 없다면 GPT-4가 제시한 디자인이 효과적인지 어떻게 알 수 있습니까? 문제를 해결할 수 있나요?

위 내용은 ChatGPT가 프로그래머의 핵심 역량을 위협하기 시작했습니다!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!