Ketika saya dan teman saya berusia sekolah dan bercita-cita untuk menjadi pengembang perangkat lunak, kami melamun merancang beberapa hal keren bersama - seperti game atau aplikasi mega-berguna.
Saya memilih untuk belajar C ++ dan C #, dia memilih JavaScript. Kami menyelesaikan sekolah, lulus dari universitas, melayani di ketentaraan, dan memulai pekerjaan. Kami memiliki waktu yang cukup sibuk dalam rekayasa perangkat lunak industri, dengan banyak pekerjaan dan posisi yang berbeda, dan setelah semuanya mulai dikenakan pada kami, kami mengingat di mana semuanya dimulai.
Setelah akhirnya berkumpul sebagai pengembang yang matang, kami memutuskan untuk mengerjakan proyek kami sendiri - video game 2D. Karena domain teman saya adalah front-end dan saya adalah pengembang full-stack, pilihan langsung kami untuk platform pengembangan adalah browser Internet. Karena saya hanya terbiasa bekerja dengan TypeScript ketika mendesain front-end, kami pikir, ok, tidak masalah, lagipula, TS hanyalah JavaScript pada skala. Mari kita gunakan dan semuanya akan berjalan lancar. Kalau saja aku tahu betapa salahnya aku! Ketika kami mulai mendiskusikan proyek tersebut, kami mengalami jurang kesalahpahaman yang luas di antara kami.
Inilah visi permainan saya. Saya seperti, ok, kami memiliki jenis permainan, alat, item, peta, lokasi. Saya memiliki pemahaman dasar tentang bagaimana mereka bekerja bersama, jadi saya menggambarkannya, menyusun proyek - dan itu berhasil. Lagi pula, kompiler telah memverifikasi kode saya, dan saya melakukannya dengan benar. Selanjutnya, saya mulai menulis kode yang menggunakan tipe-tipe itu. Mereka membuat hidup saya lebih mudah. IDE saya memberi saya tooltips dan memeriksa kesalahan. Jika suatu proyek dapat dikompilasi, itu mungkin berhasil. Saya menghabiskan beberapa upaya pada deskripsi jenis dan menghasilkan hasil. Singkatnya, pendekatan saya.
Teman saya memiliki ide yang berlawanan - untuk langsung beralih ke penulisan kode tanpa meluangkan waktu untuk menjelaskan jenisnya. Dia tidak siap untuk mendefinisikan masalah sebagai keluarga tipe. Dia tidak tertarik menggunakannya sebagai fondasi, karena dia tidak melihat masalah sebagai satu set kelas, jenis, catatan apa pun dari jenis itu. Saya pikir itu tidak masuk akal. Kami berdua memiliki satu poin, hanya saja poin kami saling eksklusif.
Serius, kami berbicara selama berjam-jam, namun masing-masing mengatakan masalahnya sendiri, seolah-olah kami berbicara bahasa yang berbeda. Pikiran Anda, saya tidak bisa menyalahkan kami terjebak dalam cara lama kami. Hanya setahun yang lalu, saya bermigrasi tanpa rasa sakit dari dunia pemrograman berorientasi objek ke dunia pemrograman fungsional dan kembali. Selain itu, saya menghabiskan cukup banyak waktu untuk belajar JS, dan dia - pada belajar sejumlah bahasa yang diketik secara statis.
Namun, bagi pengembang mana pun, teknologi yang mereka gunakan untuk pekerjaan nyata pertama mereka sering kali mendefinisikan mereka sejauh dua orang dewasa yang berpengalaman tidak memiliki kesabaran untuk mendengarkan satu sama lain. Selama bertahun-tahun dalam rekayasa perangkat lunak, visi kami dibentuk sedemikian rupa sehingga pendekatan kami untuk pemecahan masalah tidak cocok bersama.
Pada akhirnya kami meninggalkan ide bekerja sebagai sebuah tim. Tanggapan pertama Anda mungkin bahwa masalahnya ada di kepribadian kita. Anda mungkin benar, tetapi saya juga melihat ini terjadi pada orang lain di industri ini.
Perbedaan mendasar, tidak dapat didamaikan antara pengetikan statis dan dinamis
Kode saya memberikan solusi untuk masalah cara bekerja dengannya, sedangkan kode pendukung pengetikan dinamis yang berpengalaman memecahkan masalah cara kerjanya. Kedua pola pikir itu sah dan didukung oleh perangkat yang ada, tetapi hanya satu yang dapat memiliki prioritas tertinggi setiap saat.
Pengetikan statis baik untuk proyek skala besar yang melibatkan ratusan pengembang yang mengerjakannya selama bertahun-tahun, sedangkan pengetikan dinamis baik untuk tim yang lebih kecil dan proyek yang sering memerlukan kode hanya menulis. Pengetikan dinamis memungkinkan Anda menghemat waktu dan upaya di awal pengembangan, sedangkan pengetikan statis memberi Anda dorongan di akhir pengembangan.
Gagasan mengutamakan tipe sangat mempengaruhi pemikiran saya sebagai pengembang. Setelah memilih C # di awal karir saya, saya mengetik statis statis ke dalam pola pikir saya, dan saya membayar harga ketidakfleksibelan ini sekarang. Begitu saya melihat sebuah tugas, saya mencoba membayangkan solusinya sebagai serangkaian tipe dan aturan hubungan mereka. Ketika saya sedang mengembangkan sebuah modul, langkah pertama saya adalah menentukan tipe yang dioperasikan dan digunakannya untuk berinteraksi dengan lingkungannya. Saya hanya tidak ingat bagaimana saya dulu memecahkan masalah sebelum itu.
Seluruh proses belajar ke program di Jawa adalah tentang belajar mendesain dan menggunakan tipe. .NET CLR - runtime C # - dibangun pada tipe dan tipe. Pengetikan statis merupakan inti dari paradigma pemrograman berorientasi objek (halo, kelas JS, saya memutuskan untuk memberi Anda istirahat). Implementasi kanonik dari sebagian besar pola OOP jenuh dengan kata kunci Interface, yang tidak masuk akal dalam bahasa yang diketik secara dinamis.
Pola desain itu sendiri adalah konsep lintas-bahasa, tetapi adakah yang bisa memberi tahu saya mengapa saya membutuhkan pola Negara dalam bahasa yang diketik secara dinamis? Bagaimana dengan Builder? Pola-pola ini tidak ada hubungannya dengan pengembangan, mereka terutama tentang jenis. Jenis dan OOP memiliki tautan ketat.
Anda tidak dapat membangun logika bisnis Anda pada tipe dan belum tahu apa-apa tentang mereka ketika Anda mulai menulis kode. Itu sebabnya kami memiliki pengembang front-end yang mempersenjatai kode mereka dengan sejumlah besar unit test yang secara khusus memeriksa basis kode untuk segala jenis kesalahan.
Kita semua tahu bahwa perlindungan berdasarkan cakupan kode adalah ilusi. Tes ditulis secara manual, dan menurut definisi kurang dapat diandalkan dibandingkan sistem bawaan jenis verifikasi yang tersedia dalam bahasa.
Itu tidak berarti bahwa bahasa yang diketik secara dinamis tidak masuk akal (walaupun saya akui bahwa saya pikir mereka tidak mengerti). Ini berarti bahwa saat menggunakannya, Anda harus mundur dari OOP sebagai paradigma yang mendominasi. Semua kesatuan data ini dan operasi yang digerakkan oleh data adalah untuk orang yang memiliki pengetikan statis.
Pengembang yang saya temui tidak berpikir bahwa pengetikan statis mempengaruhi cara pengkodean sampai batas tertentu, jadi mereka hanya menulis kode mereka seolah-olah mereka menggunakan bahasa yang dinamis, hanya saja mereka menambahkan pemeriksaan jenis. Saya percaya ini salah secara inheren. Ini sangat jelas dalam kasus front-end modern.
Saya tahu, saya tahu, ada tabu untuk mengkritik pengembang front-end. Teman saya dan saya pernah mengumpulkan bot AI yang mengacaukan pengguna Twitter, dan kami berhasil menjebak Brendan Eich. Serius, pembuat JavaScript memiliki bolak-balik dengan jaringan saraf kami di komentar.
Untuk beberapa alasan, orang-orang ini tidak siap untuk hidup di dunia di mana visi mereka memiliki kekurangan yang nyata. Itu sebabnya saya mengkritik hanya mereka yang mengutak-atik proyek saya yang diketik pasti untuk mengerjakannya kembali dengan santai, “Apa pun caranya”.
Kami akan terus berdiam di dunia kecil kami, tetapi TypeScript menyatukan kami
Ambil saya sebagai contoh: karena batasan jenis, kode saya tidak mungkin digunakan secara tidak benar. Ketika saya mengerjakan proyek, saya mengandalkan orang lain untuk menggunakan tipe juga. Kemudian kode saya akan berfungsi seperti yang dirancang. Jadi saya sengaja tidak menutupi semua kasus di mana kode ini dapat digunakan secara tidak benar (karena mengetik membuatnya tidak mungkin). Tetapi kemudian seorang pengembang JS bergabung dengan proyek saya, mengambil tipeku, membungkusnya dalam Apa saja dan mulai menggunakannya secara salah, yang menghasilkan bug yang sulit untuk ditiru.
Pengembang JavaScript yakin bahwa TypeScript adalah JS tua yang sama, tetapi dengan opsi untuk menambahkan pemeriksaan tipe statis jika mereka membutuhkannya. Ini salah. TypeScript seratus kali lebih kuat, namun mereka hanya tertarik pada sebagian kecil dari potensinya.
Argumen pembunuh mereka adalah bahwa TypeScript hanyalah superset dari JS. Dalam praktiknya, seseorang tidak dapat mengabaikan fakta bahwa TypeScript adalah bahasa yang independen, bahkan jika seseorang adalah raja front-end yang aneh. Karena itu memerlukan pendekatan yang berbeda - yang statis, tidak dinamis, verifikasi.
Manfaat utama dari pengetikan statis adalah memberi Anda jaminan. Jika Anda menggunakannya dalam satu modul dan memilih untuk tidak menggunakannya di modul lain, maka Anda hanya membuang waktu dan energi Anda untuk mendeskripsikan dan mendesain tipe-tipe itu, tanpa mendapatkan jaminan apa pun.
Banyak yang berpikir bahwa TypeScript adalah kompromi dari sistem tipe antara JS dan Java. Yah, itu bukan kompromi dalam bentuk apa pun, itu punya sistem tipe khusus sendiri.
Yang terburuk, hari ini satu dari dua posisi front-end membutuhkan kecakapan dalam TypeScript. Ini memacu pengembang JS untuk melirik fitur-fitur TypeScript dan segera melompat untuk menulis kode di dalamnya, menghasilkan proliferasi praktik berbahaya. Situasi terjadi ketika mereka tidak benar-benar membutuhkan pemeriksaan tipe statis, tapi itu agak dipaksakan pada mereka, jadi mereka mengacaukannya. Kita akhirnya harus mengakui bahwa pendekatan pemrograman dengan pengetikan statis vs dinamis bertentangan satu sama lain dan tidak dapat digabungkan.
Saya melihat JavaScript sebagai alat yang hebat untuk menulis kode peretasan cepat yang memberikan solusi tanpa menyelesaikan abstraksi yang tidak perlu. Contoh paling keterlaluan di sini adalah pola Pabrik Es. Anda bisa memberi makan instance Anda, dan itu akan membungkusnya dalam immutability runtime. Jika saya memproses objek saya melalui pabrik tersebut, ia akan mengembalikan yang setara, tetapi jika saya mencoba mengubah salah satu propertinya, ia akan mengeluarkan pengecualian. WAT?!?
Pola ini muncul karena pengembang front-end mendengar di suatu tempat tentang imutabilitas keren, jadi mereka memutuskan untuk menyeret omong kosong ini ke dalam bahasa mereka, yang membutuhkannya seperti lubang di kepala. Di TypeScript, saya bisa mendesain pabrik yang serupa, tetapi dengan batasan waktu kompilasi pada mutasi dan tanpa pengecualian.
Di sisi lain, saya hampir tidak membutuhkan ini karena ada pemrograman fungsional murni. Ambil contoh F #, Haskell, OCaml, Clojure, ReasonML - mereka memiliki larangan mutabilitas yang out-of-the-box. Tetapi ada sesuatu yang memberi tahu saya bahwa jika pengembang front-end menggunakan bahasa fungsional, ia akan bersedia memutakhirkannya untuk membuat perilakunya mirip dengan JavaScript.
Itu karena memilih agama pengetikan Anda adalah tiket satu arah. Semua di antara solusi memberikan ilusi kompromi. Anda bergantung pada tipe atau tidak. Saya tidak tahu apakah hidup saya akan berbeda jika saya mulai belajar C # dan JavaScript secara paralel. Hari ini saya begitu putus asa mengidentifikasi diri saya dengan pola pikir saya sehingga saya tidak melihat keuntungan dari pengetikan dinamis (dan tidak ingin melihat mereka). Mereka ada, hanya di luar jangkauan penglihatan saya, jadi yang bisa saya lakukan hanyalah memejamkan mata kepada mereka seperti yang saya lakukan terhadap fenomena yang harus saya hadapi di dunia ini. Saya tahu saya salah, tetapi saya harus bekerja di sini dan sekarang, dan saya tidak punya anggaran untuk terus duduk di pagar.
Jadi saya tidak ingin mencari kompromi, sebagai gantinya saya akan meluruskannya. Jika Anda baru saja membuat langkah pertama dalam pengembangan, mulailah dengan mengetik statis!