PHP
Cara Yang Salah
Update Terakhir: 2023-09-01
Dalam dunia pemrograman PHP, serangkaian tren secara besar-besaran disebarkan oleh beberapa orang (dalam buku-buku mereka dan di situs web) sebagai “PHP Modern” sementara semua pendekatan lain tidak disukai karena dianggap terbelakang, bodoh, atau sekadar salah.
Orang-orang ini sepertinya bekerja tanpa lelah untuk membuat orang lain mengikuti cara mereka melakukan sesuatu.
Website ini dibuat dalam upaya menyajikan pandangan pragmatis tentang pemrograman PHP. Pandangan yang ditentukan oleh pengalaman dan konsekuensi praktis, bukan tren populer, teori, atau doktrin akademis.
Website PHP - The Wrong Way adalah dokumen yang aktif dan akan terus diperbarui dengan lebih banyak informasi saat tersedia.
Jangan ragu untuk berkontribusi.
Salah satu masalah dengan aturan dan pedoman pemrograman pada umumnya aturan dan pedoman tersebut hanya melayani tujuan dalam konteks tertentu. Jika tidak sesuai konteks, peraturan yang baik bisa menjadi peraturan yang buruk. Faktanya, setiap aturan yang baik menjadi buruk jika diterapkan secara ekstrem.
Hal ini penting untuk dipahami karena banyak prinsip dan aturan pengembangan software yang dikembangkan dari waktu ke waktu dan disajikan oleh banyak orang sering kali disalahgunakan oleh para ekstremis.
Pengalaman telah mengajarkan bahwa penyalahgunaan peraturan dan pedoman umum selalu mengakibatkan komplikasi, kurangnya keamanan, hasil yang rawan kesalahan, dan dalam beberapa kasus menjadi bencana total.
KISS principle, yang merupakan singkatan dari “Keep It Simple, Stupid”, adalah prinsip yang sangat bijaksana dan baik yang umumnya dipandang oleh orang-orang berpengalaman sebagai anjuran yang sangat baik untuk diikuti. Namun prinsip besar ini pun bisa menjadi bahaya bagi sebuah proyek jika dilakukan secara ekstrem. Ada yang namanya “terlalu sederhana” yang mengakibatkan kurangnya fungsionalitas yang dibutuhkan.
Cara yang salah: Ketaatan pada aturan dan pedoman secara utuh. 
Semua framework umum PHP itu payah!
Dalam komunitas PHP, tren yang sangat buruk telah menjadi standar de-facto untuk mengembangkan aplikasi web dan itu adalah dengann menggunakan framework umum PHP yang populer.
Tren ini muncul dan menjadi populer bukan karena meningkatkan hasil proses pengembangan, atau karena merupakan hal yang benar untuk dilakukan dari sudut pandang teknologi dan arsitektur. Tren ini menjadi populer karena beberapa pengembang framework telah berhasil menyapu bersih massa dengan polemik mereka terhadap pemrograman dari awal dengan syair seperti “Jangan menulis kembali hal itu!” dan “Jangan lakukan sendiri, orang lain lebih ahli darimu.
Banyak programmer masa kini yang sepenuhnya mengabaikan prinsip-prinsip dasar pemrograman dan mereka menghabiskan banyak waktu membayangkan lapisan kompleksitas baru agar terlihat lebih pintar, lebih keren, dan lebih dapat diterima oleh siapa pun yang mereka anggap sebagai rekan mereka.
Orang-orang ini tampaknya tergila-gila dengan pemikiran agar orang lain mengikuti “cara melakukan sesuatu” mereka, menjadi semacam pemimpin komunitas PHP, dan meminta orang lain menggunakan alat Open Source “keren” terbaru mereka, sehingga mereka lupa untuk memastikannya bahwa nasihat yang mereka berikan terdengar masuk akal dan berbobot.
Dalam industri software kamu dapat membandingkan rumah yang sudah dibangun dengan framework umum. Membangun software menggunakan framework umum tidak menjadikan kamu seorang pembuat kode atau programmer, sama seperti menyusun rumah yang sudah dibangun sebelumnya tidak menjadikan kamu seorang tukang kayu.
Di situs web ini, kami membedakan antara framework dan library dengan cara berikut:
Dalam dunia Python dan Ruby, membangun situs web dari awal adalah hal yang melelahkan karena baik Python maupun Ruby pada awalnya tidak dibuat untuk membangun situs web. Akibatnya framework seperti Django dan Ruby on Rails dengan cepat menjadi populer untuk membangun situs web dalam bahasa-bahasa ini.
PHP di sisi lain diciptakan pada awalnya oleh Rasmus Lerdorf sebagai seperangkat alat yang ditulis dalam C yang memungkinkan kamu mengembangkan HTML dinamis dengan mudah dan cepat. Seperti PHP dulu dan sekarang, adalah framework itu sendiri.
PHP telah berkembang pesat sejak saat itu dan saat ini PHP dapat digunakan lebih dari sekedar membangun HTML dan situs web, namun melihat PHP sebagai semacam framework itu sendiri tidaklah salah. PHP pada dasarnya adalah lapisan abstraksi untuk mengembangkan aplikasi web yang seluruhnya ditulis dalam prosedural C.
Menggunakan library dalam proyek kamu adalah hal yang wajar. PHP sendiri dibundel dengan sekumpulan library yang dapat kamu gunakan untuk memperluas kode kamu sendiri. PDO misalnya adalah library ringan yang menyediakan interface yang konsisten untuk mengakses database di PHP.
Sebaliknya, menggunakan framework di atas PHP adalah masalah yang sama sekali berbeda.
Saat kamu menggunakan framework di PHP, kamu menambahkan lapisan abstraksi di atas lapisan abstraksi lainnya, yang mana sudah tersedia untuk digunakan sejak awal. Lapisan abstraksi tambahan yang disediakan framework mungkin hanya berfungsi untuk mengatur kode kamu ke dalam serangkaian pola yang telah ditetapkan sebelumnya, atau mungkin menambah kompleksitas dengan menyatukan ratusan atau bahkan ribuan kelas dan metode ke dalam mimpi buruk ketergantungan, apa pun caranya. kamu menambahkan lapisan kerumitan pada kode kamu yang tidak diperlukan!
Semua pengalaman dimulai dengan interface. Pengalaman interface adalah hasil dari teknologi yang mendasarinya dan jumlah lapisan abstraksi. Semakin banyak abstraksi yang kamu gunakan, semakin berkurang efisiensi dari interfacenya dan aplikasi menjadi semakin rentan terhadap kesalahan. Semakin tinggi abstraksinya, semakin banyak detail dan efisiensi yang hilang.
Pahami ini dengan jelas: Jumlah baris kode yang ideal dalam proyek apa pun adalah sesedikit mungkin, namun tetap jelas dan mudah dibaca!
Yang tidak dibutuhkan semua orang adalah framework tujuan umum. Tidak ada seorang pun yang mempunyai masalah yang sama, setiap orang mempunyai masalah yang sangat spesifik yang ingin mereka selesaikan.
Beberapa perusahaan mulai mendengarkan hype tentang framework PHP dan mereka memulai proyek berikutnya menggunakan salah satu framework tujuan umum yang populer ini hanya untuk berakhir dengan bencana. Mereka tidak hanya menemukan bahwa framework tujuan umum sangat buruk dalam menyelesaikan kebutuhan spesifik mereka, namun juga sangat lambat dalam menyelesaikannya. Tidak mungkin untuk melakukan penskalaan dan akibatnya mereka mulai merobek framework tersebut dalam upaya putus asa untuk mengeluarkan semua hal yang sebenarnya tidak mereka perlukan.
Selalu gunakan pendekatan pragmatis:
Tindakan atau kebijakan ditentukan oleh pertimbangan konsekuensi praktis langsung dan bukan berdasarkan teori atau doktrin.
– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014
Cara yang salah: Selalu gunakan framework di atas PHP.
Saya memiliki alergi besar terhadap desain dan pola desain menara gading. Peter Norvig, ketika dia masih di Harlequin, dia membuat makalah ini tentang bagaimana pola desain sebenarnya hanyalah kelemahan dalam bahasa pemrogramanmu. Dapatkan bahasa pemrograman yang lebih baik. Dia benar sekali. Memuja pola dan memikirkan, “Oh, aku akan menggunakan pola X.”
– Brendan Eich pada Coders at work - Reflections on the Craft of Programming
Dalam rekayasa software, pola desain adalah solusi yang dapat digunakan kembali untuk masalah yang umum terjadi dalam desain software. Pola desain bukanlah desain akhir yang dapat diubah langsung menjadi kode. Ini adalah deskripsi atau ide tentang cara memecahkan suatu masalah yang dapat digunakan dalam berbagai situasi. Pola desain berorientasi objek biasanya menunjukkan hubungan dan interaksi antar kelas atau objek, tanpa menentukan kelas atau objek aplikasi akhir yang terlibat.
PHP mendukung paradigma imperatif, fungsional, berorientasi objek, prosedural, dan reflektif. PHP adalah kotak peralatan besar dengan banyak alat berbeda yang memungkinkan penyelesaian banyak masalah dengan berbagai cara - bukan hanya satu cara.
PHP is all about freedom, fast and scalable solutions, and having many different ways to deal with problems.
Ketika kita mencoba untuk meningkatkan diri kita sendiri, dan dalam hal ini lebih khusus lagi kode kita, kita terkadang terpaku pada filosofi pola atau ide tertentu dan cenderung lupa untuk berpikir secara praktis.
Ketika saya melihat pola dalam program saya, saya menganggapnya sebagai tanda adanya masalah. Bentuk suatu program harus mencerminkan masalah yang perlu dipecahkan. Keteraturan lain dalam kode adalah tanda, setidaknya bagi saya, bahwa saya menggunakan abstraksi yang tidak cukup kuat - sering kali saya membuat sendiri perluasan beberapa makro yang perlu saya tulis.
Kita tidak boleh terlalu terjebak dalam filosofi atau gagasan di balik pola atau solusi tertentu. Perhatian utama kami adalah menjaga kode agar mudah dinavigasi dan dipahami, sehingga mudah dipelihara dan dijaga keamanannya.
Kita juga harus ingat bahwa ada yang namanya anti-pola. Ini adalah pola yang umum digunakan namun tidak efektif dan/atau kontraproduktif dalam praktiknya.
Saya pikir pola dimulai sebagai solusi terbaik yang diakui secara umum untuk masalah-masalah umum. Namun kini pola tersebut telah ada sejak lama dan kita telah melihat aplikasi dibuat sepuluh kali lebih rumit dari yang seharusnya karena orang-orang mencoba menjejalkan semua pola yang telah mereka baca (“aplikasi saya dirancang dengan baik, karena itu dimuat ke insang dengan pola.”) kesan saya terhadap nilai pola tersebut telah sedikit berubah.
– Paul Weaton pada Evil Design Patterns
Selalu gunakan pendekatan pragmatis:
Tindakan atau kebijakan ditentukan oleh pertimbangan konsekuensi praktis langsung dan bukan berdasarkan teori atau dogma.
– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014
Cara yang salah: Mencari pola untuk memecahkan suatu masalah.
Masalah dengan bahasa berorientasi objek adalah mereka mempunyai semua lingkungan implisit yang mereka bawa. Kamu menginginkan pisang tetapi yang kamu dapatkan adalah seekor gorila yang memegang pisang dan seluruh hutan.
– Joe Armstrong pada Coders at work - Reflections on the Craft of Programming
Abstraksi sangat kuat. Apa yang benar-benar membuat saya alergi, dan reaksi saya di tahun 90an, adalah semua omong kosong berorientasi objek CORBA, COM, DCOM. Setiap start up hari ini memiliki sesuatu yang gila yang memerlukan 200.000 panggilan metode untuk memulai dan mencetak “Halo dunia”. Itu sebuah parodi! kamu tidak ingin menjadi seorang programmer yang dikaitkan dengan hal semacam itu.
– Brendan Eich pada Coders at work - Reflections on the Craft of Programming
Banyak pengembang software, dan banyak perusahaan, merasa bahwa pemrograman berorientasi objek adalah satu-satunya cara yang masuk akal untuk mengembangkan software saat ini. Siapa pun yang menentang pemrograman berorientasi objek akan segera menyadari fakta bahwa mereka menentang “kebijaksanaan konvensional” industri.
Di blog dan forum pemrograman, ada banyak sekali orang yang membela pemrograman berorientasi objek, dan merasa yakin bahwa mereka tahu apa yang mereka bicarakan, meskipun tidak ada definisi standar!
Faktanya adalah bahwa apa yang disebut pemrograman berorientasi objek sering kali menimbulkan beban berat dengan kompleksitas yang tidak diperlukan!
Sebagai ilmuwan dan pemrogram komputer, kita harus belajar mengesampingkan prasangka dan menemukan solusi terbaik terhadap suatu masalah.
Saat ini, salah satu kekuatan utama PHP adalah dukungannya terhadap paradigma imperatif, fungsional, berorientasi objek, prosedural, dan reflektif. PHP adalah kotak peralatan besar dengan banyak alat berbeda yang memungkinkan penyelesaian banyak masalah dengan berbagai cara - bukan hanya satu arah!
Segera setelah kami mencoba untuk memaksakan masalah yang berbeda dalam suatu aplikasi ke satu paradigma pemrograman tertentu, kami tidak berpikir kreatif dan kami tidak bekerja secara efisien!
Salah satu cara terbaik untuk memahami paradigma pemrograman tertentu adalah dengan melihat bagaimana paradigma tersebut pertama kali berkembang. Apa alasan perkembangannya? Masalah apa yang ada pada paradigma pemrograman lain yang memerlukan cara berpikir baru? Apakah ini masalah dunia nyata atau sekadar masalah akademis? Dan bagaimana perkembangannya?
Tidak peduli apa yang dikatakan oleh orang X atau definisi apa yang diberikan oleh orang Y, yang penting dalam konteks paradigma adalah sejarah yang membentuk paradigma tersebut.
Ada dua cara untuk membangun desain software. Salah satu caranya adalah dengan membuatnya sesederhana mungkin sehingga jelas tidak ada kekurangannya. Dan cara lainnya adalah dengan membuatnya sedemikian rumit sehingga tidak ada kekurangan yang terlihat jelas.
Di masa lalu, sebelum munculnya pemrograman berorientasi objek, sekitar akhir tahun lima puluhan, banyak software dikembangkan menggunakan bahasa pemrograman yang menekankan pemrograman tidak terstruktur, kadang-kadang disebut sebagai bahasa generasi pertama dan kedua. Pemrograman tidak terstruktur (atau pemrograman tidak terstruktur) secara historis merupakan paradigma pemrograman paling awal. Itu dikritik habis-habisan karena menghasilkan kode “spaghetti”.
Ada bahasa pemrograman tingkat tinggi dan rendah yang menggunakan pemrograman tidak terstruktur. Ini termasuk versi awal BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, kode tingkat mesin, sistem assembler awal (yang tidak memiliki operator meta prosedural) dan beberapa bahasa skrip.
Sebuah program dalam bahasa tidak terstruktur biasanya terdiri dari perintah atau pernyataan yang diurutkan secara berurutan, biasanya satu di setiap baris. Baris biasanya diberi nomor atau mungkin memiliki label yang memungkinkan alur eksekusi melompat ke baris mana pun dalam program (seperti pernyataan GOTO yang tidak populer).
Kemudian, pada tahun enam puluhan, pemrograman terstruktur muncul - terutama karena surat terkenal dari Edsger W. DijkstraPernyataan Go To dianggap berbahaya.
Pemrograman terstruktur adalah paradigma pemrograman yang meningkatkan kejelasan, kualitas, dan pengembangan software dengan memanfaatkan subrutin, struktur blok, dan loop. Hal ini berbeda dengan penggunaan lompatan sederhana seperti pernyataan GOTO.
Kemudian, pemrograman prosedural diturunkan dari pemrograman terstruktur. Pemrograman prosedural didasarkan pada konsep “panggilan prosedur”. Sebuah "panggilan prosedur" hanyalah nama lain untuk "panggilan fungsi". Prosedur juga dikenal sebagai rutinitas, subrutin, atau metode. Prosedur hanya berisi serangkaian langkah komputasi yang harus dilakukan. Setiap prosedur tertentu dapat dipanggil kapan saja selama eksekusi program, termasuk oleh prosedur lain atau prosedur itu sendiri.
Pada awalnya semua prosedur tersedia untuk setiap bagian program sebagai data global. Dalam program-program kecil, hal ini tidak menimbulkan masalah, namun seiring dengan semakin rumitnya dan semakin besarnya ukuran program, perubahan kecil pada satu bagian program akan berdampak besar pada banyak bagian lainnya.
Tidak ada yang merencanakan perubahan dalam program dan banyak ketergantungan yang muncul. Perubahan kecil pada satu prosedur akan mengakibatkan serangkaian kesalahan di banyak prosedur lain yang bergantung pada kode aslinya.
Sebuah teknik baru berkembang yang memungkinkan data dibagi ke dalam cakupan terpisah yang disebut “objek”. Hanya prosedur spesifik dalam lingkup yang sama yang dapat mengakses data yang sama. Ini disebut penyembunyian data atau enkapsulasi. Hasilnya adalah kode yang terorganisir jauh lebih baik.
Pada awalnya objek tidak disebut objek, mereka hanya dipandang sebagai lingkup yang terpisah. Kemudian ketika ketergantungan dikurangi dan hubungan antara prosedur dan variabel dalam lingkup ini dipandang sebagai segmen yang terisolasi, hasilnya melahirkan konsep “objek” dan “pemrograman berorientasi objek”.
Kemudian, terutama karena perkembangan Java, “kata kunci” tertentu muncul dan “prosedur” atau “fungsi” tidak lagi disebut fungsi, namun diganti namanya menjadi “metode” ketika berada dalam lingkup yang terpisah. Variabel juga tidak lagi disebut “variabel”, tetapi diganti namanya menjadi “atribut” ketika berada dalam lingkup terpisah.
Jadi suatu objek pada dasarnya hanyalah kumpulan fungsi dan variabel yang sekarang disebut “metode dan atribut”.
Cara metode dan atribut tetap terisolasi dalam lingkup terpisah adalah dengan menggunakan “kelas”. Sebuah kelas, setelah dibuat instance-nya, disebut objek.
Objek dapat saling mereferensikan dan dengan referensi tersebut metode (fungsi) di dalamnya dapat “berkomunikasi” satu sama lain. Objek juga dapat “mewarisi” metode dari objek lain sehingga memperluas metode tersebut, hal ini disebut “pewarisan”. Ini adalah cara untuk menggunakan kembali kode dan mengizinkan ekstensi independen software melalui kelas dan antarmuka publik. Hubungan objek menimbulkan hierarki. Warisan ditemukan pada tahun 1967 untuk bahasa pemrograman Simula 67.
Objek juga dapat mewarisi metode dari objek lain dan “menimpa” metode tersebut dengan menambahkan atau mengubah fungsionalitas, hal ini disebut “polimorfisme”.
Bagaimana ide-ide yang berbeda ini diimplementasikan sangat bervariasi dari satu bahasa pemrograman ke bahasa pemrograman lainnya.
Pemrograman berorientasi objek adalah tentang mengatur kode dengan cara yang berbeda dari sebelumnya. Ini adalah perpanjangan dari pemrograman prosedural dan tentang menyembunyikan data (enkapsulasi) dan menghindari cakupan global. Ini tentang memperluas fungsi dengan “meminjam” cetak birunya tanpa benar-benar mempengaruhi kode aslinya (warisan). Dan ini tentang mengganti fungsi tanpa mempengaruhi kode asli (polimorfisme).
Model berorientasi objek memudahkan pembuatan program secara bertahap. Artinya, dalam praktiknya, hal ini menyediakan cara terstruktur untuk menulis kode yang berantakan.
– Paul Graham pada Ansi Common Lisp
Cara yang salah: Selalu menggunakan pemerograman beriorentasi objek.
Argumen yang sering dikemukakan untuk penggunaan framework adalah bahwa orang tidak ingin berurusan dengan basis kode yang telah ditulis dari awal oleh orang lain.
Namun ini adalah mentalitas yang aneh, terutama ditemui di kalangan pengembang web di komunitas PHP. Ini menunjukkan kurangnya profesionalisme dan pengalaman.
Menulis software dan menangani kode orang lain adalah hal yang normal. Itu adalah bagian dari pekerjaan sehari-hari seorang programmer profesional. Ini bukanlah sesuatu yang perlu ditakuti.
Seorang pemrogram profesional tidak akan melihat kode orang lain dan mulai mengeluh tentang bagaimana dia sepenuhnya bergantung pada mantan pemrogram, yang mungkin tidak lagi terkait dengan perusahaan atau proyek, dan andai saja mantan pemrogram tersebut menggunakan framework A atau framework B hari itu akan terselamatkan.
Ini bukanlah mentalitas seorang programmer profesional. Tidak ada yang melakukan ini.
Mungkin rendahnya hambatan masuk dalam pengembangan web PHP berperan dalam mentalitas seperti ini. Apapun itu, itu tandanya seseorang berada di bidang pekerjaan yang salah.
Sebagian besar pemrograman berhubungan dengan orang yang harus bekerja dengan kode orang lain. Ini adalah bagian dari upaya untuk meningkatkan basis kode yang ada dan terkadang melibatkan penulisan ulang secara menyeluruh.
Catatlah dari para ahli pemrograman yang hebat, bacalah bukunya Coders at work - Reflections on the Craft of Programming.
Beberapa basis kode terbesar dan tersukses di dunia adalah basis kode yang telah dikembangkan oleh ratusan orang yang bahkan belum pernah bertemu satu sama lain, basis kode dikembangkan tanpa menggunakan framework apa pun, basis kode dilakukan seluruhnya dalam bahasa pemrograman prosedural tanpa menggunakan framework apa pun. apa pun kecuali paradigma prosedural, dan mereka tidak akan bermimpi untuk melakukannya secara berbeda.
Sebuah Linux Kernel terdiri dari lebih dari 20 juta baris kode yang semuanya ditulis seluruhnya menggunakan pemrograman prosedural oleh lebih dari 14.000 peserta tanpa menggunakan framework apa pun.
perbedaan antara BSD dan kebanyakan Linux GNU userland telah ditulis seluruhnya menggunakan pemrograman prosedural tanpa menggunakan framework apa pun.
Hal yang sama berlaku untuk ratusan proyek Open Source di seluruh dunia yang akhirnya ditinggalkan oleh pemrogram aslinya hanya untuk diambil alih oleh pemrogram terampil lainnya. Banyak dari proyek ini yang hanya memiliki sedikit dokumentasi (jika ada), tidak ada komentar dalam basis kode, dan tidak ada pedoman atau bantuan untuk ditawarkan sama sekali.
Seluruh basis kode PHP dilakukan dalam C, bahasa pemrograman prosedural murni, tanpa menggunakan framework apa pun.
Setiap kali kamu mendefinisikan kelas dalam PHP atau setiap kali kamu menjalankan framework PHP favorit Anda, kamu menjalankan pekerjaan prosedural murni milik orang lain!
Tentu saja, ada sesuatu seperti kode yang buruk, kode yang mungkin tidak dirancang sejak awal, atau kode yang mungkin sudah terlalu besar berkali-kali tetapi klien tidak mau menulis ulang, kode yang sangat buruk kamu tidak dapat lagi menyimpulkan apa yang terjadi, namun tidak ada framework yang bisa mencegah situasi ini. Hal ini sering kali merupakan proses pertumbuhan alami suatu program. Pada akhirnya framework apa pun akan hancur berkeping-keping.
Dan tentu saja ada kode berantakan yang mengerikan, tetapi tidak ada yang sengaja membuat kode berantakan yang mengerikan. Terkadang hal ini disebabkan oleh kurangnya pengalaman, sering kali ini adalah kesalahan klien karena mereka mengubah spesifikasi beberapa kali di tengah pengembangan, dalam kedua kasus tersebut, bahkan jika framework digunakan, hasilnya tetap berupa kode yang berantkan, dan tidak peduli berapa banyak paradigma berorientasi objek yang digunakan, hasilnya tetap berupa kode yang berantakan.
As programmers we all try to prevent these situations, but this is normal, this is the art of programming, this is part of what it means to be a programmer!
Cara yang salah: Takut dengan kode orang lain.
FIG adalah singkatan dari “Framework Interoperability Group”.
PHP-FIG dibuat oleh sejumlah pengembang framework di php|tek pada tahun 2009. Sejak itu berbagai anggota lainnya telah mendaftar dan dipilih, sehingga meningkatkan ukuran grup dari 5 orang pertama menjadi lebih dari 20 orang.
Banyak kontroversi muncul mengenai PHP-FIG. Beberapa orang menganggap PHP-FIG sebagai hal terbaik yang pernah terjadi pada komunitas PHP sejak PHP itu sendiri, sementara yang lain menganggap grup tersebut sebagai sesuatu yang sebaiknya dilupakan.
Salah satu masalah dengan PHP-FIG adalah ia menampilkan FAQ dirinya seperti ini di dalamnya :
Ide di balik kelompok ini adalah agar perwakilan proyek dapat membicarakan kesamaan antara proyek-proyek kami dan menemukan cara untuk bekerja sama. Audiens utama kami adalah satu sama lain, namun kami sangat sadar bahwa komunitas PHP lainnya juga menonton. Jika orang lain ingin mengadopsi apa yang kami lakukan, mereka boleh melakukannya, tapi itu bukan tujuannya. Tidak ada seorang pun di grup yang ingin memberi tahu Anda, sebagai programmer, cara membangun aplikasi Anda.
Namun, jika kita melihat pekerjaan beberapa anggota kelompok, kita dapat melihat dengan jelas bahwa tujuannya sangat bertentangan dengan pernyataan di atas. Para anggota ini bekerja tanpa kenal lelah dalam upaya menjadikan PHP-FIG menjadi “kelompok standar PHP” yang diterima. yang juga merupakan nama asli grup tersebut. Mereka melakukan ini dengan mengklasifikasikan pekerjaan PHP-FIG sebagai “PHP Modern” dalam buku-buku mereka, di situs web mereka, posting blog, forum, dll., dan dengan mengklasifikasikan cara-cara lain sebagai kebalikannya.
Salah satu masalah dengan PHP-FIG adalah meskipun banyak framework dan proyek Sumber Terbuka telah mengadopsi beberapa standar mereka, standar-standar ini terutama menangani masalah dari “perspektif framework”, yang menjadikannya tidak dapat digunakan di banyak industri kehidupan nyata. situasi.
Banyak orang mengembangkan software untuk industri yang harus sangat efisien, aman, dan hemat biaya, software yang ingin dibeli dan digunakan oleh pelanggan. Mereka tidak bisa diganggu dengan standar yang harus disesuaikan dengan kebutuhan para fanatik framework. Jika mereka mencoba melakukannya, itu akan menjadi bencana bagi bisnis.
Jika suatu kelompok standar perlu dibuat, hal itu harus mencerminkan kepentingan seluruh komunitas PHP, bukan hanya pengembang proyek framework dan CMS Open Source. Itu harus diwakili oleh pengembang bahasa pemrograman PHP itu sendiri dan harus diwakili oleh keanggotaan yang jauh lebih besar dengan hak untuk memilih.
Jika kamu memilih untuk mengadopsi standar yang dikembangkan oleh PHP-FIG, kamu harus memahami bahwa beberapa standar ini - seperti standar autoloader PSR-0 dan PSR-4 dan beberapa standar lainnya - memiliki efek langsung pada cara kamu mengkodekan kode kamu. software.
Banyak industri memerlukan software yang sangat skalabel, run-time kritis, dan hemat biaya yang tidak dapat dikembangkan menggunakan standar PHP-FIG ini.
Cara yang salah: Mengikuti standa PHP-FIG secara taat.
– Seymour Cray padaMasalah dengan pemrogram adalah kamu tidak akan pernah bisa mengetahui apa yang sedang dilakukan seorang pemrogram sampai semuanya sudah terlambat. defprogramming.com
Pengkodean aman adalah praktik penulisan program yang tahan terhadap serangan orang atau program lain yang jahat atau nakal. Pengkodean yang aman membantu melindungi data dari pencurian atau korupsi. Selain itu, program yang tidak aman dapat memberikan akses bagi penyerang untuk mengambil kendali atas server atau identitas pengguna, yang mengakibatkan penolakan layanan kepada satu pengguna hingga kebocoran rahasia, hilangnya layanan, atau kerusakan pada sistem. dari ribuan pengguna.
Setiap program komputer merupakan target potensial serangan keamanan. Penyerang akan mencoba menemukan kerentanan keamanan di aplikasi Anda. Mereka kemudian akan mencoba menggunakan kerentanan ini untuk mencuri rahasia, merusak program dan data, serta mendapatkan kendali atas server dan jaringan. Properti pelanggan kamu dan reputasi kamu dipertaruhkan.
Keamanan bukanlah sesuatu yang dapat ditambahkan ke software!
Aplikasi yang tidak aman mungkin memerlukan desain ulang yang ekstensif untuk mengamankannya. kamu harus mengidentifikasi sifat ancaman terhadap software kamu dan menerapkan praktik pengkodean yang aman sejak awal dan sepanjang perencanaan dan pengembangan aplikasi Anda.
Mengamankan sumber daya software penting menjadi lebih penting dari sebelumnya karena fokus penyerang terus berpindah ke lapisan aplikasi. Sebuah studi SANS tahun 2009 menemukan bahwa serangan terhadap aplikasi web mencakup lebih dari 60% total upaya serangan yang diamati di Internet.
PHP tidak biasa karena merupakan bahasa pemrograman dan framework web pada saat yang bersamaan. Ini berarti PHP memiliki banyak fitur web bawaan dalam bahasa tersebut yang membuatnya sangat mudah untuk menulis kode yang tidak aman.
Kompleksitas membunuh. Hal ini menyedot kehidupan para pengembang, membuat produk sulit untuk direncanakan, dibangun dan diuji, menimbulkan tantangan keamanan dan menyebabkan frustrasi pengguna akhir dan administrator.
Agar aplikasi dapat dirancang dan diimplementasikan dengan persyaratan keamanan yang tepat, praktik pengkodean yang aman dan fokus pada risiko keamanan harus diintegrasikan ke dalam operasi sehari-hari, pemikiran, dan proses pengembangan itu sendiri.
Secara umum, membangun software yang aman jauh lebih murah dibandingkan memperbaiki masalah keamanan setelah paket software selesai dibuat, belum lagi biaya yang mungkin terkait dengan pelanggaran keamanan.
Cara yang salah: Tidak menggunakan keamanan bawaan software
Sangat mudah untuk salah memahami dokumen tertulis, jadi mari kita perjelas beberapa masalah.
Pertanyaan: Apa gunanya situs ini dan mengapa pendekatannya konfrontatif?
Jawaban: Untuk menciptakan diskusi dan pemikiran tentang praktik terkini dan pandangan ekstrem.
Pertanyaan: Apakah kamu mengatakan pemrograman berorientasi objek itu buruk atau salah?
Jawaban: Tidak, tentu saja tidak! Kami mengatakan bahwa selalu memikirkan dan hanya menggunakan paradigma berorientasi objek dalam memecahkan masalah adalah hal yang buruk. Kapan pun kamu berpikir hitam-putih saja, itu salah.
Bahkan dalam satu aplikasi pun terdapat masalah yang berbeda. Multiparadigma terkadang merupakan solusi terbaik, semuanya tergantung pada masalah yang ingin kamu selesaikan.
Setiap kali kamu memaksakan masalah tertentu ke solusi yang tidak tepat, hal buruk akan terjadi.
Pertanyaan: Apakah kamu mengatakan bahwa semua framework itu buruk?
Jawaban: Kami tidak mencoba menilai framework tertentu. Kami sedang menghadapi masalah selalu menggunakan framework di atas PHP.
Pertanyaan: Jika suatu framework dapat membuat saya aktif dan berjalan dengan cepat, mengapa hal itu sangat buruk?
Jawaban: Jika kamu telah menganalisa situasi dan implikasi jangka panjangnya dan kamu kemudian melihat bahwa “berdiri dan berjalan dengan cepat” adalah satu-satunya masalah yang harus kamu hadapi, maka itu tidak buruk, tapi kita tidak lagi berurusan dengan pemrograman atau pengembangan software. kita kebanyakan berurusan dengan solusi tunjuk-dan-klik.
Memulai dan menjalankannya dengan cepat bukanlah berarti merancang software, ini berarti kamu belum menganalisis masalah yang kamu hadapi dan belum memahami implikasi jangka panjang dari pilihan Anda.
Pertanyaan: Apakah menurut kamu package thrid party itu buruk?
Jawaban: Tidak. Kami mempromosikan penggunaan library thrid party. Kode yang dapat kamu integrasikan dengan mudah ke dalam proyek kamu sendiri tanpa menerapkan batasan atau batasan apa pun. Itu bagus sekali!
Pertanyaan: Siapa kamu?
Jawaban: Situs web ini berisi tentang gagasan dan pemberantasan ekstremisme dalam komunitas PHP, bukan tentang ketenaran atau pengakuan pribadi. Menyebutkan nama orang hanya akan mengalihkan fokus dari masalah yang dibahas di situs web ke orang yang menangani masalah tersebut. Tetap fokus pada ide-idenya.
Pertanyaan: Apa pengalamanmu dalam pengembangan software?
Jawaban: Ide, pemikiran dan kesimpulan yang diungkapkan dalam website ini tidak memerlukan banyak pengalaman untuk mencapainya jika kamu tetap fokus pada tema utama yaitu selalu melakukan suatu hal tertentu karena orang lain mengatakan demikian.
PHP The Wrong Way on Hacker News
Why bad scientific code beats code following “best practices”
Coders at work - Reflections on the Craft of Programming
The traits of a proficient programmer
OWASP Secure Coding Guidelines
Survive The Deep End: PHP Security
Refactoring Improving the Design of Existing Code
Understanding programming languages
Kontribusi pada GitHub.