ChatGPT mula mengancam keupayaan teras pengaturcara!

Soalan yang lebih kritikal ialah bagaimana untuk mengenal pasti sama ada jawapannya betul, saya kini mempunyai jawapan standard dan boleh menilainya. Dalam projek sebenar, kita berhadapan dengan perkara yang tidak diketahui Jika kita tidak mempunyai pengalaman, bagaimana kita tahu bahawa reka bentuk yang diberikan oleh GPT-4 adalah berkesan? Bolehkah ia menyelesaikan masalah?​

​ChatGPT ialah pembantu yang baik untuk pengaturcara? Atau adakah anda mahu membunuh pengaturcara?

Saya fikir ia bukan sahaja mengenai keupayaannya untuk menjana kod, tetapi yang lebih penting, sama ada ia mempunyai keupayaan reka bentuk yang kukuh.

Keupayaan reka bentuk mempunyai dua peringkat, satu peringkat tinggi, seperti reka bentuk seni bina dan reka bentuk sistem.

Satunya ialah keupayaan reka bentuk peringkat rendah, terutamanya mereka bentuk kelas dan antara muka tertentu.

Hari ini kita akan melihat prestasinya dalam dua aspek ini.

Memandangkan jawapan ChatGPT sangat panjang lebar, saya akan memadamkan beberapa butiran dan hanya menyimpan bahagian penting sahaja.

Atas sebab kerahsiaan syarikat, kami tidak boleh menggunakan projek sebenar dan hanya boleh menggunakan kes awam dalam buku untuk mengujinya.

1. Reka bentuk seni bina

Kes yang saya gunakan di sini ialah kerja perkhidmatan pelanggan sistem pesanan , diekstrak daripada buku "From Programmer to Architect". Buku ini mempunyai banyak kes praktikal.

Keperluan anggaran sistem pesanan kerja perkhidmatan pelanggan adalah seperti berikut:

Terdapat sistem perkhidmatan pelanggan yang menggunakan pangkalan data MySQL. Jumlah pesanan kerja yang dihasilkan setiap tahun adalah Terdapat lebih daripada 30 juta item, dan setiap pesanan kerja akan mempunyai 5 hingga 6 operasi ini juga mesti direkodkan, jadi terdapat lebih daripada 150 juta rekod operasi setiap tahun.

Kini apabila perkhidmatan pelanggan membuka sistem untuk melihat pesanan kerja, kelajuannya sangat perlahan dan ia mengambil masa 10 saat untuk dibuka Kini penyata SQL, indeks, dsb. telah dioptimumkan melampau dan tidak boleh diperbaiki lagi.

Kini prestasi sistem telah menjejaskan kecekapan pemprosesan perkhidmatan pelanggan secara serius Pelanggan memerlukan masalah ini diselesaikan dalam masa seminggu, iaitu masa yang sangat singkat.

Setelah menganalisis proses perniagaan, didapati sekiranya pesanan kerja selesai, status "tutup" akan ditambah pesanan kerja sedemikian tidak boleh dibuka beberapa kali setahun .

Pasukan tidak pernah menggunakan pembahagian pangkalan data sebelum ini, dan mereka menyerah pada rancangan pembahagian pangkalan data kerana mereka tidak pasti ia boleh diselesaikan dalam masa seminggu.

Untuk masalah ini, penyelesaian dalam buku adalah "pemisahan data panas dan sejuk" operasi harian "pangkalan data panas" memindahkan pesanan kerja "tertutup" ke dalam "pangkalan data sejuk" baharu, tetapi dalam pemisahan. data panas dan sejuk Semasa proses, isu konsistensi data perlu ditangani.

Serahkan keperluan ini kepada GPT-4 dan lihat cara ia menjawab.

GPT-4: Dalam kes ini, saya mengesyorkan dua kaedah berikut untuk menyelesaikan masalah prestasi:

1. Pengarkiban Pangkalan Data : Sejak kebanyakan tiket tertutup tidak lagi perlu diakses pada dasarnya, data tiket ini boleh dialihkan dari pangkalan data utama ke pangkalan data arkib. Dengan cara ini, saiz pangkalan data utama akan dikurangkan dengan banyak, sekali gus meningkatkan kelajuan pertanyaan. Pangkalan data arkib boleh dikemas kini secara kerap (seperti bulanan atau suku tahunan), dan pesanan kerja tertutup boleh dialihkan ke pangkalan data arkib...

Langkah-langkah khusus adalah seperti berikut:

a. Cipta pangkalan data MySQL baharu untuk menyimpan data yang diarkibkan.

b. Tulis skrip untuk sentiasa memindahkan pesanan kerja tertutup dan rekod operasi yang berkaitan daripada pustaka data induk ke pangkalan data arkib dan memastikan ketekalan data.

c. Ubah suai sistem perkhidmatan pelanggan supaya ia hanya menanyakan data yang tidak diarkibkan dalam pangkalan data utama secara lalai.

d. Sediakan antara muka atau alat yang berasingan untuk kakitangan perkhidmatan pelanggan untuk menanyakan data dalam pustaka data yang diarkibkan apabila diperlukan.

2. Cache: ...sedikit...

Ya, ia mendapat maksud serta-merta, Pangkalan data skim arkib dan langkah operasi khusus diberikan.

Walau bagaimanapun, terdapat petunjuk tertentu dalam keperluan, dan penyelesaian ini mudah untuk difikirkan.

Liu Xin: Dalam langkah operasi anda, bagaimana untuk memastikan konsistensi data Anda perlu mengendalikan dua pangkalan data di sini

GPT-4 : Ia? adalah sangat penting untuk memastikan konsistensi data. Apabila mengendalikan dua pangkalan data, kaedah berikut boleh digunakan untuk memastikan ketekalan data:

1. Gunakan urus niaga: Transaksi boleh memastikan satu set operasi sama ada semuanya berjaya atau semua gagal. .....Sedikit....

Liu Xin: Apabila anda menggunakan transaksi, bagaimana anda boleh memulakan transaksi yang merangkumi dua pangkalan data?

GPT-4: Maaf, saya ada membuat kesilapan dalam jawapan saya sebelum ini. Dalam MySQL kita tidak boleh terus menggunakan satu transaksi antara dua pangkalan data yang berbeza. Dalam kes ini, pertimbangkan untuk menggunakan strategi lain untuk memastikan ketekalan data. Satu pendekatan yang mungkin adalah menggunakan protokol Komit Dua Fasa (2PC). .... sedikit....

Liu Xin: Protokol komit dua fasa sangat rapuh Terdapat cara lain yang selamat untuk mengalihkan data daripada pangkalan data utama.

GPT-4: Maaf kerana penyelesaian sebelumnya tidak memenuhi keperluan anda sepenuhnya. Di sini saya menyediakan penyelesaian baharu yang menggunakan baris gilir mesej (seperti RabbitMQ, Kafka atau Amazon SQS) untuk memastikan ketekalan proses pemindahan data. Pendekatan ini memecahkan proses pemindahan data kepada dua langkah berasingan, memastikan pemulangan mudah jika berlaku kesilapan. .....Sedikit...

Liu Xin: Jika anda tidak menggunakan MQ dan menulis kod itu sendiri, bagaimana untuk memastikan konsistensi semasa proses pemindahan data?

GPT-4: Jika anda tidak mahu menggunakan baris gilir mesej, anda boleh menulis kod anda sendiri untuk memastikan konsistensi semasa pemindahan data menggunakan kaedah berikut:

1. Gunakan medan kunci dan tanda:

a Tambah medan Boolean bernama "is_migrated" pada jadual pesanan kerja dan jadual rekod operasi untuk menandakan sama ada rekod telah dipindahkan.

b. Tulis skrip atau program untuk menanyakan pangkalan data induk untuk rekod yang memenuhi syarat penghijrahan (contohnya, tiket tertutup dan "is_migrated" adalah palsu).

...Sedikit...

Nah, pada ketika ini, ia akhirnya menemui penyelesaian, yang agak serupa dengan buku itu, iaitu menggunakan medan untuk menandakan "sama ada ia telah dipindahkan".

Walau bagaimanapun, tidak kira bagaimana saya mendorongnya, ia tidak akan mencadangkan cara menjadikannya idempoten, jadi saya berputus asa.

Liu Xin: Pangkalan data arkib mempunyai jumlah data yang besar dan pertanyaannya sangat perlahan, tetapi pertanyaan pada asasnya adalah "cari pesanan kerja berdasarkan ID pelanggan, dan kemudian cari keluar perintah kerja berdasarkan ID pesanan kerja" "Semua rekod pemprosesan sahaja", adakah ada cara untuk menyelesaikannya?

GPT-4: Untuk mod pertanyaan ini, strategi berikut boleh diguna pakai untuk mengoptimumkan prestasi pertanyaan pangkalan data arkib:

1. ialah ID pelanggan dan ID perintah kerja Cipta indeks: ...... sedikit...
2. Pembahagian jadual pangkalan data: ...... sedikit...
3. Paparan pangkalan data:.. .. ..Sedikit......
4. Cache hasil:......Sedikit......
5. Belah beban baca dan tulis:..... .Sedikit ...
6. Optimumkan perkakasan dan konfigurasi:...Sedikit...

Penyelesaian ini Masalahnya tidak dapat diselesaikan dengan berkesan ialah untuk menggunakan pangkalan data NoSQL seperti HBase, yang tidak dijangka.

2.Detailed design

Kes yang saya guna masih bayaran gaji, ini diekstrak daripada buku klasik Agile Software Development: Principles, Patterns, and Practices.

Keperluan kes ini adalah seperti berikut:

Sistem ini terdiri daripada pangkalan data syarikat dan data berkaitan pekerja tepat pada masanya Membayar pekerja mengikut peraturan

Terdapat tiga jenis pekerja

1. Pekerja setiap jam, yang mempunyai gaji tetap setiap jam , dan mereka menyerahkan Kad waktu kerja mereka setiap hari, yang merekodkan tarikh dan waktu bekerja Jika anda bekerja lebih daripada 8 jam sehari, anda akan dibayar pada 1.5 kali. Mereka dibayar setiap hari Jumaat.

2. Pekerja gaji bulanan, gaji tetap, dan mereka dibayar pada hari terakhir bekerja setiap bulan

3 kakitangan, ada Mereka menerima gaji tetap, tetapi dibayar sejumlah komisen berdasarkan jualan mereka, dan mereka menyerahkan resit jualan yang merekodkan tarikh dan kuantiti jualan. Mereka dibayar setiap hari Jumaat.

Pekerja boleh memilih kaedah pembayaran mereka boleh menghantar cek ke alamat pos mereka yang ditetapkan, menyimpannya di bahagian kewangan dan mengeluarkannya pada bila-bila masa, atau memintanya untuk didepositkan terus. ke dalam akaun bank mereka yang ditetapkan.

Selepas membaca keperluan ini, reka bentuk umum adalah seperti berikut:

Pekerja berfungsi sebagai kelas asas yang mewarisi pelbagai jenis kelas pekerja.

Walau bagaimanapun, keperluan ini akan berubah. Pelanggan memerlukan jenis pekerja boleh ditukar, seperti dari pekerja setiap jam kepada pekerja gaji bulanan, jadi reka bentuk di atas tidak akan berfungsi.

Pada masa ini, anda harus membuat abstraksi, menggunakan kelas PaymentClassification untuk menyatakan klasifikasi pembayaran, dan kemudian biarkan kelas Pekerja memegang contoh ini .

Ini adalah perangkap, Ini juga merupakan lubang yang digali untuk ChatGPT untuk melihat cara ia mengendalikannya.

Dimulakan secara rasmi, saya memberitahunya keperluan dan biarkan ia mereka bentuk.

Tanpa diduga, ia mula menulis kod Python untuk saya sebaik sahaja ia bermula, jadi saya segera berhenti mengeluarkannya.

Liu Xin: Tidak perlu tunjukkan kod, terangkan kelas.

GPT-4 : OK, mengikut keperluan anda, kami boleh mereka bentuk kelas berikut serta sifat dan kaedah yang berkaitan:

1. Pekerja kelas asas: ...... sedikit...
2. Kelas Pekerja Setiap Jam, diwarisi daripada kelas Pekerja: ...... sedikit...
3. Kelas Pekerja Bergaji, diwarisi dari kelas Pekerja:... sedikit...
4. Kelas Pekerja Jualan, diwarisi dari kelas Pekerja Bergaji:... sedikit... ....
5. Kelas Kaedah Pembayaran: sedikit

Memang bagus, ia "memahami" keperluan dan mengekstraknya Kata Nama digunakan untuk mereka bentuk kelas direka olehnya hampir sama dengan gambar rajah UML yang pertama.

Telah mencapai tahap utama reka bentuk berorientasikan objek.

Kemudian mari kita mula menggali:

Liu Xin: Kelas di atas direka dengan baik, tetapi jika seseorang bermula sebagai pekerja setiap jam, Kemudian, saya menjadi pekerja gaji bulanan, dan reka bentuk di atas tidak lagi dapat menyokong perubahan ini.

GPT-4: Untuk menyelesaikan masalah yang anda nyatakan, kami boleh mengasingkan strategi pengiraan gaji pekerja daripada kelas Pekerja dan mereka bentuk menggunakan corak strategi. Dengan cara ini, kita boleh menukar strategi pengiraan gaji untuk kelas Pekerja secara dinamik tanpa mengubahnya.

Di bawah reka bentuk ini, kita perlu membuat beberapa pelarasan pada struktur kelas asal:

• Kekalkan kelas asas Pekerja:

Kaedah baru: set_gaji_strategi, digunakan untuk menetapkan strategi pengiraan gaji pekerja

• Alih keluar subkelas asal Pekerja Setiap Jam, Pekerja Bergaji dan Pekerja Jualan kerana kami mengasingkan strategi pengiraan gaji daripada kelas Pekerja.
• Strategi Gaji Kelas abstrak baharu, sebagai kelas asas strategi pengiraan gaji
• Kelas strategi khusus baharu:

Kelas Gaji Setiap Jam, diwarisi daripada kelas Strategi Gaji

Kelas Gaji Bergaji, diwarisi dari kelas Strategi Gaji

Kelas Gaji Jualan, diwarisi dari kelas Strategi Gaji

Dengan pelarasan di atas, ia kini boleh digunakan tanpa pengubahsuaian Dalam kes kelas Pekerja, strategi pengiraan gaji diubah secara dinamik untuknya. Apabila pekerja bertukar daripada gaji setiap jam kepada gaji bulanan, sediakan sahaja polisi pengiraan gaji baharu untuk mereka.

Saya perlu katakan, GPT-4 sangat berkuasa!

Ia menggunakan corak strategi untuk mengabstrak strategi pengiraan gaji Strategi Gaji.

Berbanding dengan gambarajah UML kedua, kecuali untuk nama yang berbeza, ia pada dasarnya adalah sama.

Boleh dikatakan jika anda boleh melakukan ini, anda boleh mengatasi ramai pengaturcara.

Saya perasan bahawa ia tidak mengendalikan isu kitaran gaji. Saya mula terus bertanya soalan:

Liu Xin: Permintaan asal juga termasuk masa pembayaran Contohnya, pekerja setiap jam dibayar setiap hari Jumaat.

GPT-4: Untuk mengendalikan masa pembayaran pelbagai jenis pekerja, kami boleh memperkenalkan kaedah abstrak should_pay_today dalam kelas asas SalaryStrategy, yang menentukan sama ada gaji perlu dibayar berdasarkan tarikh semasa. Seterusnya, laksanakan kaedah ini dalam kelas strategi khusus.

...Sikit-sikit...

Di sini ia membuat kesilapan, meletakkan tempoh pembayaran dalam gaji Dalam strategi pengiraan, ia juga dikenali sebagai "mudah dikekalkan dan dikembangkan".

Liu Xin: Masa pembayaran dan strategi pengiraan gaji ialah dua konsep yang tidak berjalan dengan baik bersama-sama Bagaimana kita boleh mencapai fleksibiliti maksimum?

GPT-4: Anda betul, masa pembayaran dan strategi pengiraan gaji adalah dua konsep berbeza. Untuk menjadikan reka bentuk lebih fleksibel, kami boleh memisahkan masa pembayaran daripada strategi pengiraan gaji dan mencipta Jadual Pembayaran kelas abstrak baharu untuk mengendalikan logik masa pembayaran. Dengan cara ini, kita boleh menetapkan strategi pengiraan gaji dan strategi masa pembayaran secara berasingan untuk setiap pekerja.

Berikut ialah struktur kelas yang dilaraskan:

Kekalkan kelas asas Pekerja:

• Atribut: nama, ID, alamat

Kaedah: set_payment_method, digunakan untuk menetapkan kaedah pembayaran pekerja

Kaedah: set_gaji_strategy, digunakan untuk menetapkan strategi pengiraan gaji pekerja

Kaedah baharu: set_payment_schedule, digunakan untuk menetapkan Strategi masa pembayaran pekerja

• mengekalkan kelas abstrak SalaryStrategy dan kelas strategi khusus tanpa sebarang perubahan.
• Tambahkan kelas abstrak PaymentSchedule sebagai kelas asas strategi masa pembayaran:... sedikit...
• Tambahkan kelas strategi masa pembayaran tertentu, warisi PaymentSchedule:

Kelas Bayaran Mingguan...ditinggalkan...

Kelas Bayaran Bulanan...ditinggalkan...

Kelas Pembayaran Dwimingguan...ditinggalkan...

• Kekalkan kelas PaymentMethod dan subkelasnya tanpa perubahan.

Hebat! Nampaknya saya tahu apa yang saya fikirkan, Jadual Pembayaran dan Strategi Gaji telah dipisahkan!

Setakat ini ia telah mencapai final, dan mungkin reka bentuk terbaik dalam buku:

3 Ringkasan

Dalam terperinci. tahap reka bentuk, prestasi GPT-4 jauh lebih kuat daripada reka bentuk seni bina.

Pembaca lama yang dah jadi coder tahu saya dah test GPT-3.5 dengan kes pembayaran gaji tahun lepas, tengah baca jawapan malah memberi rekaan melebihi syarat. .

Tetapi keupayaan reka bentuk GPT-4 telah melangkah lebih jauh Dengan gesaan pengaturcara, dia telah belajar untuk memisahkan kebimbangan.

Dari segi reka bentuk seni bina, saya merasakan bahawa GPT-4 telah menguasai banyak pengetahuan, tetapi ia tidak boleh digunakan dengan berkesan untuk masalah yang kompleks. Penyelesaian yang dihasilkannya sangat mengelirukan dan jauh dari apa yang kita mahukan.

Soalan yang lebih kritikal ialah bagaimana untuk mengenal pasti sama ada jawapannya betul, saya kini mempunyai jawapan standard dan boleh menilainya. Dalam projek sebenar, kita berhadapan dengan perkara yang tidak diketahui Jika kita tidak mempunyai pengalaman, bagaimana kita tahu bahawa reka bentuk yang diberikan oleh GPT-4 adalah berkesan? Bolehkah ia menyelesaikan masalah?

Atas ialah kandungan terperinci ChatGPT mula mengancam keupayaan teras pengaturcara!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!