Kebetulan sebagian besar hidup saya yang saya program di PHP. Otak kita, memahami informasi dari sumber mana pun, melakukan ini tanpa gangguan dari otoritas sumber ini. Secara kasar, jika Anda menyukai PHP - Anda secara otomatis menambahkan poin kredibilitas ke penulis artikel ini, dan jika Anda tidak suka - mereka secara otomatis mengambilnya. Proses ini terjadi pada tingkat bawah sadar dan pada dasarnya adalah prisma persepsi, yang di satu sisi melindungi kita dari jatuh ke dalam analisis informasi tanpa batas dari setiap tingkat otoritas, tetapi di sisi lain membatasi kita dalam mencari informasi baru yang lebih relevan. Yang terburuk adalah bahwa kredibilitas sumber jarang diperiksa pada tingkat yang disadari (karena butuh waktu dan sumber daya dalam bentuk kalori yang berharga), saya bisa dengan probabilitas yang sama dengan pengembang plus, ibu rumah tangga-juru masak, tukang ledeng tanpa putri, atau rekayasa genetika. kucing Jangan menilai artikel saya dengan ketat, saya punya cakar.
Hal yang sama berlaku untuk membaca kode orang lain: jika penulisnya duduk di sebelah kiri tahta Anda, telah bekerja di perusahaan Anda selama 10+ tahun dan menghasilkan satu nol lebih banyak dari Anda, ini sama sekali tidak sama dengan penulis yang dipecat karena sesuatu- itu buruk, dan Anda dipekerjakan di tempatnya. Namun pada kenyataannya, kode di sana-sini hanya satu set byte yang akan berguna untuk dievaluasi tanpa mengacu pada otoritas sumber.
Ketika kita membaca kode orang lain, berbagai macam emosi dapat mengunjungi kita: kekaguman, tawa, kejengkelan, kekecewaan, penolakan total. Berguna untuk mengetahui bahwa manifestasi emosi apa pun dalam konteks apa pun adalah respons otomatis dari tingkat yang lebih rendah (pertama) dari sistem saraf, yang dibentuk secara evolusioner, diperlukan dalam lingkungan primitif. Tugas utama dari jawaban semacam itu, dalam kasus emosi "negatif", adalah meluncurkan mekanisme aksi "pukul atau lari" dengan satu tujuan tunggal - untuk bertahan hidup. Di lingkungan kantor kami saat ini, ketika menganalisis kode orang lain, jawaban seperti itu menjadi agak tidak berguna dan bahkan berbahaya, karena Anda menghabiskan waktu dan sumber daya yang berharga di atasnya, ditambah Anda mencemari otak Anda dengan neurotransmiter yang menurunkan kecerdasan Anda untuk kecepatan reaksi. Berita baiknya adalah bahwa jawaban ini dapat diprogram ulang. Anda dapat menekan reaksi emosional negatif, atau Anda dapat menginventarisasinya, misalnya, tertawa di tempat Anda dulu marah. Tawa, tidak seperti amarah, mengeluarkan neurotransmiter yang baik, enak, bermanfaat yang memberikan kesenangan, memperkuat pengalaman dan memotivasi Anda untuk terus bekerja.
Untuk memprogram ulang emosi, Anda perlu secara mental memasuki meta-posisi untuk mengevaluasi situasi Anda sendiri dan mengevaluasi diri sendiri alih-alih mengutuk kode orang lain. Mengapa potongan kode orang lain ini membuat saya jijik? Benarkah sang amatir yang menulisnya, dan sekarang saya harus menderita begitu baik dan berpengalaman? Jika saya sangat baik dan berpengalaman, lalu mengapa saya mengalami masalah untuk memahami kode orang lain dan menulis ulang sesuai keinginan saya? Mungkin saya tidak punya cukup RAM untuk mewujudkan mie ini? Mungkin penulis artikel ini tahu sesuatu yang tidak saya ketahui?
Alat pengembangan modern memungkinkan Anda mengubah kode orang lain menjadi struktur yang lebih mudah dimengerti dan menyenangkan. Sebuah fungsi atau variabel tidak bernama - ctrl + shift + R dan dalam beberapa detik ini disebut baik. Tab alih-alih spasi, lekukan yang tidak nyaman, lekukan yang tak biasa dan membuka kawat gigi dalam gaya Mesir - ctrl + shift + F dan pemformatan dipulihkan! Komentar redundan atau ketinggalan jaman - ctrl + D dan tidak. Jika Anda mengubah prisma persepsi, membaca kode orang lain dapat berubah menjadi permainan detektif interaktif yang menyenangkan.
Kode hanyalah alat. Tidak peduli betapa buruk dan buruknya ia ditulis, pada waktu tertentu dan di tempat tertentu ia berhasil memecahkan masalah tertentu, yang berarti ia sudah "dibenarkan." Sesuatu telah berubah dalam persyaratan bisnis, sesuatu belum diperhitungkan - kode telah rusak atau menjadi usang, dan ini normal. Kode memiliki kemampuan untuk berkembang dalam berbagai cara: dan secara bertahap, ditumbuhi lapisan dan revolusioner, menulis dari awal. Tentu saja, ada baiknya ketika programmer melihat masa depan dan pada tahap awal ada kemungkinan pengembangan lebih lanjut. Tapi kapak ini tajam di dua sisi, Anda dapat membuat kesalahan dengan memprediksi masa depan, masa depan mungkin tidak datang sama sekali, dan waktu dan sumber daya akan hilang. Penting untuk memahami kode sampai tingkat kualitas apa yang dituntut dari Anda. Jika ini adalah sistem terdistribusi besar, modul yang diprogram oleh kolega Anda dari seluruh dunia di perusahaan yang terhubung dengan Anda, maka ya, masuk akal untuk menggunakan pola modis, untuk membungkus modul dalam wadah layanan bahkan di mana Anda tidak dapat membayangkan mengapa ini perlu. Tetapi jika ini adalah CRM lokal kecil untuk satu perusahaan, modul yang sangat saling tergantung satu sama lain sehingga menonaktifkan modul apa pun pada dasarnya menghentikan seluruh sistem dari bekerja ... dalam hal ini, dapat dibenarkan untuk memanggil metode orang lain secara langsung, ini akan mengurangi jumlah kelas dan memfasilitasi operasional Anda memori dan mengurangi waktu untuk men-debug masalah. Tapi di sini muncul situasi ketika CRM lokal kecil berubah menjadi sesuatu yang dapat diperluas yang ingin dimasukkan perusahaan Anda ke domain publik dan dijual. Persyaratan bisnis telah berubah. Haruskah programmer disalahkan karena tidak melihat ini?
Standarisasi
Kode hanyalah alat, tetapi penciptaannya adalah kreativitas murni. Masalah apa pun dapat diselesaikan dengan jumlah tak terbatas dari cara yang paling beragam. Beberapa dari mereka lebih produktif daripada yang lain - contoh penilaian obyektif. Beberapa dari mereka lebih mudah dibaca daripada yang lain - contoh penilaian subyektif. Bahkan jika Anda meyakinkan seluruh kantor bahwa beberapa kode tidak dapat dibaca, masih ada setidaknya satu penulis yang tidak setuju dengan Anda. Standarisasi kode ini bertujuan untuk mengubah kreativitas murni ke dalam serangkaian tindakan paling rutin sehingga lebih mudah bagi programmer lain untuk memahami kode Anda. Itu sebenarnya, sehingga Anda dapat digantikan oleh spesialis lain, lebih patuh dan lebih murah. Dan setelah beberapa dekade, itu sepenuhnya kecerdasan buatan. Perlu diingat bahwa jika beberapa standar bertentangan dengan akal sehat, mungkin masuk akal untuk melanggarnya di beberapa tempat, atau bahkan sepenuhnya meninggalkannya atau menggantinya dengan yang lain, yang lebih cocok.
Standar dewasa menjual diri mereka dari posisi "ketika memilih standar, perhatikan popularitas komunitas." Saya bertanya-tanya bagaimana mereka menjual diri mereka ketika mereka baru saja keluar. Gagasan utamanya adalah bahwa popularitas suatu standar tertentu bukanlah faktor yang ingin Anda pertimbangkan pertama-tama ketika memilih. Popularitas dan komunitas sangat lembam dan selama beberapa dekade dapat menolak standar baru yang lebih baik. Apalagi jika mereka revolusioner.
Perhatian khusus diberikan pada standar yang telah benar-benar memantapkan diri mereka dalam budaya hanya karena standar tersebut muncul lebih awal dari standar serupa lainnya. Contoh kanonik adalah perang suci antara tata letak QUERTY dan Dvorak. Yang kedua, tentu saja, lebih baik, tetapi yang pertama memiliki pukulan (tetap lebih populer) hanya karena massa pengguna yang kritis yang tidak ingin berlatih kembali dengan yang baru.
Contoh serupa ditemukan sepanjang dan dalam budaya pemrograman. Standar PSR singkatan dari 4 spasi daripada tab, mengabaikan fakta yang jelas: lingkungan pengembangan sebagian besar programmer PHP telah berubah dari editor konsol ke IDE penuh, di mana menabrak lebih nyaman dalam banyak cara: lebih mudah untuk menghapusnya dengan menekan Backspace sekali, dan Anda dapat mengonfigurasi panjang masing-masing Tab sesuai selera.
Saat menerapkan standar ini atau itu, ajukan pertanyaan: kepada siapa Anda membuatnya lebih nyaman? Siapa yang lebih tidak nyaman? Siapa yang akan mendapat manfaat dari aturan "nama nama-nama metode lowerKamelKeysom"? Jelas hanya untuk mereka yang terbiasa memanggil mereka seperti itu. Semua orang akan menjadi tidak nyaman, mereka harus beradaptasi, dan kehilangan waktu dan sumber daya ini benar-benar dari awal, mengingat kenyataan itu
a) sekarang kami memiliki IDE ajaib yang menyoroti berbagai elemen kode dalam warna yang berbeda,
b) programmer memiliki kemampuan untuk melompat dari proyek ke proyek, standar pengkodean yang dapat bervariasi.
Secara pribadi, ketika mengembangkan proyek saya, saya menggunakan:
- CamelCase untuk penamaan kelas dan metode
- $ CamelCase untuk variabel penamaan yang berisi instance dari objek
- $ snake_case untuk variabel penamaan yang berisi tipe sederhana
Saya tidak punya masalah membedakan nama kelas dari nama metode karena yang pertama adalah kata benda dan yang kedua adalah kata kerja. Selain itu, lampu latar membantu. Tapi ini selera pribadi saya, saya tidak memaksakannya pada siapa pun. Ini adalah prisma persepsi pribadi, itu adalah individu untuk setiap kepala individu. Seseorang “beruntung” untuk segera terjun ke standar populer, seseorang “tidak beruntung” memulai karir mereka dengan yang alternatif, dan seseorang umumnya mengembangkan sendiri. Saya mengarahkan Anda pada fakta bahwa alih-alih melatih kembali orang lain, mungkin masuk akal untuk melatih diri untuk memahami kode dalam standar apa pun. Atau bahkan di luar standar.
Tentu saja, para penganut standardisasi di tempat ini akan marah dan melemparkan banyak alasan kepada saya. Artikel ini bukan untuk mereka, saya menulisnya untuk mereka yang tertarik untuk memahami esensi hal-hal, mencoba membayangkan apa yang sebenarnya ada dalam pikiran penulis dan tujuan apa yang dia kejar.
Kemampuan untuk memahami kode orang lain
Pemicu yang menyebabkan impuls muntah di sebagian besar programer (contoh penilaian subyektif). Tampaknya tidak pernah aneh bagi Anda bahwa sering kali lebih mudah bagi kami untuk menulis ulang semua kode dari awal daripada memahami orang lain? Dalam industri lain, kita bertindak berbeda: pertama kita belajar membaca, lalu menulis; penggunaan pertama (peralatan listrik, bangunan), kemudian desain mereka. Sepertinya bagi saya intinya adalah dalam pendidikan kita (khususnya di bidang pemrograman). Kami diajarkan untuk mencapai tujuan dengan cara yang paling langsung dan cepat, menggunakan pengetahuan yang baru diperoleh. Sebagai hasilnya, kami menggabungkan mereka (pengetahuan) persis sampai "itu" bekerja, menguji sedikit dan mengirimkannya ke guru untuk moderasi. Menurut pendapat saya, akan menyenangkan untuk menambahkan langkah tambahan untuk proses ini, di mana kami membandingkan kode kami dengan kode master, yang meskipun tidak ideal dan satu-satunya yang benar, tetapi memberikan solusi alternatif, seringkali lebih optimal dan dapat dibaca.
Adapun pemicunya, untuk mematikannya, cukup dengan menempatkan diri Anda secara mental di tempat pelanggan, yang telah menyaksikan para programmer yang akan datang sepanjang hidupnya, mengklaim bahwa pekerjaan para pendahulu mereka adalah kotoran dan Anda perlu menulis ulang semuanya untuk menjadikannya baik. Pelanggan tidak memiliki kompetensi untuk mengetahui apakah Anda mengatakan yang sebenarnya atau hanya malas untuk memahami kode orang lain. Untuk mendapatkan kepercayaannya dalam masalah seperti itu, Anda harus mempelajari kode orang lain dan menemukan beberapa lubang keamanan raksasa dan menunjukkannya kepada pelanggan. Tetapi bahkan dalam situasi ini, dari sudut pandang bisnis, mungkin lebih menguntungkan untuk "mengeras". Terutama jika itu adalah outsourcing dengan tenggat waktu dan uang tertentu. Haruskah programmer disalahkan untuk ini?
Kesimpulan
Wha, shcha menulis dengan huruf I. Alih-alih sarapan, minum kopi dan mentega melalui blender.
Lihat lebih dalam, pikirkan lebih luas, cari alternatif. Jangan pernah berhenti berkembang.