Hari ini kami menyampaikan kepada Anda
terjemahan lanjutan
dari materi tentang bahaya yang disebut pemrograman "fungsional".
Sukses adalah jalan, bukan tujuan.
Mari kita akui bahwa kita programmer dibayar untuk waktu kita. Sama seperti pembangun yang telah menggali lubang di dekat rumah saya selama dua tahun sekarang (ngomong-ngomong, mereka membangun dinding, yaitu, jalan).
Mari kita cari formula produktivitas programmer. Setiap orang yang bekerja di perusahaan besar mana pun tahu rumus sederhana untuk sukses:
= __ x __
▍Jumlah bug diperbaiki
Otak manusia sangat kurang beradaptasi untuk bekerja dengan apa yang disebut "keadaan aplikasi" dalam pemrograman. Kita dapat, pada suatu saat, menyimpan hanya sekitar lima elemen dalam ingatan jangka pendek kita. "Status" dalam pemrograman biasanya data disimpan dalam memori. Dalam OOP, ini adalah, misalnya, bidang objek atau variabel. Bekerja dengan keadaan yang bisa berubah sangat mirip dengan juggling. Beberapa teman saya bisa bermain sulap dengan tiga bola, belum lagi lima.
OOP memanfaatkan kelemahan ini dengan baik. Dalam OOP, hampir semua hal dapat bermutasi. Saya berterima kasih kepada kekuatan yang lebih tinggi atas fakta bahwa pencipta OOP telah mempertimbangkan dengan serius apa yang menjadi tergantung pada produktivitas pengembang! Dalam OOP, semua status yang dapat diubah juga tersedia untuk digunakan di berbagai tempat program dengan referensi. Ini berarti bahwa pemrogram tidak hanya perlu memikirkan keadaan objek yang dapat berubah yang saat ini bekerja dengannya. Dia perlu mengingat tentang keadaan yang bisa berubah dari 10-50 objek lain yang dengannya objek ini berinteraksi! Itu seperti menyulap 50 bola sekaligus. Keadaan ini juga memiliki nilai tambah. Ini adalah latihan yang bagus untuk otak.
Kesalahan? Ya - selama proses juggling, beberapa bola jatuh. Programmer mungkin kehilangan beberapa hal kecil mengenai interaksi 50 objek. Tapi siapa, jujur saja, yang peduli? Kesalahan produksi harus dilaporkan oleh pengguna. Ini adalah seberapa besar, organisasi yang serius bekerja. Kemudian pesan kesalahan masuk ke jurnal JIRA (ini, seperti yang Anda pahami, adalah produk perangkat lunak tingkat perusahaan yang serius). Bahkan beberapa tahun tidak akan berlalu, dan kesalahan akan diperbaiki. Masalahnya terpecahkan!
Tuhan, betapa aku mencintai aplikasi mobile banking saya. Ini sangat fungsional, bank menghargai bisnis saya dan mengurus data pribadi saya. Kesalahan hanyalah kemungkinan (saya diberitahu)!
Programmer yang disebut "fungsional" tidak mengerti mengapa mengisolasi negara dan membuatnya tidak berubah. Ini memerlukan konsekuensi menyedihkan dari pengurangan kompleksitas program dan, akibatnya, mengurangi jumlah kesalahan. Jika ada lebih sedikit kesalahan dalam basis kode, ini berarti bahwa programmer harus menyelesaikan lebih sedikit masalah. Perusahaan pengembang tidak akan dapat membebankan biaya kepada pelanggan untuk memperbaiki bug. Dengan menggunakan metode fungsional, programmer yang bekerja di perusahaan besar dan serius akan terlihat buruk di mata manajer mereka, dan pada saat yang sama, mereka akan sangat membahayakan peluang karier mereka.
▍Jumlah baris kode
Programmer membutuhkan kesempatan untuk menunjukkan kepada manajer hasil pekerjaannya, hasil bergerak ke arah tujuan. Apa cara paling efektif untuk mengekspresikan hasil seorang programmer? Ini, tentu saja, adalah jumlah baris kode yang ditulisnya! Jika kita semua beralih ke pemrograman fungsional, maka kita akan sangat mengecewakan para manajer dan menimbulkan kecurigaan yang serius tentang efektivitas pekerjaan kita. Pendekatan "deklaratif" mengarah pada penulisan kode yang lebih ringkas. Penggunaannya sangat mengurangi jumlah baris kode dalam program. Saya percaya bahwa benar-benar tidak dapat diterima bahwa dengan pendekatan deklaratif, untuk mencapai tujuan yang sama, diperlukan kode hingga 3-5 kali lebih sedikit daripada saat menggunakan OOP.
Dengan kata lain, dalam transisi ke pemrograman fungsional, produktivitas kita akan benar-benar runtuh di mata manajer perusahaan yang serius. Ini, pada gilirannya, akan menempatkan pekerjaan kita dalam risiko. Oleh karena itu, adalah kepentingan terbaik kami untuk menjauh dari pemrograman "fungsional".
Saran yang sama berlaku untuk kontraktor yang menagih pelanggan berdasarkan jam kerja. Berikut adalah formula sukses sederhana untuk mereka:
__ = ____ = $$$$$$
Formula sukses ini, tentu saja, juga langsung berlaku untuk kontraktor serius yang dibayar untuk jumlah baris kode:
if (1 == '1') { doStuff(); } else { // }
▍Kode spaghetti adalah roti dan mentega kami
Tidak seperti pemrograman fungsional, OOP menawarkan kita pendekatan yang konsisten untuk menulis kode spaghetti. Ini sangat bermanfaat untuk produktivitas pengembang. Menulis kode spaghetti berarti menghabiskan lebih banyak waktu untuk menulis kode. Ini adalah manfaat langsung bagi pemrogram berorientasi objek yang serius. Spaghetti tidak hanya sangat lezat. Ini juga merupakan konsep yang sangat penting bagi mereka yang menulis dengan gaya OOP.
OOP adalah hadiah nyata bagi kontraktor dan karyawan perusahaan yang serius.
Departemen Pencegahan Kesalahan
Anda tidak perlu takut menggunakan OOP. Saya ulangi - kesalahan yang mengganggu adalah hal yang sepele yang tidak perlu Anda khawatirkan. Dalam organisasi yang serius, ada departemen untuk pencegahan kesalahan (ini juga disebut departemen dukungan pengguna), tugas utamanya adalah melindungi pengembang perusahaan dari pelanggan yang marah. Pada akhirnya - jika klien tidak dapat menggunakan aplikasi dengan benar - ini hanya kesalahannya.
Pengembang tidak boleh diganggu oleh hal-hal yang tidak relevan dengan bisnis mereka, seperti laporan bug. Ini membantu memastikan keadaan di mana sumber daya perusahaan tidak terbuang sia-sia. Sebagai hasilnya, pengembang mendapatkan kesempatan untuk dengan tenang mengimplementasikan fitur aplikasi baru dan mengarahkan semua perhatian mereka untuk menciptakan abstraksi berorientasi objek dari kelas enterprise dan untuk menerapkan pola desain yang kompleks.
▍ Proses pelaporan kesalahan
Proses yang dirancang dengan cermat dan terencana ini biasanya ada untuk melindungi sumber daya manusia organisasi. Segera setelah pengguna menemukan kesalahan, ia biasanya mencari nomor telepon departemen dukungan pelanggan. Kemudian pengguna disajikan dengan menu telepon interaktif yang besar, yang mencakup berbagai opsi. Biasanya, dibutuhkan sekitar 2-5 menit untuk mendengarkan informasi tentang menu dan memilih opsi yang diinginkan. Langkah ini memungkinkan Anda untuk menyaring pelanggan yang paling tidak gigih.
Kemudian klien biasanya diberitahu bahwa perusahaan dihadapkan dengan "volume panggilan yang luar biasa besar" dan bahwa "waktu tunggu rata-rata adalah 56 menit." Pada saat yang sama, mereka biasanya meminta maaf kepada klien atas ketidaknyamanan ini dan berbicara tentang bagaimana mereka menghargai dia dan bisnisnya. Pada langkah ini, sebagian besar pelanggan memutuskan untuk tidak melaporkan kesalahan. Untuk menghibur mereka yang masih menunggu, mereka biasanya memainkan musik yang inspiratif. Selain itu, mereka ditawarkan untuk mencoba aplikasi baru yang luar biasa. Ini adalah aplikasi yang bermasalah dengan klien.
Setelah masa tunggu 56 menit berakhir, panggilan dialihkan ke pusat panggilan yang terletak di suatu tempat di Amerika Utara. Karyawan pusat panggilan semacam itu biasanya menjalani pelatihan khusus yang memungkinkan mereka berbicara dengan aksen India atau Bulgaria yang kuat. Karyawan call center menjawab bahwa aplikasi yang dimaksud berada di luar lingkup tanggung jawabnya, tetapi ia dengan senang hati akan mengalihkan klien ke departemen lain.
Setelah masa tunggu yang lain, yang sekarang berlangsung 42 menit, karyawan call center lain dengan nada bahagia di suaranya memberi tahu klien bahwa kesalahan yang ia temui sebenarnya adalah fitur aplikasi. Setelah itu, klien disarankan untuk merujuk ke bagian bantuan aplikasi. Jika klien terus bersikeras bahwa ia berurusan dengan kesalahan, maka mereka bahkan dapat membuat permintaan untuk dukungan. Klien bahkan mungkin mendapatkan jawaban - sesuatu dalam semangat "Playback gagal."
Saya harap Anda sekarang yakin bahwa kesalahan bukanlah yang harus diperhatikan oleh programmer. Organisasi biasanya mengambil langkah serius untuk melindungi pengembang dari pemborosan waktu yang tidak perlu.
Hindari "Kesalahan Pemula" di Wawancara
Jika Anda secara aktif mencari pekerjaan - usahakan untuk menghapus semua omong kosong "fungsional" dari resume Anda. Kalau tidak, tidak ada yang akan menganggapmu serius. Tidak seorang pun di dunia korporat yang nyata menghabiskan waktu mempelajari mainan anak-anak seperti "komposisi fungsi", "kemurnian", "monad" atau "kekebalan". Anda tidak ingin menjadi seperti orang luar. Jika Anda mulai membicarakan hal-hal seperti itu, itu akan membuat orang yang mewawancarai Anda merasa tidak nyaman. Dan jika seorang perwakilan dari perusahaan pemberi kerja potensial merasa bahwa Anda lebih pintar darinya - peluang Anda untuk mendapatkan pekerjaan di perusahaan ini akan cenderung nol.
Spesialis SDM, merekrut tenaga teknis di perusahaan besar, di samping itu, menjalani pelatihan intensif wajib. Ini memungkinkan mereka untuk dengan percaya diri membedakan antara teknologi serius - seperti Java dan JavaScript.
Pastikan resume Anda berisi referensi tentang apa yang menunjukkan pengetahuan luas Anda tentang teknologi yang dihargai oleh perusahaan besar. Sertakan kata-kata dan frasa seperti "kelas," "warisan," "pola desain," "injeksi ketergantungan," "SOLID," "pabrik abstrak," dan "singleton."
Ketika Anda diminta untuk menyelesaikan masalah FizzBuzz, yang sering ditawarkan saat wawancara, di selembar kertas, Anda dengan baik mengingat rekomendasi berikut, yaitu Anda harus siap terlebih dahulu untuk menyelesaikan masalah ini. Ini adalah kesempatan Anda untuk memamerkan pengetahuan mendalam Anda di bidang pemrograman yang dihargai di dunia korporat. Anda harus mulai dengan rancangan solusi komprehensif yang melibatkan penggunaan pola desain dan teknik OOP lainnya. Titik awal yang baik untuk menyelesaikan masalah ini adalah
FizzBuzzEnterpriseEdition . Banyak pelamar membuat kesalahan yang sama yang tipikal untuk pemula. Kesalahan ini terletak pada kenyataan bahwa mereka bergantung pada teknologi terbatas seperti fungsi. Setelah ini, tidak ada yang terkejut bahwa setelah wawancara, tidak ada yang menelepon dan menulis surat kepada mereka.
Pemrograman fungsional mungkin tidak dapat digunakan untuk mengembangkan solusi perangkat lunak yang serius.
Setelah mempertimbangkan argumen di atas, serius dan akurat, siapa pun sekarang dapat dengan jelas melihat bahwa tidak ada hal baik yang dapat diharapkan dari penggunaan yang disebut pemrograman "fungsional". Sangat jelas bahwa pendekatan pemrograman ini harus dihindari dengan cara apa pun.
Banyak kebisingan telah muncul di sekitar pemrograman "fungsional" selama beberapa tahun terakhir. Tetapi hal baiknya adalah bahwa hobi jangka pendek komunitas pemrogram ini sudah sekarat! Pelaku pasar besar seperti Facebook dan Microsoft telah lama menyadari keterbatasan pemrograman fungsional dan keunggulan absolut pendekatan berorientasi objek untuk mengatur kode di atasnya. Mereka mengarahkan upaya mereka ke generasi baru bahasa berorientasi objek, khususnya - ke
ReasonML dan
BosqueOOP . Bahasa-bahasa seperti itu membawa mutabilitas keadaan aplikasi ke tingkat yang sama sekali baru, dan, untungnya, mereka tidak mendukung omong kosong fungsional yang tidak berguna seperti struktur data yang tidak dapat diubah.
Ringkasan: hadiah para dewa
Di sini Anda mungkin memiliki pertanyaan tentang alternatif apa yang disebut pemrograman "fungsional". Ini, tentu saja, adalah pemrograman berorientasi objek. OOP dikirimkan kepada kami oleh dewa pemrograman sejati. OOP adalah kekuatan yang harus diperhitungkan. Ini adalah Alat Bermodal yang membuat programmer produktif. Berkat OOP, Anda dan tim Anda akan selalu sibuk dengan bisnis (dan Anda tidak akan kehilangan pekerjaan Anda).
Inilah artikel saya di mana saya berbicara secara rinci tentang OOP.
Semoga kekuatan (berorientasi objek) menyertai Anda. Dan kodemu. Saya menyatu dengan kekuatan. Damai untuk semua.
Seperti yang mungkin sudah Anda duga, ini bahan satir. Jika Anda seorang programmer pemula, jangan mengambil semua ini dalam hati.
Pemrograman fungsional sangat bagus. Luangkan waktu menjelajahi paradigma pemrograman ini dan Anda akan mendapati diri Anda di depan banyak rekan tim Anda.
Saya harap Anda tertarik membaca ini seperti yang saya tulis.
Pembaca yang budiman! Apa yang paling tidak Anda sukai dari OOP?
