TypeScript (dan JSDoc) lwn JavaScript

Pengenalan

Malah pada tahun 2024, 12 tahun selepas keluaran TypeScript dan 17 tahun selepas keluaran JSDoc, ramai orang masih tidak tahu mengapa menggunakan alat menaip statik dalam projek JavaScript mereka, walaupun selepas ia menjadi standard dalam JavaScript/ Komuniti NodeJs.

Dalam artikel ini, Saya akan menerangkan apa itu TypeScript dan JSDoc, dan sebab anda perlu menggunakan salah satu daripadanya dalam projek anda.

Apa mereka

TypeScript dan JSDoc ialah alatan untuk membenarkan JavaScript mempunyai penaipan statik. Lihat di bawah untuk contoh kedua-duanya.

Seperti yang anda lihat, TypeScript biasanya kurang bertutur berbanding JSDoc, tetapi sebaliknya, JSDoc tidak memerlukan langkah binaan, ia berfungsi secara langsung dengan ulasan dalam kod JavaScript.

TypeScript

convert-string-to-int.ts (fail TYPESCRIPT!)

JSDoc

convert-string-to-int.js (fail JAVASCRIPT!)

Kebaikan

Sebelum bercakap tentang kebaikan, saya mesti menyatakan bahawa tidak kira berapa banyak artikel yang anda baca atau seberapa bagus artikel ini, tidak ada cara untuk menerangkan betapa lebih baiknya pengalaman pembangun apabila anda bekerja dengan penaipan statik.

Tiada sesiapa boleh menerangkan dengan perkataan atau hujah betapa bagusnya bekerja dengan pangkalan kod yang mempunyai penaipan statik di atas yang tidak ditaip, malah bukan penyair yang terbaik.

Saya, seperti ramai yang lain, akan cuba menterjemah perasaan ini kepada fakta dan data, tetapi saya memastikan ia tidak mencukupi untuk menggambarkan perasaan yang tepat.

Elakkan kesilapan dalam pengeluaran

Ini, tanpa ragu-ragu, adalah kelebihan terbesar penaipan statik. Tidak ada perkataan yang mencukupi untuk menggambarkan betapa ia membantu, baik dari segi mengelakkan kerja semula dan menjimatkan wang.

Untuk menghantar barangan dengan pantas, terutamanya pembaikan terkini, kami akhirnya tidak mempunyai masa untuk menulis ujian unit atau menguji semua kemungkinan aliran penyelesaian. Jika anda bekerja dengan JavaScript tulen, tiada cara untuk memastikan bahawa:

• Semua pembolehubah yang anda gunakan wujud

• Semua pembolehubah yang anda gunakan diisytiharkan

• Anda menggunakan kaedah yang dibenarkan untuk jenis itu (cth: anda boleh menggunakan peta dalam pembolehubah nombor)

• Jika anda membandingkan pembolehubah setara (anda tidak sepatutnya membandingkan nombor dengan tatasusunan)

Jika anda tidak menguji kod anda dengan sangat baik, anda perlu mengusahakannya semula untuk membetulkan pepijat, menghabiskan masa yang berharga untuk sesuatu yang anda mungkin batuk sebelum ini. Pepijat yang disebabkan oleh perkara ini mungkin kedengaran bodoh, tetapi ia adalah yang paling banyak berlaku.

Menggunakan penaipan statik, anda memastikan pembangunan yang lebih selamat dan lebih pantas, mengurangkan jumlah pepijat dalam pengeluaran secara tidak masuk akal dan membenarkan pembangun menumpukan hanya pada perkara yang benar-benar memberikan nilai: Logik perniagaan.

Tiada ujian yang tidak perlu

Kebanyakan projek warisan dan projek berintensif awan (projek yang anda banyak sumber eksklusif untuk awan) mempunyai proses yang sukar untuk menjalankan kod secara setempat, atau lebih teruk lagi, anda perlu menggunakan kod tersebut untuk dapat dilaksanakan tanpa ejekan.

Proses menjalankan sesuatu secara tempatan boleh memakan masa dan meletihkan pembangun, dan dapat mengelakkannya menjimatkan banyak sumber (masa, wang, kesabaran, sumber awan, dll).

Dengan penaipan statik, kod ini sangat boleh diramal, dan anda boleh membangunkan segala-galanya mengetahui perkara yang berlaku dalam setiap bahagian kod, dan menjejaki pelaksanaan dengan sangat mudah, ini menjadikannya satu-satunya masa yang anda perlukan untuk menjalankan kod adalah selepas selesai pembangunan, untuk benar-benar menguji sama ada semuanya berfungsi seperti yang diharapkan.

Tiada dokumen lapuk

Kebanyakan masa (jika tidak semuanya) apabila kita cuba menulis dokumentasi tentang fungsi dan cuba menambah contoh input/output, ia menjadi lapuk dalam sekelip mata. Pembangun tidak pernah ingat untuk mengemas kini dokumen dan Scrum Masters tidak pernah mahu memperuntukkan masa yang cukup untuk melakukannya.

Dengan penaipan statik, kod tersebut ialah dokumen langsung. Ia tidak akan ketinggalan zaman, kerana apabila pembangun mengemas kini kod, mereka akan mengemas kini dokumen.

Elakkan masalah dengan modul CommonJs / ES

Selepas pelaksanaan modul ES dalam NodeJs, banyak perpustakaan mula berhijrah kepada cara penulisan kod baharu ini, jadi versi baharu mereka (lebih selamat, boleh dipercayai, berprestasi dan dengan lebih banyak ciri) tidak serasi dengan versi JavaScript yang lebih lama, yang membuatkan anda terjebak dengan versi lapuk yang tidak selamat.

Tebak apakah yang serasi dengan modul CommonJs dan ES tanpa perlu menukar apa-apa dalam kod anda (hanya beberapa baris dalam konfigurasi)? Tepat sekali, TypeScript (malangnya, saya rasa JSDoc tidak mempunyai kelebihan ini).

Autolengkap & elakkan salah tulis

Daripada perlu mengingati setiap sifat dan kaedah yang ada pada sesuatu, biarkan penaipan statik dan IDE kegemaran anda melakukannya untuk anda!

Ini mengurangkan masa pembangunan kerana:

• Anda tidak perlu ke belakang dan ke hadapan untuk merujuk sifat sesuatu

• Anda boleh menaip hanya huruf pertama harta/kaedah dan tekan enter (atau pilih cadangan yang betul, kemudian tekan enter), dan ia akan dilengkapkan secara automatik

Ia juga mengelakkan salah tulis perkataan , perkara yang menyebabkan lebih banyak pepijat dalam pengeluaran daripada yang sepatutnya.

Kurang kehilangan ilmu & tiada masa terbuang

Lazimnya dalam projek, pembangun yang berbeza menulis bahagian tertentu kod dan perkara yang kelihatan sangat jelas bagi orang yang menulisnya, mungkin tidak intuitif kepada semua orang.

Jika pembangun lain mengusahakan perkara baharu yang ditulis oleh orang lain, mereka perlu meluangkan sedikit masa untuk memahami perkara itu sebelum boleh membuat sebarang perubahan. Menggunakan penaipan statik membolehkan pembangun memotong BANYAK masa memahami nilai pembolehubah dan aliran pelaksanaan.

Jika pembangun yang menulis kod itu meninggalkan syarikat/pasukan, ia tidak akan memberi impak yang besar kerana semua dokumentasi ini secara langsung pada kod. Mudah dicari dan mudah difahami.

Pembangun juga perlu kurang bergantung pada pengaturcaraan berpasangan untuk dapat mengusahakan projek, jika ditaip dengan baik dan cukup mudah, mereka mungkin boleh membuat penambahbaikan/perubahan tanpa bercakap dengan seseorang dalam projek, meningkat secara tidak masuk akal kecekapan mereka.

Moden dan menarik kepada pemaju

TypeScript ialah salah satu bahasa yang paling digemari berdasarkan Tinjauan Pembangun Stack Overflow, berikut keputusan 4 tahun berturut-turut:

2020:

2021:

2022:

2023:

JSDoc tidak hadir dalam tinjauan, jadi saya tidak mempunyai apa-apa jenis data untuk mengatakan bahawa ini adalah pilihan yang baik. Satu-satunya perkara yang boleh saya katakan ialah HTMX sedang menggunakannya, tetapi ia adalah perpustakaan yang sangat mudah.

Sebaliknya, kita boleh mengatakan bahawa daripada tinjauan ini, pembangun telah memilih TypeScript berbanding JavaScript untuk kebanyakan tahun kebelakangan ini.

Fleksibel

Anda tidak perlu menaip semuanya. TypeScript dan JSDoc boleh meneka jenis kebanyakan perkara, yang menjadikannya lebih mudah dan kurang bertutur berbanding bahasa lain seperti Java atau C.

Untuk TypeScript, dalam senario terburuk, gunakan mana-mana sahaja. mana-mana jenis joker, ia mewakili apa-apa sahaja, dan kerana ini anda harus mengelakkannya pada semua kos , tetapi jika anda kekurangan masa atau tidak mahu disekat oleh kekurangan daripada jenis, anda mempunyai pilihan ini.

Untuk JSDoc, cuma jangan ulas apa-apa, JavaScript tulen!

Tiada lagi refactor yang tidak perlu

Saya akan menerangkan lebih lanjut tentang sebabnya dalam bahagian Ia mempunyai keluk pembelajaran yang tinggi, tetapi saya akan memberikan beberapa spoiler di sini.

Pangkalan kod dengan kod yang tidak difahami perlu difaktorkan semula dan pangkalan kod yang tidak mempunyai dokumentasi yang betul (yang kami bersetuju adalah mustahil untuk dikekalkan jika ia berasingan daripada kod) mempunyai jumlah bahagian yang lebih tinggi mustahil untuk difahami tanpa banyak penggalian dan masa untuk menganalisis.

Refactor tidak sepatutnya berlaku kerana kod anda adalah mustahil untuk difahami, tetapi kerana isu prestasi atau perubahan dalam logik perniagaan. perlu melakukan perkara yang sama dua kali adalah tidak baik untuk semua orang: pembangun, pengguna dan pelabur.

Lebih banyak kebebasan untuk pemaju

Kebiasaan untuk projek jangka panjang memerlukan ramai orang yang mengerjakannya, dan ia sentiasa mengambil sedikit masa (untuk pendatang baru dan pembangun yang lebih berpengalaman) untuk menjadikan pendatang baru mahir dengan pangkalan kod tersebut.

Dengan jenis statik, kami boleh mengurangkan banyak masa yang diperlukan, kerana pembangun boleh memahami sekurang-kurangnya asas kod sahaja, dan memerlukan bantuan pembangun lain hanya untuk memahami logik perniagaan yang lebih kompleks (jika mereka tidak didokumenkan dalam kod, tetapi ini adalah topik untuk artikel lain).

Ia memudahkan untuk mendapatkan pendatang baharu dalam projek, mengurangkan keluk pembelajaran mereka dengan banyak dan membolehkan mereka mengusahakan projek dengan risiko yang lebih rendah untuk memecahkan sesuatu, meningkatkan kecekapan pasukan anda secara keseluruhan.

Keburukan

Langkah binaan yang lebih kompleks

Satu-satunya kelemahan TypeScirpt ialah langkah binaannya lebih kompleks (kerana nyatakan, pada masa kini SEMUA projek JavaScript sudah pun mempunyai langkah binaan, jadi ia hanya menjadikannya lebih kompleks sedikit).

Anda mungkin memerlukan pemalam atau penyesuai yang betul untuk menyepadukan proses binaan anda dengan TypeScript, tetapi pada masa kini kami mempunyai sekumpulan perpustakaan, pemalam, alatan yang matang dan sedia untuk dihasilkan dan apa sahaja yang anda perlukan untuk menjadikannya berfungsi.

Saya tidak akan berbohong, ini mungkin menyebabkan anda mengalami masalah pada kali pertama, seperti kebanyakan alatan lain dalam ekosistem JavaScript, tetapi tidak mencukupi untuk mengatasi kelebihan.

Jika anda memilih untuk menggunakan JSDoc dan bukannya TypeScript, satu-satunya kelemahan yang TypeScript telah hilang, tetapi yang baharu muncul: JSDoc tidak berfungsi dengan baik dengan jenis yang lebih kompleks jika anda tidak menggunakan kelas untuk mewakilinya.

Membongkar hujah

Ia mempunyai keluk pembelajaran yang tinggi

Penaipan statik memerlukan anda menulis beberapa perkara lagi, tetapi keluk pembelajaran tidak berkaitan dengan rentetan : tambahan yang perlu anda tulis, tetapi betapa sukar untuk digunakan pangkalan kod itu.

Tanpa penaipan statik, anda memerlukan BANYAK lagi konteks untuk memahami perkara yang berlaku dalam kod, nilai yang ada pada pembolehubah dan logik perniagaan yang digunakan.

Mari lihat contoh:

function processOrders(orders) {
 // Logic here
}

Dengan hanya maklumat ini, bolehkah anda menentukan nilai yang ada pada pesanan? Anda boleh berkata Ia adalah satu tatasusunan!, tetapi rasa apa? Anda salah. pesanan ialah objek. Sifat manakah yang dimilikinya? Semoga berjaya meluangkan masa sekurang-kurangnya seminit melihat kod untuk mengetahuinya.

Adakah hartanah pilihan? Adakah mereka sentiasa wujud? Ia adalah objek, tatasusunan atau rentetan? Adakah ahli pasukan anda yang lain mempunyai pengetahuan ini atau orang yang menulis kod ini sudah lama tiada?

Taip statik dengan sendirinya mengurangkan keluk pembelajaran dengan jumlah yang besar.

Dengan JavaScript tulen, setiap orang yang akan bekerja pada sesuatu yang berkaitan dengan pemproses perlu melalui proses yang sama:

• Bertanya pada diri sendiri apakah pesanan

• Menghabiskan banyak masa dalam prosesMemerintahkan logik cuba memikirkannya

• Jika ia memerlukan gelagat prosesPesanan tertentu, mungkin meminta ahli pasukan lain untuk butiran lanjut dan meluangkan masa mereka juga

Mari masukkan dalam nombor, untuk menjadikannya lebih menyeronokkan:

• Sepasukan 5 orang, setiap satu membuat $100k/tahun

• Katakanlah mereka mesti bekerja dengan processOrder sekali setiap 6 bulan, masa yang cukup untuk melupakan butiran khusus

• Mereka menghabiskan 5 minit untuk memikirkan SEGALA PERKARA yang mereka perlukan (Ya, saya sangat optimis di sini)

• Sesuatu projek biasanya mempunyai beribu-ribu atau sekurang-kurangnya ratusan fungsi, semuanya serupa dengan Perintah proses, tetapi mari kita pertimbangkan hanya projek kecil di sini, dengan hanya 10 fungsi.

• 5 pembangun * 10 minit / tahun * 10 fungsi = 500 minit setahun

Jika setiap pembangun membuat 88 sen seminit, Kosnya $440 hanya untuk mengetahui apa 10 fungsi terima dan pulangkan. Ini adalah masa yang tidak produktif, yang tidak menjana apa-apa nilai, dalam kes TERBAIK senario fiksyen di mana projek ajaib anda hanya mempunyai 10 fungsi, dan bukan dunia sebenar di mana projek mempunyai ribuan daripada ini.

Kini, dengan TypeScript:

interface Orders {
 ids: Array<number>
 skipTypes?: Array<string> // Skip orders if they have specific types
}

interface ProcessedOrders {
 total: number
 success: number // Amount of orders that were succesfully
 processed skipped: number // Amount of skipped orders based on input filters
}

function processOrders(orders: Orders): Promise<ProcessedOrders> {
  // Logic here
}

Saya tahu bahawa ini adalah fungsi tidak intuitif yang dahsyat, tetapi ini berlaku dalam kod. Sepatutnya , tetapi begitu, jadi lebih baik sekurang-kurangnya didokumenkan.

Bertentangan dengan versi JavaScript tulen, di sini anda mempunyai semua konteks yang anda perlu fahami segala-galanya yang diterima dan dikembalikan oleh fungsi, sama ada pilihan atau tidak, dan prinsip asas fungsi fungsi .

Selepas semua ini, anda masih boleh mempertikaikan banyak perkara, seperti Masalah Kod Bersih, bukan masalah JavaScript! atau Kekurangan Dokumentasi masalah, bukan JavaScript. masalah!, tetapi saya memastikan anda, semua perkara ini adalah BERBEZA masalah yang ya, berlaku dalam kod, yang mungkin saya atasi dalam artikel lain, tetapi bukan fokus yang satu ini.

Sesetengah perpustakaan tidak menyokong TypeScript

Inilah keajaiban TypeScript: Anda tidak memerlukan perpustakaan anda untuk menyokong TypeScript.

Anda boleh menggunakan perpustakaan tanpa sebarang menaip, dan ia akan berfungsi sama, tetapi kerana ia akan menjadi lebih sukar untuk bekerja dengan perpustakaan JavaScript tulen (kerana ia tidak mempunyai apa-apa kelebihan yang dinyatakan dalam artikel ini), anda mungkin perlu mempertimbangkan menggunakan yang berbeza.

Saya perlu belajar sesuatu yang baru

Ya. Kami sebagai pembangun terpaksa mempelajari sesuatu yang baharu setiap hari. ia sebahagian daripada pekerjaan kami. Kami berada di sini untuk mencipta penyelesaian teknikal bagi masalah, menjadi rujukan dan memikirkan cara menyelesaikan masalah yang kami hadapi.

Mempelajari sesuatu yang baharu yang mempunyai banyak faedah adalah usaha yang menjadikan masa itu berbaloi.

Kesimpulan

Setelah mengetahui betapa banyak alat menaip statik membantu pembangunan, tanpa sebarang keburukan yang besar terhadapnya, tidak ada cara untuk menafikan betapa bermanfaatnya untuk semua orang: Pembangun, pengguna dan kewangan syarikat.

Saya harap artikel ini membantu anda memahaminya dan meyakinkan pasangan anda untuk meningkatkan pengalaman pembangunan anda.

Atas ialah kandungan terperinci TypeScript (dan JSDoc) lwn JavaScript. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!