Seperti apa pemograman pada tahun 2025?



Kami sering membaca tentang praktik terbaik dalam pemrograman, tentang fitur kerangka kerja baru atau apa yang baru di versi PHP berikutnya. Kami membaca bagaimana mengubah " ini menjadi ini " , mengapa beberapa teknik baik atau buruk, atau paket baru apa yang dapat Anda gunakan dalam proyek Anda. Tapi semua ini adalah spekulasi hanya tentang masa lalu atau masa kini.



Saya akan menyelesaikan membaca buku « of The Inevitable » , yang ditulis oleh pendiri majalah Wired, di mana hanya tentang masa depan. Terinspirasi oleh buku ini, saya mengusulkan untuk melihat masa depan pemrograman.



Hari ini kami berjuang melawan hutang teknis (apa pun artinya), kode lama yang sulit dipertahankan dan mahal untuk dimodifikasi, tetapi menghasilkan banyak uang pada saat yang bersamaan. Secara teratur, kami harus memfaktor ulang kode, mengikuti prinsip DDD, menulis tes, memperbarui versi PHP untuk tujuan keamanan, menginstal versi perangkat lunak terbaru di server dan mengotomatiskan tata letak.



Ada begitu banyak pekerjaan rutin saat ini sehingga sama sekali tidak ada waktu untuk melihat lusinan proyek lain yang didukung perusahaan kami ... atau setidaknya menyimpannya di suatu tempat di server kami. Kita harus mempekerjakan seorang ahli untuk membantu meningkatkan setiap aspek setidaknya sedikit. Bukan karena proyek ini buruk, tetapi hanya karena ada begitu banyak teknologi yang dapat kita gunakan, dan bahkan lebih banyak kode yang harus kita pertahankan.



Dan bagaimana semua ini akan terjadi di masa depan?



IDE akan menggunakan kecerdasan buatan



Ke depannya, pengetikan kode menjadi lebih mudah. IDE kami akan didukung oleh kecerdasan buatan, yang belajar dari data anonim proyek PHP lainnya dan semua proyek sumber terbuka di Github dan Gitlab.



Berkat AI ini, saat kami mulai mengetik "class HomepageC ...", IDE akan mengetahui bahwa kami membuat pengontrol beranda, bahwa kami menggunakan Symfony, serta versinya dari composer.json, dan akan menawarkan untuk menambahkan pengubah finalisasi secara otomatis ke seluruh kode dan tipe yang kuat, berdasarkan pengetahuan tentang versi PHP yang digunakan, juga dari composer.json. Ini akan menghasilkan template untuk mesin template yang kita gunakan dan akan meniru konten yang ditemukan di template lain yang sudah kita miliki di proyek kita.



Berkat banyaknya data anonim dan data dari penyimpanan kode publik, AI akan mengetahui cara terbaik untuk menguji pengontrol dan akan menggunakan pengetahuan ini untuk membuat pengujian pengontrol yang optimal.



Praktik Terverifikasi Terbaik



Ketika kami berbicara tentang "praktik terbaik", kami tidak bermaksud apa yang saya atau orang lain tulis dalam posting atau buku hanya berdasarkan pengalaman pribadi. Pendapat ini sering kali didasarkan pada pengalaman hanya dari beberapa proyek dan bermuatan emosional.



Di masa mendatang, konsep "praktik terbaik" akan diganti dengan "praktik terverifikasi" dan akan didasarkan pada data nyata yang terkait dengan dua indikator kaku - utang teknis dan efisiensi pengkodean. Hutang teknologi akan memiliki nilai finansial yang setara yang akan menunjukkan berapa biaya untuk mempertahankan setiap baris kode di masa depan. Apakah Anda bebas menulis kode statis tanpa kelas yang diketik? String tersebut mungkin "berharga" $ 10. Apakah Anda menulis kelas akhir dengan tipe yang kuat dan satu metode publik? Dalam hal ini, saluran tersebut akan dikenakan biaya $ 2.



Angka-angka ini tidak akan acak, tetapi akan didasarkan pada analisis konstan dari sejumlah besar data yang sangat besar, anonim untuk semua proyek yang memilih untuk menggunakan fitur ini. Kode tersebut akan dibandingkan dengan biaya moneter yang diperlukan untuk memelihara dan meningkatkan proyek. Berkat umpan balik ini, AI juga akan mengetahui versi mana yang lebih bermanfaat untuk proyek khusus Anda.



AI akan mengetahui tentang konteks proyek Anda dan membandingkan datanya. Apakah Anda memiliki proyek CLI? Ini akan dibandingkan dengan kode proyek CLI lainnya di bidang subjek ini. Apakah Anda sedang membuat situs web? Ini akan dibandingkan dengan desain dari situs lain.



Efisiensi pengkodean akan ditentukan oleh metrik "pemeliharaan" proyek. Ini akan diukur pada skala dari 0 hingga 100, di mana 0 berarti butuh waktu berjam-jam untuk memahami kode, dan bisa butuh waktu berhari-hari atau bahkan berminggu-minggu untuk membuat perubahan. Kode dengan skor 100 akan mudah dipahami oleh developer junior dan dia akan dapat mengubah kode tersebut hampir secara instan.



Penyelesaian otomatis terverifikasi IDE



IDE akan mengetahui metrik ini dan juga akan mengikuti pola yang digunakan dalam kode Anda. Saat Anda mulai menulis kode yang efisiensinya 40-50 poin, pelengkapan otomatis akan muncul dengan saran kode dengan fungsi yang sama, tetapi dengan efisiensi 80-90. Ini serupa dengan pekerjaan yang dilakukan Rektor atau PHPStan saat ini.



Analisis kinerja juga akan dilakukan bersamaan dengan analisis kinerja pengkodean. Performa akan secara otomatis diukur setiap kali kode berubah di latar belakang di container Docker, dan Anda akan diberi tahu tentang kebocoran memori atau peningkatan waktu proses. Analisis ini akan sangat akurat sehingga akan menandai string atau karakter tertentu yang menyebabkan kebocoran dan menyarankan perbaikan yang harus Anda terima.



Refactoring AST



Refactoring juga akan lebih efektif dari sekarang. Ini akan didasarkan pada Abstract Syntax Tree (AST). IDE akan menyarankan pemfaktoran ulang terbaik yang ingin Anda lakukan sekarang, berdasarkan data anonim dari semua proyek terbuka dan tertutup.



Alih-alih mengacu pada praktik terbaik, Anda akan tahu bahwa:



  • solusi A akan dikenakan biaya $ 3 per baris dalam utang teknis, dan akan diberi peringkat 95 untuk efisiensi dan 45 untuk kinerja
  • Solusi B akan membebani Anda $ 1 per baris dalam utang teknis, dengan peringkat efisiensi 70 dan peringkat kinerja 50


Apakah Anda sedang membangun sebuah startup dan ingin menguji ide Anda? Kemudian Anda akan memilih opsi A. Bagaimana jika perusahaan Anda stabil dan harus tetap demikian di masa mendatang? Kemudian Anda harus beralih ke opsi B, yang lebih murah dalam dukungan dan kinerja, tetapi sedikit lebih lambat dalam pengembangan



Anda tidak perlu berdebat dengan rekan kerja atau atasan Anda mengapa Anda harus menggunakan solusi ini atau itu. Anda membandingkan angkanya dan kemudian memutuskan berdasarkan prioritas Anda saat ini.



Arsitektur konteks



Kode Anda akan memiliki arsitektur kontekstual. AI akan tahu kapan harus berpindah antar konteks berdasarkan data dari proyek lain dan biaya akhir migrasi ke sana. Apakah Anda memulai proyek WordPress? Tidak apa-apa. Tetapi bagaimana jika proyek Anda menjadi lebih populer dan Anda perlu beralih ke beberapa kerangka kerja PHP yang lebih sesuai dengan kebutuhan Anda? IDE akan meminta Anda untuk beralih ke Laravel. Satu klik dan Anda selesai.



Tiga tahun kemudian, proyek Anda berkembang dan Anda akan memiliki banyak tugas untuk mengintegrasikan layanan pihak ketiga yang sudah dibangun ke dalam kerangka kerja Symfony. IDE meminta Anda untuk bermigrasi ... click ... dan boom, Anda berada di Symfony 9. Apakah Anda menemukan bahwa tidak ada cukup pengembang Symfony di pasar untuk menangani pengembangan proyek Anda? Satu klik dan IDE akan mentransfer proyek ke kerangka kerja yang memiliki cukup pengembang dengan biaya yang masuk akal.



Jawaban berversi StackOverflow 



IDE akan memindai kode Anda dan menganalisis kebiasaan pengkodean Anda. Anda biasanya menulis fungsi dalam 15 menit, tapi sekarang butuh hampir 2 jam? Di tahun-tahun mendatang, IDE akan sangat bagus bahkan akan melihat sedikit penurunan dalam kecepatan penulisan kode dalam hitungan detik.



IDE kemudian akan memeriksa kode Anda, memindai respons di StackOverflow, mencocokkan respons dengan versi di composer.lock Anda, dan menyarankan agar Anda menggunakan kode tertentu yang paling sesuai.



Apakah Anda khawatir potongan kode ini disalin secara acak dan akan merusak proyek Anda? Peringkat jawaban tidak lagi berdasarkan pemungutan suara pengguna, tetapi sekarang memperhitungkan persentase penggunaan jawaban jika berhasil diintegrasikan ke dalam kode proyek.



Cuplikan kode yang diuji



Selain itu, cuplikan kode diuji setiap hari oleh StackOverflow itu sendiri dan juga sebelum disalin ke dalam proyek Anda. Ini sesuai dengan versi lingkungan lokal Anda, sehingga Anda dapat yakin bahwa kode tersebut akan berfungsi. Orang-orang tidak lagi menulis versi jawaban ini sendiri, seperti yang mereka lakukan di masa lalu. Kode dalam respons diperbarui secara otomatis dengan setiap rilis teknologi atau kerangka kerja yang digunakannya. Beberapa jawaban telah diberikan untuk Symfony 5. Apa yang akan terjadi jika Symfony 6 dirilis? Kode lama dalam jawaban akan diperbarui dengan resep AST yang dirilis dengan Symfony 6. Dengan cara ini, manusia dan IDE dapat dengan mudah bekerja dengannya.



Pendanaan Berbasis Aktivitas Sumber Terbuka



Sebuah proyek baru akan dibuat yang akan menghubungkan perusahaan komersial dan kontributor open source. Proyek open source akan didanai oleh perusahaan yang menggunakannya. Pengembang yang berkontribusi akan didanai melalui satu sistem berdasarkan arus kas masuk, tanpa biaya tambahan untuk menutupi biaya.



Pendanaan akan ditentukan menggunakan metrik seperti dampak fitur, beban kerja, waktu yang dihabiskan, efisiensi kode, dll. Dengan demikian, kode akan dikembangkan jauh lebih konsisten daripada ketika dikembangkan oleh kontributor independen di waktu senggang mereka. Seorang pengembang pada proyek open source, pada kenyataannya, akan mendapatkan pekerjaan penuh waktu yang didanai oleh proyek itu.



Apa yang akan diterima perusahaan-perusahaan ini sebagai hadiah? Promosi khusus komunitas, rilis pra-rilis versi baru, dan akses langsung ke konsultan ahli yang telah membuat proyek open source yang mereka (perusahaan ini) gunakan.



Kerangka kerja konsolidasi



~ 10 kerangka kerja PHP yang saat ini ada akan dikonsolidasikan. Komunitas di sekitar kerangka kerja PHP akan belajar untuk berkolaborasi lebih banyak daripada mengembangkan salinan kerangka kerja yang hampir identik dengan pendekatan MVC.



Berkat migrasi AST, Anda dapat beralih ke kerangka kerja PHP apa pun. Ini akan mempersempit pilihan menjadi 3-4 kerangka kerja. Jika migrasi antar framework hanya dilakukan 1 klik di IDE Anda, maka tidak akan ada lagi persaingan berdasarkan klaim bahwa "itu terjadi secara historis" dan kebiasaan, tetapi hanya pada kualitas.



Mengurangi jumlah kerangka kerja akan mengarah pada fokusnya yang lebih sempit - satu kerangka kerja akan berhasil di API, yang lain di CLI, ketiga di situs dengan UX yang bagus.



Ketika seluruh komunitas PHP berfokus pada lebih sedikit kerangka kerja, ini akan memungkinkan kami menginvestasikan upaya yang dihemat dalam mengembangkan teknologi dan fitur baru.



Hanya 1 versi PHP yang stabil



Berkat migrasi AST otomatis, hanya akan ada dua versi PHP - stable dan dev. Karena memperbarui paket atau proyek apa pun akan menjadi sangat cepat dan murah, tidak ada alasan untuk tidak memperbarui ke versi terbaru. Mungkin komunitas PHP membutuhkan satu atau dua tahun untuk menerima ini dan menjaga semua proyek tetap sinkron. Tetapi jika itu terjadi, dalam waktu satu bulan setelah rilis versi baru PHP, seluruh ekosistem open source akan menggunakannya sebagai versi minimum.



Pembaruan kode sepenuhnya otomatis dan instan



Kode PHP tidak perlu diperbarui secara manual. Setiap versi PHP akan memiliki "resep" pembaruan berbasis AST lengkap yang dapat Anda gunakan untuk memperbarui kode dalam proyek Anda secara otomatis. GitHub akan menangani "resep" ini, jadi ketika versi baru PHP dirilis, GitHub akan secara otomatis mulai mengirim permintaan tarik ke repositori Anda. Akan ada pembaruan otomatis tidak hanya untuk PHP, tetapi juga untuk kerangka kerja atau paket apa pun. Seperti Dependabot, yang baru-baru ini diintegrasikan ke GitHub, tetapi sekarang dengan pembaruan kode dan semua masalah kompatibilitas ke belakang.



Pengupgrade GitHub



Jika Anda tidak ingin mengambil alih semua PR sendiri, Anda dapat mendaftar untuk program pembaruan otomatis sehingga GitHub melakukannya untuk Anda. Dia juga akan memperbarui rilis dan SemVer mereka dengan benar.



SemVer Otomatis 



Tidak akan ada perdebatan mengenai apakah perubahan tersebut adalah kompatibilitas mundur atau hanya sebuah tambalan. AI akan menganalisis kode sebelum dan sesudah, dan berdasarkan ini akan mengambil keputusan. Dia akan sangat pintar sehingga dia akan dapat menentukan seberapa signifikan dampak dari perubahan tertentu. Jika ini tidak memengaruhi kode apa pun di proyek lain, ini akan dirilis sebagai tambalan.



PHP RFC Berdasarkan Pelajaran yang Dipelajari



Analisis kerusakan kompatibilitas mundur yang sama akan dimungkinkan untuk RFC apa pun dalam kode inti PHP. Ingin menyarankan konstanta yang diketik? AI akan memberi tahu Anda berapa banyak proyek dari 10.000 teratas di Github yang akan rusak sebagai persentase. Hal serupa sekarang dilakukan secara manual di beberapa RFC.



Rethinking Backward Compatibility Break



AI juga akan membantu Anda menghasilkan "resep" migrasi AST, sehingga pembaruan instan dapat sepenuhnya menangani gangguan kompatibilitas ke belakang. Ini akan menyebabkan perubahan konsep itu sendiri. Pemutusan kompatibilitas mundur hanya akan terjadi ketika pembaruan otomatis tidak dapat terjadi dan manusia diperlukan untuk mengubah kode.



Coba RFC secara lokal



Selain itu, siapa pun dapat mencoba fitur RFC secara lokal tepat setelah PR dibuat di GitHub. Bagaimana? Github secara otomatis akan membuat versi sementara dengan tag dev khusus dan mendorong versi PHP tersebut ke registri paket. Anda membuat RFC untuk menambahkan konstanta yang diketik, mengirimkannya sebagai PR ke GitHub dan setelah 1 menit Anda dapat menjalankan sudo apt-get install php-dev-typed-constant untuk mendapatkan PHP dengan RFC ini di mesin lokal Anda.



Dengan demikian, pemrogram akan dapat mencoba fitur ini bahkan sebelum dimasukkan ke dalam cabang utama dan bahkan sebelum memberikan suara pada RFC. Dalam hal ini, bahkan pemungutan suara untuk fitur baru akan didasarkan pada data dan pengalaman nyata, dan bukan pada emosi, pendapat subjektif, dan argumen.



Apa masa depan bagi kita?



Di masa depan, kemampuan kami tidak akan dibatasi oleh riwayat kami, pilihan sebelumnya, atau teknologi yang berkembang pesat yang membuat kode kami cepat usang. Hanya dengan satu klik, semua alat kami adalah yang paling canggih di pasaran saat ini.



Ini akan memungkinkan kami untuk bereksperimen lebih banyak, menguji asumsi kami, dan mendapatkan umpan balik yang nyata. Hal ini akan mengarah pada otomatisasi proses pengkodean dan penemuan yang lebih baik dalam bahasa, pola, dan arsitektur aplikasi yang bahkan tidak dapat kita bayangkan saat ini.



"Cara terbaik untuk memprediksi masa depan adalah dengan menciptakannya." 



Selamat berkreasi!



All Articles