Apakah bahasa dinamis tidak menguntungkan untuk pengembangan tangkas?


12

Dari apa yang saya baca pengembangan tangkas sering melibatkan refactoring atau membalikkan kode teknik menjadi diagram. Tentu saja ada lebih dari itu, tetapi jika kita menganggap praktik yang mengandalkan kedua metode ini, apakah bahasa yang diketik secara dinamis tidak menguntungkan?

Tampaknya bahasa yang diketik secara statis akan membuat refactoring dan membalikkan teknik menjadi lebih mudah.

Apakah Refactoring atau (otomatis) rekayasa terbalik sulit jika bukan tidak mungkin dalam bahasa yang diketik secara dinamis? Apa yang dikatakan proyek dunia nyata tentang penggunaan bahasa yang diketik secara dinamis untuk metodologi tangkas?


5
Membalikkan kode teknik menjadi diagram? Mengapa Anda melakukannya di Agile?
CaffGeek

7
Agile tidak berarti "kode dulu, dokumentasikan nanti".
Gort the Robot

@CaffGeek: Beberapa buku yang sering direkomendasikan menyarankan untuk menggambar diagram pada papan tulis, kemudian kode dan akhirnya membalikkan kode insinyur menjadi diagram untuk pertemuan berikutnya.
Gerenuk

1
Saya pikir mengetik sangat harus dihapus dari tag dan teks dari pertanyaan ini. Pertanyaannya tampaknya tentang statis vs dinamis tidak kuat vs lemah.
Winston Ewert

@ WinstonEwert - Panggilan bagus, saya telah mengubah tag menjadi dynamic-typingdanstatic-typing
Carson63000

Jawaban:


11

Bahasa dinamis secara teori tidak menguntungkan, semuanya sama, karena mereka kurang menentukan tentang bagaimana kode bekerja (apa kendalanya), dan karena itu lebih sedikit refactoring dapat dilakukan secara otomatis, dan masalah yang muncul tidak dapat dideteksi secara otomatis juga .

Tapi semuanya tidak sama. Bahasa dinamis yang paling populer memungkinkan kode yang sangat kompak namun mudah dipahami, yang umumnya membuat pengembangan di dalamnya lebih cepat, dan membuat logika (yang dapat berubah dalam refactoring) lebih mudah dikenali secara visual. Jadi, meskipun Anda mungkin kehilangan beberapa keuntungan relatif dari bekerja dalam bahasa yang dinamis, Anda mungkin masih unggul, terutama jika Anda berencana melakukan refactoring dengan tangan.

Di sisi lain, ada bahasa yang diketik secara statis dengan keunggulan yang pada dasarnya sama dengan bahasa dinamis (yaitu kompak dan dapat dipahami - dengan jenis yang sebagian besar disimpulkan, tetapi sangat banyak di sana): Haskell mungkin merupakan contoh utama, tetapi OCaML / F #, Scala, dan yang lainnya ada di kategori ini juga. Sayangnya, karena mereka kurang banyak digunakan daripada bahasa yang diketik secara statis paling populer, mereka tidak memiliki set alat yang luas untuk mereka (misalnya untuk refactoring).

Jadi, sebagai garis bawah, saya pikir Anda akan melakukan cukup dengan metodologi tangkas di sebagian besar bahasa; Saya tidak akan mengatakan ada pemenang yang jelas sekarang karena latihan belum mengejar teori.


Saya pikir jawaban ini membahas poin-poin kunci dari pertanyaan terbaik :) Bisakah Anda juga menguraikan tentang pentingnya refactoring aman dan rekayasa balik untuk pengembangan tangkas? Saya menganggap itu memainkan peran yang sangat penting? Mungkin kurang dari yang saya kira dan alat untuk bahasa dinamika cukup baik.
Gerenuk

1
@Gerenuk - Saya tidak memiliki pengalaman yang cukup dengan pengembangan gesit (terutama dalam bahasa dinamis) untuk memberikan jawaban yang otoritatif - apakah aspek refactoring tidak ditekankan, dibiarkan sama, dll? Ingatlah bahwa aspek-aspek umum lainnya dari proses - pengembangan yang didorong oleh tes, misalnya - dapat membantu menentukan dengan tepat di mana refactoring Anda serba salah, dan jika Anda melakukan sedikit usaha lebih banyak, katakanlah, fase desain, Anda mungkin tidak perlu untuk refactor sebanyak. Saya tidak berpikir satu teknik tertentu adalah kuncinya - itu menjaga seperangkat alat di tangan, sering digunakan dan secara kolaboratif.
Rex Kerr

14

Refactoring otomatis ditemukan di Smalltalk, bahasa yang diketik secara dinamis. Jadi tidak, bukan tidak mungkin untuk memiliki refactoring otomatis dalam bahasa yang diketik secara dinamis. Betapa sulitnya itu jauh lebih tergantung pada faktor-faktor lain selain disiplin mengetik. C ++ dan Java keduanya diketik secara statis, tetapi alat refactoring hanya benar-benar ada untuk Java. Smalltalk dengan introspeksi dan sintaksis sederhana adalah kandidat yang sangat baik untuk alat refactoring.

Dalam beberapa hal, pengetikan dinamis sebenarnya membuat refactoring lebih mudah. Jika Anda memiliki suite pengujian yang baik, Anda dapat memastikan refactoring Anda tidak merusak apa pun. Basis kode yang diketik secara dinamis biasanya lebih kecil. Selain itu, refactoring cenderung memengaruhi kode yang lebih sedikit. Secara keseluruhan upaya yang terlibat dalam refactoring basis kode dinamis secara manual kurang dari basis kode statis.


1
Bagaimana dengan reverse engineering? Apakah Smalltalk berbeda dari Python dalam hal mengetik? Tampaknya masalah yang sulit untuk menyimpulkan semua jenis Python dan dengan demikian menentukan metode mana yang benar-benar identik dan bukan hanya nama yang sama.
Gerenuk

2
Smalltalk tidak yang jauh berbeda dari Python berkaitan dengan mengetik. Ini adalah , bagaimanapun, secara signifikan berbeda berkaitan dengan perkakas . Alat dan IDE yang tersedia untuk Smalltalk jauh lebih baik daripada yang tersedia untuk Python atau bahkan C #, C ++ dan Java. Alasan mengapa IDE untuk Python buruk bukan karena Python diketik secara dinamis, itu karena, well, IDE untuk Python buruk. Jangan lupa bahwa IDE yang sekarang kita kenal sebagai Eclipse dulu bernama VisualAge untuk Smalltalk. Komunitas Smalltalk memiliki pengalaman selama 40 tahun dalam membangun IDE, dan mereka menerapkannya pada Java.
Jörg W Mittag

@ Geerenuk, pengetikan Smalltalk tidak berbeda dengan python. Dengan cara lain, seperti introspeksi, Smalltalk memang menyediakan fitur yang lebih ramah untuk refactoring. Ketik inferencing dengan python akan membutuhkan pekerjaan, tetapi telah dilakukan, lihat proyek PyPy.
Winston Ewert

1
@ WinstonEwert "tetapi Anda dapat melakukan refactor secara manual, dan bahasa yang dinamis sebenarnya membuat itu cukup mudah" - Tidak, refactoring manual tidak menjadi skala. Dukungan alat untuk refactoring mengubah segalanya bahkan ketika refactoring tidak 100% otomatis (lihat cuplikan studi kasus di bawah ini - programmer.stackexchange.com/a/166594/4334 )
igouy

1
Hampir setiap titik dalam "pemrograman dinamis Anda sebenarnya membuat refactoring lebih mudah" meragukan atau tidak berurutan. Pemrograman dinamis tidak berarti Anda memiliki test suite yang lebih komprehensif, hanya yang lebih besar (karena beberapa hal perlu pengujian yang kalau tidak secara statis akan tertangkap). Anda tidak menawarkan dukungan apa pun untuk "refactoring cenderung memengaruhi kode yang lebih sedikit" (sebagai tambahan untuk "proyek ini lebih kecil", yang mungkin benar mengingat potongan bahasa dinamis saat ini). Dan "usaha yang terlibat dalam refactoring secara manual" tampaknya salah kecuali Anda tidak akan membiarkan kompiler membantu Anda!
Rex Kerr

8

Refactoring ditemukan dalam bahasa dinamis. Alat Refactoring Otomatis diciptakan dalam bahasa yang dinamis. IDE ditemukan dalam bahasa dinamis. Beberapa Metodologi Agile diciptakan dalam bahasa yang dinamis.

Saya benar-benar tidak melihat masalah.


"Smalltalk tidak jauh berbeda dari Python dalam hal mengetik. Namun, sangat berbeda dengan perkakas." - Mungkin itu mulai berubah, lihat jetbrains.com/pycharm/features/index.html
igouy

3

Jangan sampai kita lupa, cara kerja "Agile" yang kemudian dikenal sebagai Extreme Programming (XP) diciptakan pada proyek Smalltalk (dan Smalltalk tentu saja dianggap sebagai bahasa "dinamis").

Berikut ini adalah studi kasus penggunaan industri alat refactoring yang disediakan dengan bahasa yang diketik secara dinamis:

Aplikasi Smalltalk yang sangat besar dikembangkan di Cargill untuk mendukung pengoperasian elevator biji-bijian dan aktivitas perdagangan komoditas terkait. Aplikasi klien Smalltalk memiliki 385 jendela dan lebih dari 5.000 kelas. Sekitar 2.000 kelas dalam aplikasi ini berinteraksi dengan kerangka akses data awal (sekitar 1993). Kerangka kerja secara dinamis melakukan pemetaan atribut objek ke kolom tabel data.

Analisis menunjukkan bahwa meskipun pencarian dinamis menghabiskan 40% waktu eksekusi klien, itu tidak perlu.

Antarmuka lapisan data baru dikembangkan yang mengharuskan kelas bisnis untuk menyediakan atribut objek untuk pemetaan kolom dalam metode yang dikodekan secara eksplisit. Pengujian menunjukkan bahwa antarmuka ini lebih cepat dari pesanan. Masalahnya adalah bagaimana mengubah 2.100 pengguna kelas bisnis dari lapisan data.

Aplikasi besar yang sedang dikembangkan tidak dapat membekukan kode sementara transformasi antarmuka dibangun dan diuji. Kami harus membuat dan menguji transformasi dalam cabang paralel dari repositori kode dari arus pengembangan utama. Ketika transformasi diuji sepenuhnya, maka itu diterapkan ke aliran kode utama dalam satu operasi.

Kurang dari 35 bug ditemukan di 17.100 perubahan. Semua bug dengan cepat diselesaikan dalam periode tiga minggu.

Jika perubahan dilakukan secara manual, kami memperkirakan bahwa akan dibutuhkan 8.500 jam, dibandingkan dengan 235 jam untuk mengembangkan aturan transformasi.

Tugas diselesaikan dalam 3% dari waktu yang diharapkan dengan menggunakan Aturan Penulisan Ulang. Ini merupakan peningkatan dengan faktor 36.

dari "Transformasi lapisan data aplikasi" Will Loew-Blosser OOPSLA 2002

Juga - "Alat untuk membuat perubahan yang tidak mungkin - pengalaman dengan alat untuk mengubah program Smalltalk besar"


1

Menurut saya, prinsip Anda kedengarannya benar .

Bahasa yang sangat diketik seperti C # adalah kandidat yang baik untuk basis kode yang terus-menerus perlu anjak ulang. Pada dasarnya sebagian besar alat re-factoring (seperti Resharper, JustCode, dll.) Di pasar sangat efektif dalam bahasa pemrograman yang diketik secara statis.

Apa yang dikatakan proyek dunia nyata tentang penggunaan bahasa yang diketik secara dinamis untuk metodologi tangkas?

Untuk tim pengembangan yang mempraktikkan metodologi Agile / Scrum, sangat membantu (bahkan kritis) untuk memiliki seperangkat alat re-factoring yang baik di bawah armor. Jika tidak, semua perubahan mendadak dalam sprint mendatang mungkin merupakan mimpi buruk untuk dimodifikasi atau dirancang ulang.

Dengan demikian, metodologi lincah tidak memberikan keuntungan untuk bahasa yang diketik secara statis atau dinamis sekali. Apa yang disediakannya adalah pendekatan berulang untuk membangun aplikasi yang solid.


4
Bahasa dinamis memiliki Alat Refactoring Otomatis jauh sebelum C # bahkan ada dan ketika Notepad masih merupakan IDE Java yang paling kuat.
Jörg W Mittag

4
Jawaban ini sama sekali tidak didukung oleh pengalaman saya. Bahasa dinamis biasanya lebih cepat untuk melakukan hal-hal di daripada yang statis diketik lebih konvensional (saya telah mendapat belajar Haskell atau ML atau sesuatu seperti kadang-kadang itu). Mereka juga jauh lebih cepat untuk dimodifikasi jika tiba-tiba diperlukan, yang mengarah pada kesimpulan saya bahwa Common Lisp adalah bahasa terbaik ketika Anda tidak benar-benar tahu apa yang Anda lakukan. Terlebih lagi, di mana menurut Anda refactoring dimulai?
David Thornley

1
mengapa Anda berpikir begitu, misalnya javascript adalah bahasa yang dinamis, tetapi Re-sharper tidak melakukan pekerjaan licin yang sama seperti halnya dengan C #. Kedua, saya TIDAK mengatakan bahwa "bahasa dinamis lebih lambat untuk melakukan hal-hal".
Yusubov

Dari orang-orang yang membawa Anda IntelliJ IDEA - PyCharm - "Ganti nama refactoring memungkinkan untuk melakukan perubahan kode global dengan aman dan instan. Perubahan lokal dalam file dilakukan di tempat. Refactoring berfungsi dalam proyek Python dan Django. Gunakan Introduce Variable / Bidang / Konstan dan Inline Lokal untuk meningkatkan struktur kode dalam suatu metode, Ekstrak Metode untuk memecah metode yang lebih panjang, Ekstrak Superclass, Push Up, Pull Down dan Pindahkan untuk memindahkan metode dan kelas. " jetbrains.com/pycharm/features/index.html
igouy

@igouy, saya mengacu pada Resharper dan JustCode dalam jawaban saya. Jadi, memang benar untuk konteks yang dimaksud.
Yusubov
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.