Bagaimana seorang programmer digunakan untuk bahasa statis mengatasi kekurangan Javascript

Saya telah memprogram secara eksklusif dalam bahasa yang dikompilasi, khususnya Jawa, untuk sebagian besar karir saya. Salah satu hal favorit saya tentang Java adalah seberapa produktif Anda, dan seberapa sedikit kode yang harus Anda tulis, ketika menggunakan alat seperti Eclipse.

Kamu bisa:

• Mudah dan otomatis memperbaiki metode dan kelas Anda
• Lihat secara instan semua tempat di mana metode dipanggil, atau konstanta digunakan (Open Call Hierarchy / Show Reference)
• Pengetikan statis berarti Anda dapat menggunakan pelengkapan kode untuk menampilkan semua parameter / fungsi yang tersedia pada objek
• Kontrol-klik pada fungsi / nama anggota / kelas untuk langsung ke definisi

Semua fasilitas ini membuat saya merasa IDE adalah sahabat saya. Menulis kode Java dan khususnya memahami program orang lain menjadi jauh lebih mudah.

Namun, saya semakin sering dipanggil untuk menggunakan Javascript, dan pengalaman saya sejauh ini cukup negatif.

Khususnya:

• Tidak ada cara segera untuk menemukan titik masuk fungsi (selain pencarian teks biasa, yang kemudian dapat menghasilkan pencarian selanjutnya untuk metode lebih lanjut hierarki panggilan, setelah dua atau tiga di antaranya Anda lupa di mana Anda mulai)

• Parameter diteruskan ke fungsi, tanpa mengetahui sifat dan fungsi apa yang tersedia pada parameter itu (selain benar-benar menjalankan program, menavigasi ke titik di mana fungsi dipanggil, dan menggunakan console.logs untuk menampilkan semua properti tersedia)

• Penggunaan umum dari fungsi anonim sebagai panggilan balik, yang sering mengarah ke spaghetti jalur kode yang membingungkan, yang tidak dapat Anda navigasikan dengan cepat.

• Dan tentu saja, JSLint menangkap beberapa kesalahan sebelum runtime, tetapi bahkan itu tidak berguna seperti memiliki garis bergelombang merah di bawah kode Anda langsung di browser.

Hasilnya adalah bahwa Anda perlu memiliki seluruh program di kepala Anda setiap saat. Ini secara besar-besaran meningkatkan beban kognitif untuk menulis program yang kompleks. Dan semua hal ekstra yang perlu dikhawatirkan ini menyisakan sedikit ruang di otak saya untuk kreativitas dan pemecahan masalah yang sebenarnya.

Tentu, lebih cepat untuk hanya membuang objek bersama daripada menulis seluruh definisi kelas formal. Tetapi sementara program mungkin sedikit lebih mudah dan lebih cepat untuk ditulis, menurut pengalaman saya mereka jauh lebih sulit untuk dibaca dan didebug.

Pertanyaan saya adalah, bagaimana programmer lain mengatasi masalah ini? Javascript jelas semakin populer, dan blog yang saya baca adalah tentang seberapa produktif orang-orang bersamanya, daripada berusaha mati-matian mencari solusi untuk masalah ini.

GWT memungkinkan Anda untuk menulis kode untuk lingkungan Javascript di Jawa sebagai gantinya, tetapi sepertinya tidak banyak digunakan seperti yang saya harapkan; orang tampaknya lebih menyukai Javascript untuk program yang kompleks.

Apa yang saya lewatkan?

Dasar-dasar berbasis IDE tidak tersedia * dalam bahasa yang dinamis seperti javascript. Anda harus belajar melakukannya tanpa mereka. Anda harus mengganti dukungan alat dengan desain yang lebih baik.

Gunakan pola modul - baik dengan tangan, atau dengan alat seperti membutuhkan . Jaga agar modul-modulnya kecil, sehingga Anda dapat dengan mudah membahasnya.

Jangan mendefinisikan sebanyak mungkin tipe - gunakan objek anonim yang dibuat dekat dengan tempat panggilan. Kemudian Anda bisa melihat si penelepon dan si callee dan tahu apa yang terjadi.

Cobalah untuk menghindari menyambungkan kode Anda ke DOM - Berusaha keras untuk membatasi jumlah manipulasi DOM yang Anda lakukan dalam kode Anda. Jika Anda bisa mengirimkan koleksi penyeleksi atau jQuery, lakukan itu daripada membuat kode Anda tahu tentang struktur halaman.

* _{Jika Anda menggunakan perpustakaan populer, Anda bisa mendapatkan autocomplete palsu, tetapi lebih seperti "tampilkan semua metode jquery" daripada seperti "properti apa yang dimiliki objek ini". Menghemat pengetikan, tetapi tidak menawarkan jaminan kebenaran.}

Saya ingin menambahkan jawaban untuk pertanyaan ini karena saya telah berjalan dengan susah payah melalui beberapa Jawa baik, buruk tapi sebagian besar jelek akhir-akhir ini dan saya memiliki banyak generalisasi over-gross total tentang Java dan dev Java vs JS dan JS devs yang mungkin sebenarnya didasarkan pada sesuatu yang samar-samar menyerupai kebenaran yang bermanfaat.

Ada IDE Tetapi Dapat Membantu untuk Memahami Mengapa Belum Ada Banyak

Saya sudah mencoba Webstorm sekarang karena saya merasa tertarik pada pengembangan Node dan itu tidak cukup buruk sehingga saya benar-benar membelinya tetapi saya masih cenderung membuka file js di Scite lebih sering daripada WS. Alasan untuk ini adalah bahwa Anda dapat melakukan lebih banyak dengan lebih sedikit di JS tetapi juga karena UI bekerja memberikan umpan balik langsung, alat pengembang browser (khususnya Chrome dan Firebug) sebenarnya cukup bagus, dan (memperhitungkan konteks non-browser ) menjalankan kembali kode yang diubah dengan cepat dan mudah tanpa langkah kompilasi.

Hal lain yang saya cukup yakin adalah bahwa IDE pada dasarnya menciptakan permintaan mereka sendiri dengan mengaktifkan kode ceroboh yang Anda benar-benar tidak mampu dalam JavaScript. Ingin mempelajari cara kami mengelola JS? Mungkin membantu untuk memulai dengan mencoba menulis sesuatu yang non-sepele di Jawa tanpa IDE dan memperhatikan hal-hal yang harus Anda mulai lakukan dan pikirkan untuk benar-benar dapat mempertahankan / memodifikasi kode itu tanpa IDE bergerak meneruskan. IMO, hal-hal yang sama masih penting untuk menulis kode yang dapat dipelihara apakah Anda memiliki IDE atau tidak. Jika saya harus menulis kurikulum pemrograman 4 tahun, itu tidak akan membiarkan Anda menyentuh IDE selama dua tahun pertama dengan tujuan tidak mendapatkan alat dan ketergantungan memutar.

Struktur

Pengembang JS berpengalaman yang berurusan dengan aplikasi kompleks dapat dan membuat struktur kodenya. Sebenarnya itu adalah satu hal yang kita cenderung harus lebih baik dengan sejarah awal yang tidak memiliki IDE untuk membaca kode untuk kita tetapi juga karena bahasa yang sangat ekspresif dapat dengan kuat mengekspresikan basis data bencana yang benar-benar tidak dapat dipelihara dengan sangat cepat jika Anda tidak membuat kode dengan bijaksana.

Saya benar-benar memiliki kurva belajar yang cukup curam dalam memahami basis kode Java kami baru-baru ini sampai saya akhirnya menyadari bahwa tidak ada yang benar OOP. Kelas tidak lebih dari kumpulan metode terkait longgar mengubah data yang tersedia secara global duduk di dalam kacang atau DTO atau getter statis / setter. Pada dasarnya itu adalah binatang tua yang sama yang seharusnya diganti OOP. Jadi saya berhenti mencari dan memikirkan kode pada dasarnya. Saya baru saja belajar tombol pintas dan menelusuri kekacauan dan semuanya berjalan lebih lancar. Jadi, jika Anda sudah tidak terbiasa dengan kebiasaan itu, pikirkan lebih keras tentang OOD.

Aplikasi JS yang terstruktur dengan baik di tingkat tertinggi akan cenderung terdiri dari fungsi kompleks (misalnya jQuery) dan objek yang berinteraksi satu sama lain. Saya berpendapat bahwa tanda aplikasi yang terstruktur dengan baik dan mudah dirawat dalam bahasa apa pun adalah bahwa aplikasi tersebut dapat terbaca dengan sempurna apakah Anda melihatnya dengan IDE atau Notepad ++. Itu salah satu alasan utama saya sangat kritis terhadap injeksi ketergantungan dan tes TDD pertama yang diambil secara ekstrem.

Dan akhirnya, lepaskan kelas. Pelajari warisan prototypal. Ini sebenarnya cukup elegan mudah diimplementasikan ketika Anda benar-benar membutuhkan warisan. Saya menemukan pendekatan pengomposisikan cenderung bekerja lebih baik di JS, dan saya pribadi mulai sakit dan mengalami teror malam EXTJS setiap kali saya melihat lebih dari satu atau dua tingkat warisan terjadi dalam bahasa apa pun.

Prinsip Inti Pertama

Saya sedang berbicara tentang hal-hal inti yang harus diperoleh dari semua praktik baik lainnya: KERING, YAGNI, prinsip yang paling tidak mengejutkan, pemisahan yang bersih dari domain bermasalah, menulis ke antarmuka, dan menulis kode yang dapat dibaca manusia adalah inti pribadi saya. Apa pun yang sedikit lebih rumit yang menganjurkan ditinggalkannya praktik-praktik tersebut harus dianggap sebagai Kool Aid dalam bahasa apa pun, tetapi terutama bahasa seperti JavaScript di mana sangat mudah untuk meninggalkan warisan kode yang sangat membingungkan untuk orang berikutnya. Kopling longgar, misalnya, adalah hal-hal hebat sampai Anda mengambilnya sejauh itu sehingga Anda bahkan tidak tahu di mana interaksi antara objek terjadi.

Jangan Takut Mengetik Dinamis

Tidak ada banyak tipe inti dalam JavaScript. Untuk sebagian besar, aturan casting dinamis adalah praktis dan lurus ke depan tetapi membayar untuk mempelajarinya sehingga Anda dapat lebih baik belajar mengelola aliran data tanpa gips yang tidak perlu dan rutinitas validasi pointless. Percayalah kepadaku. Tipe ketat bagus untuk kinerja dan menemukan masalah pada kompilasi tetapi mereka tidak melindungi Anda dari apa pun.

Pelajari Omong kosong dari Fungsi dan Penutupan JS

Fungsi kelas satu JS bisa dibilang alasan utama JS memenangkan "Hanya Bahasa yang Layak Menyentuh Web Sisi Klien Dengan Penghargaan." Dan ya, sebenarnya ada persaingan. Mereka juga merupakan fitur utama JS. Kami membangun objek dengan mereka. Semuanya mencakup fungsi. Dan mereka memiliki fitur yang berguna. Kami dapat memeriksa params melalui kata kunci argumen. Kita dapat melampirkan dan memadamkannya untuk sementara waktu dalam konteks menjadi metode objek lain. Dan mereka membuat pendekatan berbasis peristiwa untuk hal-hal yang sangat mudah diimplementasikan. Singkatnya, mereka menjadikan JS binatang buas mutlak dalam mengurangi kompleksitas dan mengadaptasi berbagai implementasi JS itu sendiri (tetapi kebanyakan DOM API) tepat di sumbernya.

Evaluasi Kembali Pola / Praktek Sebelum Mengadopsi

Fungsi kelas satu dan tipe dinamis membuat banyak pola desain yang lebih kompleks benar-benar tidak berguna dan rumit di JS. Namun, beberapa pola yang lebih sederhana sangat berguna dan mudah diterapkan mengingat sifat JS yang sangat fleksibel. Adaptor dan dekorator sangat berguna dan saya telah menemukan lajang membantu untuk pabrik widget ui kompleks yang juga bertindak sebagai manajer acara untuk elemen ui yang mereka bangun.

Ikuti Pimpinan Bahasa dan Lakukan Lebih Banyak Dengan Lebih Sedikit

Saya percaya salah satu honchos kepala Java membuat argumen di suatu tempat bahwa verbositas sebenarnya adalah fitur positif yang membuat kode lebih mudah dipahami untuk semua pihak. Omong kosong. Jika itu benar, legalese akan lebih mudah dibaca. Hanya penulis yang dapat membuat apa yang mereka tulis lebih mudah dimengerti dan Anda hanya bisa melakukannya dengan menempatkan diri Anda pada posisi orang lain sesekali. Jadi merangkul kedua aturan ini. 1. Jadilah sejelas dan sejelas mungkin. 2. Dapatkan ke titik sialan sudah. Kemenangannya adalah kode yang bersih dan ringkas itu adalah urutan besarnya yang lebih mudah dipahami dan dipelihara daripada sesuatu di mana Anda harus melintasi dua puluh lima lapisan untuk mendapatkan dari pelatuk ke tindakan yang diinginkan sebenarnya. Kebanyakan pola yang mendukung hal semacam itu dalam bahasa yang lebih ketat sebenarnya merupakan solusi untuk keterbatasan yang tidak dimiliki JavaScript.

Semuanya ditempa dan tidak apa-apa

JS mungkin adalah salah satu bahasa yang paling tidak proteksionis dalam penggunaan populer. Pegang itu. Ini bekerja dengan baik. Sebagai contoh, Anda dapat menulis objek dengan vars "pribadi" persisten yang tidak dapat diakses hanya dengan mendeklarasikan vars reguler dalam fungsi konstruktor dan saya sering melakukannya. Tapi itu bukan untuk melindungi kode saya atau pengguna "dari diri mereka sendiri" (mereka bisa menggantinya dengan versi mereka sendiri selama waktu berjalan). Melainkan itu untuk menunjukkan niat karena asumsinya adalah bahwa lelaki lain cukup kompeten untuk tidak mau memecah-mecah ketergantungan dan akan melihat bahwa Anda tidak dimaksudkan untuk mendapatkannya secara langsung mungkin karena alasan yang baik.

Tidak Ada Batas Ukuran, Hanya Masalah Domain

Masalah terbesar yang saya miliki dengan semua basis kode Java yang pernah saya lihat adalah terlalu banyaknya file kelas. Pertama-tama SOLID hanyalah pengulangan membingungkan dari apa yang harus Anda ketahui tentang OOP. Kelas harus menangani serangkaian masalah terkait yang spesifik. Tidak ada masalah dengan satu metode. Itu hanya mengambil kode Ch-func-spaghetti tua rantai buruk hanya dengan penambahan semua sintaks kelas gunanya untuk boot. Tidak ada batasan ukuran atau metode. Jika masuk akal untuk menambahkan sesuatu ke fungsi atau kelas atau konstruktor yang sudah lama, masuk akal. Ambil jQuery. Ini seluruh toolset panjang perpustakaan dalam satu fungsi dan tidak ada yang salah dengan itu. Apakah kita masih membutuhkan jQuery hingga debat yang masuk akal tetapi dalam hal desain,

Jika Java adalah Semua yang Anda Ketahui, Bereksperimenlah dalam Sesuatu Dengan Sintaks Non-C Berbasis

Ketika saya mulai mengacaukan Python karena saya menyukai apa yang saya dengar tentang Django, saya belajar untuk mulai memisahkan sintaksis dari desain bahasa. Akibatnya, menjadi lebih mudah untuk memahami Java dan C sebagai jumlah bagian desain bahasa mereka daripada jumlah hal yang mereka lakukan secara berbeda dengan sintaksis yang sama. Efek samping yang bagus adalah bahwa semakin Anda memahami bahasa lain dalam hal desain, semakin baik Anda memahami kekuatan / kelemahan bahasa yang paling Anda kenal melalui kontras.

Kesimpulan

Sekarang, mempertimbangkan semua itu, mari kita tekan semua poin masalah Anda:

• Tidak ada cara segera untuk menemukan titik masuk fungsi (selain pencarian teks biasa, yang kemudian dapat menghasilkan pencarian selanjutnya untuk metode lebih lanjut hierarki panggilan, setelah dua atau tiga di antaranya Anda lupa di mana Anda mulai)

Chrome dan Firebug benar-benar memiliki penelusuran jejak. Tetapi lihat juga poin saya tentang struktur dan menjaga segala sesuatunya singkat dan langsung. Semakin Anda dapat menganggap aplikasi Anda sebagai konstruk yang lebih besar yang dienkapsulasi dengan baik berinteraksi satu sama lain, semakin mudah untuk mencari kesalahan siapa itu ketika terjadi kesalahan. Saya akan mengatakan ini juga berlaku untuk Jawa. Kami memiliki konstruktor fungsi seperti kelas yang dapat diservis dengan sempurna untuk masalah OOP tradisional.

function ObjectConstructor(){
    //No need for an init method.
    //Just pass in params and do stuff inside for instantiation behavior

    var privateAndPersistent = true;

    //I like to take advantage of function hoisting for a nice concise interface listing
    this.publicAndPointlessEncapsulationMurderingGetterSetter
    = publicAndPointlessEncapsulationMurderingGetterSetter;
    //Seriously though Java/C# folks, stop with the pointless getter/setters already

    function publicAndPointlessEncapsulationMurderingGetterSetter(arg){
        if(arg === undefined){
            return privateAndPersistent;
        }
        privateAndPersistent = arg;
    }

}

ObjectConstructor.staticLikeNonInstanceProperty = true;

var instance = new ObjectConstructor();//Convention is to  capitalize constructors

Dalam kode saya, saya hampir tidak pernah menggunakan objek literal {}sebagai komponen aplikasi struktural karena mereka tidak dapat memiliki vars (pribadi) internal dan lebih suka memesannya untuk digunakan sebagai struktur data. Itu membantu menetapkan harapan yang menjaga kejelasan niat. (jika Anda melihat ikal, itu data, bukan komponen arsitektur aplikasi).

• Parameter diteruskan ke fungsi, tanpa mengetahui sifat dan fungsi apa yang tersedia pada parameter itu (selain benar-benar menjalankan program, menavigasi ke titik di mana fungsi dipanggil, dan menggunakan console.logs untuk menampilkan semua properti tersedia)

Sekali lagi, lihat alat peramban modern. Tetapi juga, mengapa sangat mengecewakan untuk menjalankan program lagi? Muat ulang adalah sesuatu yang biasanya dikenali oleh web dev sisi klien setiap beberapa menit karena tidak ada biaya sama sekali untuk melakukannya. Ini lagi, titik lain di mana struktur aplikasi dapat membantu, tetapi itu adalah salah satu sisi negatif dari JS yang harus Anda jalankan validasi Anda sendiri ketika menegakkan kontrak sangat penting (sesuatu yang hanya saya lakukan pada titik akhir yang terpapar pada hal-hal lain yang basis kode saya tidak lakukan. dapat mengontrol). IMO, pengorbanan ini sangat bermanfaat.

• Penggunaan umum dari fungsi anonim sebagai panggilan balik, yang sering mengarah ke spaghetti jalur kode yang membingungkan, yang tidak dapat Anda navigasikan dengan cepat.

Ya itu buruk pada hal-hal yang tidak sepele. Jangan lakukan itu. Beri nama anak-anak fungsi Anda. Lebih mudah untuk melacak hal-hal juga. Anda dapat mendefinisikan, mengevaluasi (diharuskan untuk menetapkan), dan menetapkan fungsi sepele yang sederhana sesuai dengan:

doSomethingWithCallback( (function callBack(){}) );

Sekarang Chrome akan memiliki nama untuk Anda ketika Anda menelusuri panggilan. Untuk fungsi non-sepele saya akan mendefinisikannya di luar panggilan. Perhatikan juga bahwa fungsi anonoymous yang ditugaskan ke variabel masih anonim.

• Dan tentu saja, JSLint menangkap beberapa kesalahan sebelum runtime, tetapi bahkan itu tidak berguna seperti memiliki garis bergelombang merah di bawah kode Anda langsung di browser.

Saya tidak pernah menyentuh barang-barang itu. Crockford memberikan beberapa hal baik kepada komunitas tetapi JSLint melewati batas menjadi preferensi gaya dan menyarankan elemen-elemen tertentu dari JavaScript adalah bagian yang buruk tanpa alasan yang jelas, IMO. Abaikan saja satu hal tentang regEx dan kelas negasi yang diikuti oleh * atau +. Wildcard memiliki kinerja yang lebih buruk dan Anda dapat dengan mudah membatasi pengulangan dengan {}. Juga, abaikan semua yang dia katakan tentang fungsi konstruktor. Anda dapat dengan mudah membungkusnya dalam func pabrik jika kata kunci baru mengganggu Anda. CSSLint (bukan Crockford) bahkan lebih buruk di bagian depan saran buruk. Selalu bawa orang yang melakukan banyak pembicaraan dengan sebutir garam. Terkadang saya bersumpah mereka hanya ingin membangun otoritas atau menghasilkan materi baru.

Dan lagi, Anda harus melupakan apa yang telah Anda pelajari dengan masalah run-time yang Anda miliki. (itu yang umum saya lihat dengan banyak Java / C # devs) Jika melihat kesalahan dalam run-time masih mengganggu Anda 2 tahun kemudian, saya ingin Anda duduk dan mengisi ulang spam di browser sampai tenggelam. Ada tidak ada pembagian waktu kompilasi / run-waktu (yah bukan yang terlihat - JS dijalankan pada JIT sekarang). Tidak hanya menemukan bug saat run-time, tetapi juga sangat bermanfaat untuk memuat ulang spam yang murah dan mudah dan menemukan bug di setiap titik pemberhentian Anda.

Dan dapatkan crack pada alat dev Chrome itu. Mereka terintegrasi langsung ke webkit. Klik kanan di Chrome. Memeriksa elemen. Jelajahi tab. Banyak kekuatan debug di sana dengan kemampuan untuk mengubah kode di konsol selama run-time menjadi salah satu opsi yang paling kuat tetapi kurang jelas. Sangat bagus untuk pengujian.

Pada catatan terkait, kesalahan adalah teman Anda. Jangan pernah menulis pernyataan tangkap kosong. Di JS kita tidak menyembunyikan atau mengubur kesalahan (atau setidaknya kita tidak boleh batuk YUI / batuk ). Kami hadir untuk mereka. Kurang dari itu akan menyebabkan sakit debug. Dan jika Anda menulis pernyataan menangkap untuk menyembunyikan potensi kesalahan dalam produksi setidaknya diam-diam mencatat kesalahan dan mendokumentasikan cara mengakses log.

Apa yang Anda katakan hanyalah keluhan umum dari orang yang berpikiran Jawa yang melihat JavaScript.

Pertama-tama mari kita jawab pertanyaan Anda ...

... pertanyaan saya adalah, bagaimana programmer lain mengatasi masalah ini ...

Jawaban: Mereka TIDAK. Mereka mempelajari filosofi JavaScript dengan terlebih dahulu melepaskan kultus Jawa.

Anda harus memahami premis ini ... JavaScript BUKAN Java. Ini bukan tentang sintaksis - ini lebih tentang filosofi.

Sekarang mari kita ambil beberapa dari mereka ...

• Lihat secara instan semua tempat di mana metode dipanggil, atau konstanta digunakan (Open Call Hierarchy / Show Reference)

  Kontrol-klik pada fungsi / nama anggota / kelas untuk langsung ke definisi

  Semua ini tersedia - cukup pilih IDE yang layak.

• Pengetikan statis berarti Anda dapat menggunakan pelengkapan kode untuk menampilkan semua parameter / fungsi yang tersedia pada objek

  Ini bukan masalah yang Anda atasi . Ini adalah sesuatu yang mengharuskan Anda mengubah pandangan tentang pemrograman. Sistem tipe longgar adalah salah satu kekuatan JavaScript. Memahami mengetik longgar - dan belajar untuk menghargainya. Selain itu, penyelesaian kode berfungsi sangat baik dengan JS.

• Dan tentu saja, JSLint menangkap beberapa kesalahan sebelum runtime, tetapi bahkan itu tidak berguna seperti memiliki garis bergelombang merah di bawah kode Anda langsung di browser.

  Firebug, Chrome / Safari console dan bahkan IDE melakukan semua itu dan LEBIH.

  Ada JSHint yang dapat melakukan analisis statis yang bagus yang digunakan oleh programmer Java.

• Hasilnya adalah bahwa Anda perlu memiliki seluruh program di kepala Anda setiap saat. Ini secara besar-besaran meningkatkan beban kognitif untuk menulis program yang kompleks.

  Salah! Sebaliknya, JavaScript adalah bahasa pemrograman "ringan" - dan mendorong Anda untuk memiliki program yang lebih sederhana. Seperti kata Doug Crockford ... itu akan "menghukum" Anda jika Anda mencoba untuk menulis program berbasis model dalam JavaScript.

• sementara program mungkin sedikit lebih mudah dan lebih cepat untuk ditulis, menurut pengalaman saya mereka jauh lebih sulit untuk dibaca dan di-debug.

  Sangat salah! Bagaimana Anda memutuskan keterbacaan berdasarkan bahasa pemrograman? Program dapat dibaca (atau tidak) - BUKAN bahasa. Ditambah lagi, JavaScript punya debugger yang fantastis.

Maafkan saya jika saya terdengar agak kasar - tetapi sebenarnya Anda harus mengubah disposisi Java Anda untuk memahami JavaScript.

Hanya pemrogram Java "dewasa" yang dapat menghargai JavaScript - dan Anda tidak dapat menguasai apa yang tidak Anda hargai. Sekali lagi, maaf karena berterus terang.

Secara umum, sulit untuk memiliki alat yang Anda sebutkan untuk bahasa dinamis (kecuali IDE adalah bagian dari runtime - yaitu Smalltalk). Karena itu, setelah Anda mempelajari editor teks yang benar-benar bagus, sebagian besar IDE terlihat kurang menarik - setidaknya itulah pengalaman saya.

Itulah harga yang kami bayar untuk menggunakan bahasa yang tidak diketik dengan baik. Orang hanya bisa bertanya-tanya mengapa kekejian ini menjadi begitu populer. Kerugiannya jauh melebihi keunggulan dari bahasa yang diketik dengan buruk.

Mungkin kita harus menerapkan prinsip Non-kerja sama dengan sampah ini untuk menghilangkannya.

Saya dulu tidak suka javascript (dan pengetikan dinamisnya) tapi saya telah tumbuh untuk menghargai orientasi objek, penutupan dan pemrograman fungsionalnya . Juga, objek globalnya dan penghapusan konversi tipe sunyi adalah menghirup udara segar ketika saya pertama kali menemukannya.

Gagasan pilihan saya untuk javascript adalah webstorm karena mudah untuk membuat jQuery intellitext berfungsi (sayangnya tidak gratis).

Juga, saya tidak akan mengatakan itu tumbuh - sudah di mana-mana.

Poin spesifik Anda:

Tidak ada cara langsung untuk menemukan titik masuk fungsi

Saya tidak mengerti ini, bagaimana bisa lebih sederhana?

Parameter diteruskan ke fungsi, tanpa mengetahui sifat dan fungsi apa yang tersedia pada parameter itu

Jika Anda mengatur ide Anda untuk memasukkan definisi objek, properti objek akan tersedia melalui intellitext (tetapi saya mungkin melewatkan poin Anda di sini).

Penggunaan umum dari fungsi anonim sebagai panggilan balik, yang sering mengarah ke spaghetti jalur kode yang membingungkan, yang tidak dapat Anda navigasikan dengan cepat.

Penggunaan umum? Jika Anda tidak menyukai fungsi anonim, jangan gunakan itu. Atau apakah Anda merujuk ke jQuery yang menggunakannya secara substansial? jQuery mungkin dianggap oleh sebagian besar pengembang web sebagai penghemat waktu tunggal terbesar dalam sejarah pengembangan web .

JSLint menangkap beberapa kesalahan sebelum runtime

Itu menangkap mereka semua, Anda bisa memasukkannya ke dalam ide Anda . Atau Webstorm memasukkannya secara default (saya pikir).

Apa yang saya lewatkan?

Anda kehilangan dua keuntungan luar biasa yang dimiliki Javascript atas Java:

• Kode Javascript sekitar seperempat ukuran kode Java yang setara.
• Anda tidak perlu menunggu kompilasi dan server restart.

Saya bekerja secara berbeda dalam Javascript. Saya menambahkan sedikit kode sekaligus, sesedikit mungkin saya bisa menguji, dan menyegarkan browser dan mengujinya. Dengan jQuery, beberapa baris Javascript adalah yang paling saya butuhkan sepanjang waktu.

Saya menemukan pemrograman Java relatif tidak produktif , dan sekarang saya menulis semua kode sisi server saya di Groovy, untuk dua alasan yang sama.

Saya tahu pertanyaan ini sudah lama tetapi sebagai seorang programmer C ++ / C # yang memiliki perasaan yang sama tetapi yang sekarang telah melakukan banyak JavaScript selama 10 tahun terakhir, rekomendasi pertama saya adalah untuk mencoba Visual Studio Code .

Tentu saja tidak dapat menawarkan setiap fitur yang dapat ditambahkan dengan bahasa yang sangat diketik tetapi cukup dekat.

Itu juga dapat mengambil info jenis dari naskah dan menerapkannya ke JavaScript. Bahkan jika Anda tidak pernah menggunakan naskah, Anda bisa mendapatkan pelengkapan kode dan dokumentasi pada banyak API saat Anda mengetikkan JavaScript.

Jadi untuk pertanyaan Anda

• Tidak ada cara segera untuk menemukan titik masuk fungsi (selain pencarian teks biasa, yang kemudian dapat menghasilkan pencarian selanjutnya untuk metode lebih lanjut hierarki panggilan, setelah dua atau tiga di antaranya Anda lupa di mana Anda mulai)

Tampaknya sebagian besar diselesaikan dalam VSCode?

• Parameter diteruskan ke fungsi, tanpa mengetahui sifat dan fungsi apa yang tersedia pada parameter itu

Ini dipecahkan untuk banyak IDE dengan mendokumentasikan kode Anda dengan komentar gaya JSDoc atau naskah. Para editor akan membaca komentar dan memberi Anda penyelesaian yang sama seperti dulu

Penggunaan umum dari fungsi anonim sebagai panggilan balik, yang sering mengarah ke spaghetti jalur kode yang membingungkan, yang tidak dapat Anda navigasikan dengan cepat.

Sebagai programmer C #, fungsi anonim juga ada di sana dan telah ditambahkan ke C ++. Saya pikir ini adalah sesuatu yang Anda harus terbiasa.

Meskipun panggilan balik sebagian besar telah diganti dengan janji dan dengan async / menunggu dan jika Anda memiliki api yang menggunakan panggilan balik, Anda dapat dengan cepat membungkusnya untuk menggunakan janji dan kemudian menggunakan async / menunggu sehingga masalah hilang.

Dan tentu saja, JSLint menangkap beberapa kesalahan sebelum runtime, tetapi bahkan itu tidak berguna seperti memiliki garis bergelombang merah di bawah kode Anda langsung di browser.

Anda akan mendapatkan garis bergelombang dalam Visual Studio Code. Bukan hanya itu tetapi jika Anda mengaktifkan integrasi ESLint Anda akan mendapatkan banyak sekali peringatan dan atau kesalahan yang disorot dalam editor Anda. Lebih dari yang saya lihat untuk bahasa lain sebenarnya. Pengalaman saya adalah linters untuk C / C # / Java telah cukup sulit dikodekan dimana ESLint dapat dikonfigurasi secara besar-besaran dan diperluas secara besar-besaran dan karena itu perpustakaan populer bahkan dapat berintegrasi untuk memberikan saran dan peringatan tentang penggunaan perpustakaan khusus dalam editor. Sesuatu yang belum saya lihat secara pribadi dalam bahasa lain (meskipun mungkin sekarang umum untuk bahasa lain?)

Ini juga 2018 dan ES7 adalah norma baru sehingga Anda dapatkan class. Anda selalu menggunakan mode ketat. Anda tidak pernah menggunakan vardan selalu menggunakan constdan letdan banyak hal yang membuat programmer C ++ / C # / Java sulit untuk menghilang. Aktifkan no-undefaturan di ESLint dan bahkan lebih banyak masalah hilang

Yang mengatakan belajar bagaimana thissebenarnya bekerja dan bagaimana fungsi dan metode benar-benar bekerja karena itu tidak sama dengan C ++ / C # / Java.

JavaScript 2-3 tahun pertama saya membuat saya frustrasi. Pada beberapa titik itu diklik. Saya berhenti mencoba memaksanya untuk menjadi C ++ / C # / Java dan sekarang saya merasa frustrasi kembali ketika hal-hal yang akan mengambil 15 baris dalam JavaScript mengambil 150 dalam bahasa-bahasa lain.

Jika Anda menyukai IDE dan digunakan untuk gerhana, periksa Aptana sebagai IDE Untuk JavaScript. Saya pikir itu bisa melakukan banyak hal yang Anda inginkan. (Saya pribadi benci IDE tetapi itu adalah percakapan yang berbeda).

Adapun fungsi anonim, saya menemukan bahwa mereka adalah fitur yang paling kuat dalam JavaScript dan mencoba untuk bekerja dalam bahasa yang tidak memilikinya pada saat ini cukup menyakitkan.

Jika Anda menginginkan sesuatu yang lain yang dapat dikompilasi ke JavaScript ada banyak opsi, CofffeeScript, Clojure dan GWT semuanya melompat ke pikiran tetapi ada yang lain.

Saya belum menggunakannya sendiri tetapi saya telah melihat beberapa demo dan saya sangat terkesan dengan Cloud 9 sebagai IDE JavaScript.

Anda dapat menggunakan model layanan online atau mengunduhnya dari GitHub.

Dan sebagai bukti kualitasnya sebagai IDE, Cloud9 ditulis menggunakan ... Cloud9!