Menjadi seorang programmer berarti mendaftar untuk pelatihan seumur hidup. Aliran baru - fitur baru, bahasa baru, alat baru, kerangka kerja baru - tidak pernah kering. Tetapi pada saat yang sama, pemrograman adalah bidang, yang secara mengejutkan setia pada tradisi, di mana semuanya didasarkan pada prinsip-prinsip yang diuji oleh waktu. Kami memperkenalkan pemrograman berorientasi objek, solusi perangkat keras modern, kecerdasan buatan, namun, terlepas dari semua perubahan ini, banyak aksioma yang dirumuskan pada generasi lalu ternyata benar hari ini.Saya mencurahkan artikel ini untuk beberapa pernyataan favorit saya tentang pemrograman. Satu-satunya kriteria yang saya gunakan untuk memilih adalah persyaratan bahwa kuotasi harus sama dengan setidaknya dua puluh tahun. Karena itu hanya teknologi usang yang dengan cepat menjadi tidak dapat digunakan, sementara perintah kuno dari pemrogram leluhur kita telah lama tetap relevan.1. Ketidakpastian
"Semua masalah pemrograman diselesaikan dengan menciptakan tingkat tipuan tambahan" - David Willer
Berikut adalah kutipan dari buku Teori dan Aplikasi Ilmu Komputer, yang semua orang suka mengulangi dan sedikit orang yang suka menjelaskan. Namun demikian, ini adalah salah satu kebenaran pemrograman favorit saya - ini dengan tepat mengungkapkan esensi pemrograman.Cara termudah untuk memahami tipuan adalah dengan membayangkan lapisan. Misalnya, bayangkan Anda memiliki proyek kecil di mana Anda perlu menempatkan komponen A di dalam komponen B:Kedua komponen terstandarisasi, sehingga membongkarnya menjadi komponen dan mengubah prinsip operasi tidak akan berfungsi. Anda bisa membuat komponen add-on yang terpisah ( PlugTwoProngVariant), tetapi ini adalah banyak pekerjaan dan duplikasi yang tidak perlu. Ada solusi yang lebih baik: tambahkan lapisan adaptor antara dua komponen ini yang berhasil berinteraksi dengan keduanya dan berfungsi sebagai perantara di antara mereka.Dengan semua ini, jika tipuan habis dengan penambahan lapisan tambahan antara komponen yang tidak akan berlabuh, tentu saja, akan berguna, tetapi sangat terbatas dalam aplikasi. Tetapi ide memecahkan masalah dengan mengubah lingkungan area masalah meresapi semua pemrograman dari atas ke bawah. Anda menjumpainya ketika Anda mencoba menyesuaikan model data baru dengan antarmuka lama. Anda menjumpainya ketika Anda mencoba untuk melampirkan aplikasi dengan kode lama ke backend dari layanan web baru. Anda menjumpainya ketika Anda perlu menambahkan beberapa fungsi tingkat tinggi baru seperti logging dan caching atau mengoordinasikan pekerjaan beberapa layanan tingkat tinggi seperti mengirim pesan dan melakukan transaksi.Di bagian paling atas piramida ini, Anda datang ke arah yang disempurnakan seperti pembelajaran mesin (jika Anda tidak dapat menulis perilaku Anda sendiri, tambahkan lapisan kode lain yang akan menyelesaikan masalah ini untuk Anda).Banyak yang akan memberi tahu Anda bahwa tujuan pemrograman adalah menulis instruksi yang jelas dalam bahasa yang bahkan komputer paling bodoh pun bisa mengerti . Tapi kutipan David Wheeler menawarkan pertanyaan yang lebih dalam. Menjadi seorang programmer yang baik berarti memanjat tangga tipuan, berjuang untuk solusi yang paling umum.Kutipan bonusIndirectness adalah alat yang ampuh, tetapi Anda harus membayar untuk kerumitan. Orang-orang jarang mengutip pernyataan itu segera setelah kutipan terkenal:”Ini biasanya menciptakan masalah baru.” - David Wheeler.
Berkat kebenaran ini, para programmer telah lama bertahan dalam bisnis.2. Tentang kesederhanaan
“Kesederhanaan adalah Prasyarat untuk Keandalan” - Edsger Dijkstra
Tidak ada kekurangan programmer yang bijaksana yang memperingatkan kita terhadap kode yang rumit tanpa kebutuhan mendesak. Tetapi hanya sedikit yang berhasil menunjukkan dengan jelas apa kompleksitasnya bagi kita sebagai pelopor dalam ilmu komputer, Edsger Dijkstra .Inilah intinya: Anda membuat pilihan yang mendukung kesederhanaan bukan hanya karena keinginan untuk membuat masa depan menyenangkan orang lain. Dan bukan karena Anda menganggap kemampuan untuk menggunakan kembali kode ini di masa depan. Dan bukan karena Anda ingin melihat inspeksi lebih akurat, dan bukan karena Anda ingin memfasilitasi proses membuat perubahan di masa depan (walaupun semua ini, tentu saja, merupakan keuntungan yang berharga). Anda melakukan ini karena kesederhanaan adalah prasyarat. Tanpa itu, Anda tidak akan pernah memiliki kode yang dapat diandalkan yang dapat Anda percayakan dengan menjalankan bisnis atau bekerja dengan data.Untuk mengambil posisi Dijkstra, kita perlu mengubah pemahaman kita tentang apa itu "kode yang baik". Ini belum tentu kode yang paling ringkas, atau tercepat, dan tentu saja bukan yang paling musykil. Kode yang baik adalah kode yang bisa Anda andalkan.Kutipan bonus untuk suatu topik.Salah satu cara terbaik untuk menjaga kode tetap sederhana adalah dengan mengingat bahwa lebih sedikit lebih banyak. Dijkstra menawarkan unit pengukuran baru yang akan selalu mengingatkan kita tentang ini:"Jika kita ingin menghitung jumlah baris kode, kita seharusnya tidak menganggapnya sebagai tertulis, tetapi sebagai yang dihabiskan" - Edsger Dijkstra
3. Tentang keterbacaan dan penulisan ulang
"Kode lebih sulit dibaca daripada menulis" - Joel Spolsky
Pada pandangan pertama, kutipan dari Joel Spolsky ini , legenda pemrograman dan salah satu pendiri Stack Overflow, tampaknya masuk akal, tetapi tampak dangkal. Ya, fragmen kode kaya informasi, terlalu padat, atau terlalu panjang. Dan ini tidak hanya berlaku untuk apa yang ditulis orang lain. Jika Anda melihat karya Anda sendiri tahun lalu, Anda perlu waktu untuk menciptakan kembali logika yang dulu Anda kenal dari dan ke.Tetapi pengamatan Spolsky terungkap dalam sesuatu yang menarik. Bahaya kode yang sulit dibaca bukan hanya konsekuensi yang paling jelas (sulit untuk diperbaiki dan diperbaiki). Ada satu lagi, bahaya besar: kode yang sulit dibaca tampaknya lebih buruk daripada yang sebenarnya. Bahkan, memahami kode orang lain mungkin tampak seperti tugas yang luar biasa sehingga Anda akan tergoda untuk melakukan apa yang Spolsky sebut sebagai kesalahan paling parah dari semua kesalahan - untuk menulis ulang semuanya lagi.Saya tidak mengatakan bahwa arsitektur sistem tidak pernah mendapat manfaat dari penulisan ulang seperti itu. Tentu saja, itu yang menang. Tetapi perbaikan semacam ini mahal. Dalam semua yang menyangkut pengujian dan perbaikan bug - dan ini adalah dua komponen pengembangan yang membutuhkan waktu lebih lama daripada menulis kode itu sendiri - Anda kembali ke posisi awal. Menulis ulang terlihat menggoda karena cocok dengan salah satu kesalahpahaman paling umum dari pengembang - kecenderungan untuk meremehkan biaya tenaga kerja dari hal-hal sederhana secara konseptual. Itu sebabnya 50% dari waktu dihabiskan untuk 5% terakhir dari proyek. Tugas-tugas dasar secara mengejutkan dapat menghabiskan waktu! Dan solusi untuk masalah yang sudah dipecahkan di masa lalu selalu terlihat sederhana.Nah, jika Anda menulis ulang semuanya dari awal untuk membawa kode dengan sempurna, seharusnya tidak, lalu apa alternatif yang lebih sukses? Jawab: libatkan setiap pengembang dalam proses refactoring terus menerus yang terfragmentasi . Jadi kode Anda terus ditingkatkan, karena rantai perubahan kecil - manfaat nyata dengan risiko minimal. Keterbacaan dapat ditingkatkan sepanjang jalan.Kutipan bonus untuk topikJika Anda masih meragukan pentingnya keterbacaan, Martin Fowler akan membantu untuk melihat masalah secara lebih luas:“Orang bodoh mana pun bisa menulis kode yang bisa dimengerti komputer. Pemrogram yang baik menulis kode yang dapat dimengerti orang. "- Martin Fowler
Dengan kata lain, tugas programmer adalah untuk mengeluarkan tidak hanya kode yang berfungsi, tetapi juga kode dengan logika internal.4. Tentang pengulangan
“Jangan ulangi. Setiap pengetahuan harus memiliki representasi yang unik, tidak ambigu, andal dalam sistem ”- Andy Hunt dan David Thomas
Setiap programmer yang menghargai diri sendiri tahu bahwa banyak masalah terletak pada pengulangan. Jika Anda menulis hal yang sama di beberapa tempat, Anda harus berusaha lebih keras untuk menguji dan memperbaiki bug. Lebih buruk lagi, Anda menciptakan kondisi untuk perbedaan; misalnya, satu potong kode selanjutnya dapat diperbarui, dan prosedur terkait lainnya tidak dapat dipatuhi. Program yang berbeda adalah program yang tidak dapat dipercaya, dan program yang tidak dapat dipercaya tidak dapat dianggap sebagai solusi yang layak.Bug ini bisa dihindari dengan metode ini.GetTeamUniform()Namun, pengulangan mendatangkan malapetaka tidak hanya dalam kode. Versi prinsip KERING terkenal ini (Jangan Ulangi Diri Sendiri) menafsirkan prinsip menghilangkan duplikat secara luas, mencakup tempat-tempat lain di mana pengulangan dapat dilakukan. Sekarang percakapan tidak lagi tentang duplikat dalam kode - kita juga berbicara tentang pengulangan di seluruh sistem. Dan sistem menyandikan pengetahuan dalam berbagai format. Secara khusus, ini adalah:- Operator
- Komentar Kode
- Dokumentasi untuk pengembang atau pelanggan
- Skema data (mis. Tabel basis data)
- Spesifikasi lainnya - rencana pengujian, proses dokumen organisasi, aturan perakitan
Semua grup ini mungkin tumpang tindih dalam konten. Dan ketika ini terjadi, ada risiko bahwa mereka akan mulai menyiarkan versi berbeda dari satu realitas. Katakanlah apa yang harus dilakukan jika dokumentasi menggambarkan satu model pekerjaan, dan aplikasi itu sendiri mengikuti yang berbeda? Apa yang dalam hal ini dianggap sebagai pemegang kebenaran? Tetapi bagaimana jika tabel dalam database tidak cocok dengan model data dari kode? Atau jika komentar kode menggambarkan operasi atau algoritma yang secara fundamental berbeda dari implementasi yang sebenarnya? Setiap sistem membutuhkan representasi tunggal dan andal yang menjadi sandaran segalanya.By the way, orang tidak boleh berpikir bahwa konflik antara pelamar kebenaran hanya terjadi di proyek-proyek kecil atau merupakan hasil dari kode kualitas yang buruk. Salah satu contoh terbaik yang terlihat jelas adalah pertempuran antara XHTML dan HTML5. Satu sisi mengklaim bahwa spesifikasi - ini adalah versi resmi yang benar, dan browser harus beradaptasi dengannya. Kamp lain keberatan bahwa itu adalah perilaku browser yang harus dianggap standar de facto - setelah semua, itulah bagaimana desainer membayangkan segalanya ketika mereka menulis halaman web. Pada akhirnya, versi kebenaran yang dipromosikan browser dimenangkan . Sejak itu, HTML5 adalah apa yang sebenarnya dilakukan browser, termasuk pintasan dan kesalahan yang valid.Kutipan bonus dalam topik.Kemungkinan bahwa kode dan komentar terhadapnya saling bertentangan telah menghasilkan diskusi yang hidup: apa lagi yang ada dari komentar - baik atau buruk? Pendukung pemrograman ekstrim memperlakukan mereka dengan rasa tidak percaya langsung.“Kode tidak pernah bohong, tetapi ini terjadi dengan komentar” - Ron Jeffries
5. Tentang masalah yang kompleks
"Dalam ilmu komputer, hanya ada dua masalah kompleks - membatalkan cache dan muncul dengan nama" - Phil Carleton
Secara tampilan, kutipan ini tampaknya hanya lelucon seorang programmer, lucu, tetapi tidak menonjol dari yang lain. Setiap orang dapat merasakan kontras antara sesuatu yang terdengar seperti tugas yang menakutkan (membatalkan cache) dan sesuatu yang terdengar seperti omong kosong nyata (menciptakan nama). Setiap programmer memiliki setidaknya sekali membunuh seluruh jam untuk masalah kecil yang sangat kecil - dua parameter, dimasukkan ke dalam urutan yang salah, variabel yang berada di suatu tempat dengan huruf kapital dan di suatu tempat tidak (terima kasih, JavaScript!) Sementara orang harus bekerja dengan komputer untuk mencapai tujuan mereka, pemrograman akan selalu menjadi campuran perencanaan sistem tingkat tinggi dan kesalahan ketik bodoh.Tetapi jika kita melihat lebih dekat pada kata-kata Phil Cardboard, kita akan menemukan lebih banyak ruang untuk berpikir. Sulit untuk mencari nama, bukan hanya karena sakit kepala kecil yang dimiliki seorang programmer, seluruh hidupnya menjadi jungkir balik. Intinya di sini adalah bahwa nama adalah salah satu aspek dari tugas utama programmer, desain program. Dengan kata lain, bagaimana kode yang jelas, rapi, dan konsisten umumnya ditulis?Ada banyak jenis nama buruk. Kita semua bertemu variabel yang dinamai berdasarkan tipe data ( myString, obj), singkatan ( pcmis. Katalog produk), beberapa detail implementasi yang tidak signifikan ( swappable_name, formUserInput), atau bahkan tanpa nama ( ret_value,tempArray) Sangat mudah untuk jatuh ke dalam perangkap dan beri nama variabel berdasarkan apa yang Anda lakukan sekarang, dan bukan dari isinya. Dan dengan nilai tipe data logis, masalahnya adalah: apa artinya progress- bahwa kemajuan telah dimulai, bahwa Anda perlu menampilkan informasi tentang kemajuan dalam antarmuka, atau sesuatu yang lain secara umum?Sumber: CommitStrip.comTransfer«results_tmp_2? ?.. , ? !» — «, … , results_tmp_2. »
Tetapi nama variabel hanyalah permulaan. Ketika Anda mulai membuat nama untuk kelas, muncul pertanyaan tentang bagaimana memecah kode menjadi bagian-bagian independen. Nama-nama anggota publik menentukan apa yang akan menjadi presentasi dari antarmuka di mana berbagai bagian aplikasi akan berinteraksi satu sama lain. Dengan menetapkan nama ke sepotong kode, Anda tidak hanya menggambarkan apa yang dapat dilakukan - Anda menetapkan apa yang akan dilakukan.Kutipan bonus dalam topik.« – , » —